Kubernetes Ingress Controller - What's the need of it?
When creating ALB rules in AWS console is there a ingress controller running in the background?
I'm a bit confused when learning about ALB ingress controller. I thought it'd be a just a API calls to ALB services in AWS. But the instructor seems to install a aws ingress controller. Then write rules to redirect path to node port services.
What's the difference compared to creating in AWS console and doing it via kubernets cluster.
This is the controller that's being installed.
https://github.com/kubernetes-sigs/aws-load-balancer-controller
Similar Questions
2 Answers
just check my diagram first
So from a high level point of view you have a AWS ALB which redirects the traffic to the underlaying cluster. The Ingress Controller then is responsible to redirect the traffic to the correct Kubernetes service and the service is redirecting the traffic to one of its pods. There are multiple different solutions for that.
My favorite solution is:
- Use an Ingress Controller like the ingress-nginx (there are multiple different Ingress Controllers available for Kubernetes, a very good comparison is provided here)
- Configure the IngressController Service to use NodePort as a type and use a port like 30080
- Create an own AWS ALB with Terraform for an example and add the NodePort 30080 to the TargetGroup
- Create an Ingress resource to configure the IngressController
So i hope that the diagram help to understand the reason of an ALB and an Ingress Controller.
If you still have questions, just ask here.
In general, in Kubernetes, a controller is a running program that observes some Kubernetes objects and manages other objects based on that. For example, there is a controller that observes Deployments and creates ReplicaSets from them, and a controller that observes ReplicaSets and creates matching Pods. In this case, the ALB ingress controller observes Ingress objects and creates the corresponding AWS ALB rules.
Nothing stops you from doing the same setup by hand, or using a tool like Terraform that's a little more specialized for managing cloud resources. Using Ingress objects is a little more portable across environments (you can use a similar Ingress setup for a local minikube installation, for example). This approach would also let you use a single tool like Helm to create a Deployment, Service, and Ingress, and have the ALB automatically updated; if you delete the Helm chart, it will delete the Kubernetes objects, and the ALB will again update itself.
It's also possible that a development team would have permissions in Kubernetes to create Ingress objects, but wouldn't (directly) have permissions in AWS to create load balancers, and this setup might make sense depending on your local security and governance requirements.