Often, we want to configure context-based routing for our Kubernetes cluster. Kubernetes offers us various ways to do so. The preferred and most scalable way at this time is to use an IngressController for this job. The following diagram tries to illustrate how this ingress controller works:
In this diagram, we can see how context-based (or layer 7) routing works when using an ingress controller, such as Nginx. Here, we have a deployment of an application service called web. All the pods of this application service have a label app=web. We then have a Kubernetes service called web that provides a stable endpoint to those pods. The service has a (virtual) IP of 52.14.0.13 and exposes port 30044. That is, if a request comes to any node of the Kubernetes cluster for the name web and port 30044, then it is forwarded to this service. The service then load balances the request to one of the pods.
So far so good, but how is an ingress request from a client to the URL http[s]://example.com/web routed to our web service? First, we have to define the routing from a context-based request to a corresponding <service name>/<port> request. This is done through an Ingress object:
- In the Ingress object, we define the host and path as the source and the (service) name, and the port as the target. When this Ingress object is created by the Kubernetes API server, then a process that runs as sidecar in the IngressController picks this change up
- Modifies the configuration file of the Nginx reverse proxy
- By adding the new route, Nginx is then asked to reload its configuration and thus will be able to correctly route any incoming requests to http[s]://example.com/web.