Ingress and Ingress Controllers

Luke Hebert

- 4 minutes read - 645 words

Ingress is a Kubernetes resource that exposes HTTP and HTTPS routes from outside the cluster to services within it. It provides load balancing, SSL/TLS termination, and name-based virtual hosting, all controlled by rules defined on the Ingress resource. An Ingress controller (such as nginx, HAProxy, or a cloud-provider load balancer) is required to fulfill the Ingress and route traffic to the appropriate backends.

What is Ingress?

Ingress exposes HTTP and HTTPS routes from outside the cluster to services within the cluster. Traffic routing is controlled by rules defined on the Ingress resource. An Ingress may be configured to give Services externally reachable URLs, load balance traffic, terminate SSL/TLS, and offer name-based virtual hosting.

An Ingress controller is responsible for fulfilling the Ingress, usually with a load balancer, though it may also configure your edge router or additional frontends to help handle the traffic.

An Ingress does not expose arbitrary ports or protocols. Exposing services other than HTTP and HTTPS to the internet typically uses a service of type Service.Type=NodePort or Service.Type=LoadBalancer.

Exported image

Figure. Ingress

Terminology

For clarity, this guide defines the following terms:

  • Node: A worker machine in Kubernetes, part of a cluster.
  • Cluster: A set of Nodes that run containerized applications managed by Kubernetes. For this example, and in most common Kubernetes deployments, nodes in the cluster are not part of the public internet.
  • Edge router: A router that enforces the firewall policy for your cluster. This could be a gateway managed by a cloud provider or a physical piece of hardware.
  • Cluster network: A set of links, logical or physical, that facilitate communication within a cluster according to the Kubernetes networking model.
  • Service: A Kubernetes Service that identifies a set of Pods using label selectors. Unless mentioned otherwise, Services are assumed to have virtual IPs only routable within the cluster network.

Ingress Controllers

Make your HTTP (or HTTPS) network service available using a protocol-aware configuration mechanism that understands web concepts like URIs, hostnames, paths, and more. The Ingress concept lets you map traffic to different backends based on rules you define via the Kubernetes API.

This service acts as a load balancer over your exposed services to facilitate traffic routing. You still need to expose this service, but it is simpler to expose one service than many separate load balancers provisioned on a provider.

You will have to deploy an Ingress controller of some kind in order to deploy this service. If you define Ingress objects in Kubernetes without deploying a controller, they will not work. There are some options such as HAProxy, GCE (Google HTTPS Load Balancer), AWS ALB Ingress, Nginx Ingress, Traefik, Contour, and Istio.

Keep in mind that Ingress Controllers are not very suitable for multi-tenant deployments and they mostly target HTTP traffic routing. They may not cover other traffic types. The configurations also support options that are passed through as annotations. Kubernetes has also created a new project known as Gateway API, and it is the next generation of Ingress controllers.

Common fields you will encounter in an Ingress spec include apiVersion, serviceName, and servicePort.

Exported image

Creating an Ingress

In Kubernetes version 1.20 and later, you can create an Ingress resource imperatively with kubectl:

kubectl create ingress <ingress-name> --rule="host/path=service:port"

Example:

kubectl create ingress ingress-test --rule="wear.my-online-store.com/wear*=wear-service:80"

Find more information and examples in the kubectl ingress reference.

Prerequisites

You must have an Ingress controller to satisfy an Ingress. Only creating an Ingress resource has no effect.

You may need to deploy an Ingress controller such as ingress-nginx. You can choose from a number of Ingress controllers.

Ideally, all Ingress controllers should fit the reference specification. In reality, the various Ingress controllers operate slightly differently.

Note

Make sure you review your Ingress controller’s documentation to understand the caveats of choosing it.

References

Kubernetes as a project supports and maintains AWS, GCE, and nginx Ingress controllers.