See also migration notes: https://gist.github.com/icy/20354a9b6962baa2b4df350533751e73
Homepage: https://github.com/zalando-incubator/kube-ingress-aws-controller
zalando is creating a confusing name. Their controller isn't an ingress
controller. What it can do is to help other ingress controller(s).
So, this is a short explanation how it works: You install your primary ingress controller, e.g, https://github.com/kubernetes/ingress-nginx with some special configurations, so that
- it doesn't actually create any new ALB/ELB/... resource (don't try
LoadBalancerservice) - it doesn't try to update status of any LBs (
--update-status=false)
Your primary ingress controller gets its job done. Now, zalando
controller will fetch a list of Ingress resources from k8s cluster,
then (amazingly) it creates new Cloudformation stack to set up
- new Amazon ALB/ELB/NLB
- new target groups/LB configuration targeting your k8s worker instances
How can new ALB see new instances? It's about healthcheck endpoints. When you start the zalando controller, you provide the health-check-path, health-check-port, and the target-port. All these configurations are set up in new ALB settings, which should be aligned with your actual (nginx) ingress controller settings: For example, you configure nginx daemon to listen on every node (daemonset) and provide health check ports/paths are specified in zalando configuration. (For kube ingress controller, you may look at the flags --health-check-path and --healthz-port; yes different tools use different option names for the same thing.)
The idea is very good, and it also helps a lot. With a few drawbacks
- It's quite impossible to support your local domains, e.g,
foo.local - If you don't have ssl certificate for your domain on AWS Certificate Manager
the
zalandocontroller gives up - Because it's all about CLoudformation, you need to learn a new thing, wait for stuff, and sometimes get stuck if Cloudformation just doesn't work or creates a war :)