After deploying Contour as a Supervisor service, the envoy endpoints aren't listening on the targetPorts 8080 and 8443

Products

• VMware vSphere Kubernetes Service

Issue/Introduction

• After deploying the Contour Ingress Controller, the Envoy LoadBalancer service appears correctly configured with Port 80 mapping to TargetPort 8080. Below is how the service yaml for envoy load balancer looks like
  
  Selector:                 app=envoy,kapp.k14s.io/app=<ID>
Type:                     LoadBalancer
IP Family Policy:         SingleStack
IP Families:              IPv4
IP:                       <IP>
IPs:                       <IP>
LoadBalancer Ingress:     <external-ip>
Port:                     http  80/TCP
TargetPort:               8080/TCP
NodePort:                 http  31247/TCP
Endpoints:                <IP>:8080,<IP>:8080
Port:                     https  443/TCP
TargetPort:               8443/TCP
NodePort:                 https  32259/TCP
Endpoints:                <IP>:8443,<IP>:8443
Session Affinity:         None
External Traffic Policy:  Cluster
Events:


• However, when inspecting the Envoy pods via netstat or the Envoy Admin API (/listeners), the expected ports (8080 for HTTP and 8443 for HTTPS) are not in a LISTEN state. Below is how the netstat output for envoy endpoint looks like.
  
  Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0 127.0.0.1:9001          0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:8090            0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:8002            0.0.0.0:*               LISTEN
tcp        0      0 10.244.0.83:32928       10.244.0.83:8002        TIME_WAIT
tcp        0      0 10.244.0.83:32916       10.244.0.83:8002        TIME_WAIT
tcp        0      0 10.244.0.83:54646       10.244.0.83:8002        TIME_WAIT
tcp        0      0 10.244.0.83:38094       10.244.0.83:8002        TIME_WAIT
tcp        0      0 10.244.0.83:40788       10.244.0.83:8002        TIME_WAIT
tcp        0      0 10.244.0.83:38078       10.244.0.83:8002        TIME_WAIT
tcp        0      0 10.244.0.83:40774       10.244.0.83:8002        TIME_WAIT
tcp        0      0 10.244.0.83:38064       10.244.0.83:8002        TIME_WAIT
tcp        0      0 10.244.0.83:38706       10.244.0.83:8002        TIME_WAIT
tcp        0      0 10.244.0.83:39652       10.244.0.83:8002        TIME_WAIT
tcp        0      0 10.244.0.83:40800       10.244.0.83:8002        TIME_WAIT
tcp        0      0 10.244.0.83:39660       10.244.0.83:8002        TIME_WAIT
tcp        0      0 10.244.0.83:39746       10.96.2.71:8001         ESTABLISHED
tcp        0      0 10.244.0.83:38692       10.244.0.83:8002        TIME_WAIT
tcp        0      0 10.244.0.83:32930       10.244.0.83:8002        TIME_WAIT
tcp        0      0 10.244.0.83:54650       10.244.0.83:8002        TIME_WAIT
  
  
• External traffic hitting the LoadBalancer results in a Connection Refused because the underlying pod is not accepting traffic on the designated TargetPorts

Environment

VMware vSphere Kubernetes Service

Cause

This is an intended contour behaviour.

In a default installation, contour is intelligent enough to know that if there are no routing rules defined in the cluster, it technically has "nothing to do." To save resources and maintain security, it does not instruct Envoy to open the 8080/8443 ports until a valid route exists. Envoy listeners are created on-demand.

Resolution

To wake up the Envoy listeners, a dummy routing object can be applied to the cluster.

For example, apply a basic HTTPProxy object (for port 8080) and HTTPSProxy (for port 8443). Even if the backend service is invalid or non-existent, the presence of the object triggers Contour to instruct envoy to open these ports.

Additional Information

Per Virtual services of Contour in AVI is down, you can also deploy Harbor with Supervisor service which will use the Contour Ingress. The same should also lead to the relevant port getting opened on the envoy end.