contour: Address not set on Ingress resource

Contour does not set the IP value on the Ingress resource. This value is necessary for services like ExternalDNS to work properly.

Version

The version that https://j.hept.io/contour-deployment-norbac produces. Atm: docker.io/envoyproxy/envoy-alpine:v1.6.0 gcr.io/heptio-images/contour:master (pointing to b9ede01f025)

Repro

  1. Setup Contour in your cluster. kubectl apply -f kubectl apply -f https://j.hept.io/contour-deployment-norbac
  2. Deploy a simple service with Ingress rules. kubectl apply -f https://gist.githubusercontent.com/nphmuller/1c980c72e2119b1482e19eb619def08f/raw/10331f4bbc18abe36a0c8c841bf70ab04a38eb92/service-with-ingress.yaml
  3. (A) kubectl get ingress nginx
  4. (B) kubectl get ingress nginx -o yaml

Expected

A. ADDRESS column should have external IP of Contour load balancer service, but is empty. B. status should have value:

status:
  loadBalancer:
    ingress:
    - ip: %External IP-of-Contour-LoadBalancer-service%

but has value:

status:
  loadBalancer: {}

About this issue

  • Original URL
  • State: closed
  • Created 6 years ago
  • Reactions: 16
  • Comments: 16 (12 by maintainers)

Commits related to this issue

Most upvoted comments

I was going to pick this up, my thought here was to do the following:

  1. Contour watches for all Services right now, when it finds service with an external LB attached, then look to see if that matches the namespace where Contour is deployed. This will be the IP/DNS name that should get attached to any Ingress object.

This assumption also assumes there’s only one service in the namespace where Contour is deployed that is type LoadBalancer. We could also filter on the service name envoy, but not sure if that’s too specific.

The status should also only get updated if the ingress class matches the Ingress resource.

+2
stevesloka on Nov 25, 2019

This should be possible to cover as part of the IngressRoute refactor. No ETA on a milestone.

+2
davecheney on Jun 25, 2018

Just to provide an update aside from commit messages:

The main part of this work is complete for the example deployment - Contour will now look for the Envoy service and expose the IP from its Loadbalancer-type Service in Ingress records that are in scope.

The last piece is to complete #2387, allowing manual specification of the details rather than pulling them from a Service.

+1
youngnick on Apr 7, 2020

I’m picking this up now that Dave has left the team.

The current design of this has taken a lot of cues from the nginx-ingress-controller, speficially the --update-status, --publish-service, and --publish-status-address, see the command line reference.

Contour’s current design is as follows:

  • there is a new IngressStatusWriter goroutine added, that watches a channel for status updates, and writes them back to the apiserver (once it is elected leader).
  • There is a new Service Load Balancer watcher that, in the example deployment, watches the envoy service in ProjectContour for the load balancer address, and sends it down the channel to IngressStatusWriter. This is configured with via command-line flags, with defaults to the example deployment.

Todo:

  • command line flags that allow specification of a manual address or domain name. (#2387)
  • Handle ingress class correctly ( OnUpdate in the LoadBalancer status watcher amongst others) (#2388)

Done:

  • in-cluster manual testing to try and find any flakiness with the current method
+1
youngnick on Apr 7, 2020

@stevesloka Probably worth doing a small prior art survey to see how other ingress controllers solve this problem. IIRC ingress-nginx uses a command flag.

+1
jpeach on Nov 27, 2019
Read more comments on GitHub
← chrono: Pychrono tutorials do not succeed
contour: Contour should not 503 traffic to a down service if there is another service available in the Route →