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

1. 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
   

2. 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
   

3. 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…