kubernetes request routing in a nutshell

Why routing is relevant

As a cloud developer it is essential that you understand how your application is served. In case of an outage where your service is not reachable, you will want to contribute to the root cause analysis. By knowing the basics about routing, you will increase your value as a senior developer.

What are the core routing components in k8s?

In kubernetes, when talking about routing, the following components are crucial: ingress, service, pod, ingress controller. Let’s go through the levels of abstraction. You will get the big picture at the end.

In the following picture, an application “order-management” is running as multi-instance Pods. The Service resource is responsible for service discovery. It queries the cluster for Pod resources that are labeled with the application’s name. It will keep track of the status of the pods and listen to any changes. It is also responsible for load balancing, do distribute calls equally.

Now the ingress is added on top of a service. It basically says that the request for the path /order-management resolves to the “order-management” service. An ingress object can configure multiple path mappings. So one could also map multiple paths to different services.

The outside picture

The following picture is a very simplified version of what happens when a user tries to access your service. Of course, there is a Domain Name Service (DNS) in between that resolves to your clusters IP addresses. This is omitted in the picture.

Ingress controller

It is worth noting that when you set up a kubernetes cluster from scratch, that you will need to deploy an ingress controller in order to configure ingress resources. Out of the box, kubernetes does not provide a component that facilitates this. I recommend to read through this article to get familiar with the different controllers. Here is a guide to set up a nginx ingress controller.