Setting the Scene for Ingress

You'll need a working knowledge of Kubernetes Services before reading this chapter. If you don't already have this, consider going back and reading about Services first.

We’ll capitalize Ingress as it’s a resource in the Kubernetes API. We’ll also be using the terms LoadBalancer and load balancer as follows:

• LoadBalancer refers to a Kubernetes Service object of type=LoadBalancer

• load balancer refers to one of the cloud’s internet-facing load balancers

As an example, when we create a Kubernetes LoadBalancer Service, Kubernetes talks to our cloud platform and provisions a cloud load balancer.

Ingress was promoted to generally available (GA) in Kubernetes version 1.19 after being in beta for over 15 releases. During the 3+ years it was in alpha and beta, service meshes increased in popularity, and there’s now some overlap in functionality. As a result, if we're planning on deploying a service mesh, we may not need Ingress.

Background

The previous chapter showed us how to use NodePort and LoadBalancer Services to expose applications to external clients. However, both have limitations.

NodePort Services only work on high port numbers, and clients need to keep track of node IP addresses. LoadBalancer Services fix this but require a one-to-one mapping between internal Services and cloud load balancers. This means a cluster with 25 internet-facing apps will need 25 cloud load balancers, and cloud load balancers cost money! Our cloud may also limit the number of load balancers we can create.

Ingress fixes this by letting us expose multiple Services through a single cloud load balancer.

It does this by creating a single cloud load balancer on port 80 or 443 and using host-based and path-based routing to map connections to different Services on the cluster.