Ingress Architecture

Introduction to the architecture

Ingress is defined in the networking.k8s.io/v1 API sub-group, and it requires the usual two constructs:

1. A resource

2. A controller

The resource defines the routing rules, and the controller implements them.

However, Kubernetes doesn’t have a built-in Ingress controller, meaning we need to install one. This differs from Deployments, ReplicaSets, Services, and most other resources that have built-in pre-configured controllers. However, some cloud platforms simplify this by allowing us to install one when we build the cluster. We’ll install the popular NGINX Ingress controller in the hands-on section.

Once we have an Ingress controller, we deploy Ingress resources with rules telling the controller how to route requests.

On the topic of routing, Ingress operates at layer 7 of the OSI model, also known as the application layer. This means it can inspect HTTP headers and forward traffic based on hostnames and paths.

Note: The OSI model is the industry-standard reference model for TCP/IP networking and has seven layers numbered 1-7. The lowest layers are concerned with signaling and electronics, the middle layers deal with reliability through acknowledgements and retries, and the higher layers add services for things like HTTP. Ingress operates at layer 7, also known as the application layer, and implements HTTP intelligence.

The following table shows how hostnames and paths can route to backend ClusterIP Services.