The Role and Importance of Kubernetes Ingress: How It Works
In this blog, we will explore the role of ingress in the Kubernetes cluster and its usefulness for applications.
Problem statement
Consider the legacy application environment, where we manage the application’s services directly on the VM and use the single load balancer (Nginx) to route all the services.
Refer to the blog, about the functionality of the Nginx load balancer.
server {
listen 80;
server_name api.exapmle.com
location / {
proxy_pass http://localhost:3000;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-Proto $scheme;
}
location /api {
proxy_pass http://localhost:8000;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
In Kubernetes, we create a deployment object to deploy an application, and a service object to access the application.
Problem 1:
Service provides the load balancer mechanism (only round robin) and not all the enterprise-level functionality like ratio-based route, path-based route, host-based route, sticky session, whitelisting, etc.
Problem 2:
We may need to expose each service individually using a LoadBalancer or NodePort. So far, we have had to create or maintain multiple static IPs, which the cloud provider charges for.
This is a primary problem when using service resources in Kubernetes to manage the application.
About Ingress
The Ingress resources simplify managing traffic to your applications, making it more organized and cost-efficient.
Ingress provides all enterprise-level load-balancing functionality.
Single ingress can handle multiple service objects using path-based routing.
Instead of having many separate entry points for different services, Ingress lets you use one IP address or domain name.
An Ingress controller is a proxy with advanced load-balancing functionality for Kubernetes.
How does Ingress work?
For every resource that we are creating in Kubernetes, there is a component/controller which was watching that resources & performs the required action, if we create an ingress resource in the K8s cluster there has to be a resource/controller which has to watch for this ingress.
Before creating the ingress resource the ingress controller should be deployed or configured.
It acts as a proxy and load balancer that receives incoming traffic and forwards it to the appropriate service inside the cluster based on the defined configuration.
Nginx ingress controller
The Nginx ingress controller which acts as a load balancer is used inside the cluster by deploying the Nginx application as a pod in a particular namespace.
The Nginx ingress controller continuously watches for the ingress resources, so whenever we request or create it will sync it and will go into the nginx config and update with routing details.
Unlike proxies for web servers, it is not publicly accessible so can’t access the nginx ingress controller directly from the browser, it leaves inside the cluster network & forwards the request internally.
For production purposes, we use a cloud load balancer like AWS LB, which forwards the client’s request to the ingress controller inside the cluster, and then forwards the request to service resources which was configured in the ingress resources.
Note: For some of the ingress controllers, the load balancer sits outside the cluster because they might not have a containerized solution, and the configuration of the ingress controller varies accordingly.
Ingress resource examples
Host-based ingress resource
apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: myingress labels: name: myingress spec: ingressClassName: nginx rules: - host: test.minex.com http: paths: - pathType: Prefix path: "/" backend: service: name: test-svc port: number: 80
Path-based ingress resource
apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: myingress labels: name: myingress spec: ingressClassName: nginx rules: - host: test.minex.com http: paths: - path: "/first" pathType: Prefix backend: service: name: test1-svc port: number: 80 - path: "/second" pathType: Prefix backend: service: name: test2-svc port: number: 80
Wildcard ingress resource
apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: myingress labels: name: myingress spec: ingressClassName: nginx rules: - host: "*.minex.com" http: paths: - pathType: Prefix path: "/" backend: service: name: test-svc port: number: 80
Thank you for reading…