Ingress Resource, Ingress Controller and Ingress Class

If you're about to set up your Runtime Fabric cluster for Inbound Traffic and you're new to K8s and its terminology, you'll probably get confused with these three concepts: ingress, ingress controller and ingress class.
Understanding the differences between them is crucial for managing how traffic is routed into a Kubernetes cluster. Let’s see them in detail:

Ingress Controller

As we saw in this post, an ingress controller is a solution that we installed in our Kubernetes cluster that allows us to control and manage the incoming traffic to our Kubernetes cluster. With an ingress in our cluster we can expose our applications in the cluster behind a single point.

Controlling that endpoint the ingress can do load balancing, SSL termination and advanced traffic management (rate limiting, IP withelisting/blacklisting, redirects...).

In addition, the primary role of an Ingress is Traffic Routing - an Ingress Controller is continuously processing Ingress resources, which define how traffic should be directed based on hostnames, paths, or other conditions. The controller configures the underlying infrastructure (such as a load balancer or reverse proxy) to route traffic accordingly.

Have a look at this post if you want to know how an ingress works and is deployed. Common Ingress controllers include NGINX, Traefik, and HAProxy.

Ingress Resource

An Ingress Resource is a Kubernetes API object that defines rules for how external HTTP/S traffic should be routed to services within a cluster.
It specifies the mappings from HTTP/S paths or hosts to Kubernetes services. For example, it can route traffic from example.com/foo to one service and example.com/bar to another.

The Ingress resource is a YAML file that includes rules for routing traffic. Here’s an example:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
spec:
  rules:
  - host: example.com
    http:
      paths:
      - path: /foo
        pathType: Prefix
        backend:
          service:
            name: foo-service
            port:
              number: 80

The ingress controller is continuously watching the Kubernetes API server for updates to Ingress resources and configures the underlying load balancer or reverse proxy to route traffic according to the rules specified in the ingress resource. It processes the Ingress resources and makes the necessary configurations to allow inbound connections.

Ingress Class

As we saw recently in this post, we can install multiple ingress controllers. Ingress Classes are particularly important in this scenario. An Ingress Class is the mechanism that K8s uses to specify and configure which Ingress controller should handle a particular Ingress resource.

Think about it - with everything we said so far, if we’ve got more than one ingress controller, what happens when we define a new Ingress Resource? which ingress controller should take care of that new rule? That is what the ingress class will tell us.

Let’s see an example;

Let’s say we’ve got our K8s cluster and we’ve installed 2 ingress controllers - NGINX and Traefik
First, we create the IngressClass for each Ingress Controller:

apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
  name: traefik-ingress-class
spec:
  controller: traefik.io/ingress-controller
---

apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
  name: nginx-ingress-class
spec:
  controller: nginx.org/ingress-controller

Next, we create the Ingress Resources, one for Traefik and one for NGINX:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: traefik-example-ingress
spec:
  ingressClassName: traefik-ingress-class
  rules:
  - host: traefik.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: traefik-service
            port:
              number: 80
---

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: nginx-example-ingress
spec:
  ingressClassName: nginx-ingress-class
  rules:
  - host: nginx.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: nginx-service
            port:
              number: 80

Once everything is deployed:

Access nginx.example.com to route traffic through the NGINX Ingress Controller.
Access traefik.example.com to route traffic through the Traefik Ingress Controller.

Summary

Ingress Controller:

Manages and fulfills Ingress resources by configuring load balancers or reverse proxies.
Operates at the controller level, handling traffic based on Ingress resources.

Ingress Resource:

Defines the rules and paths for routing external HTTP/S traffic to internal services.
Operates at the resource level, defining specific routing rules for services.

Ingress Class:

Specifies which Ingress controller should manage a particular Ingress resource.
Operates at the class level, enabling the association of Ingress resources with specific controllers.

This structure allows Kubernetes to handle traffic routing in a flexible and scalable manner, accommodating various use cases and configurations.