How Kubernetes works underneath
From the Ingress that replaces port-forward to the controllers' reconciliation loop
Two pieces on the mechanisms sitting under the everyday use of Kubernetes: how you stop reaching services with a port-forward, and what really happens between a kubectl apply and the state changing. They are for people who use the cluster and want to stop treating it as a black box.
Stop treating the cluster as a black box
You can use Kubernetes for months without knowing what happens between a kubectl apply and the state changing. It works, until it stalls: and at that point the difference between having a mental model and not having one is half a day of guesswork.
These two pieces look underneath. The first replaces the port-forward with an Ingress Controller. The port-forward is fine for a try and becomes untenable once there is more than one service; the Ingress is an address that stops depending on whoever is running it.
The second opens the mechanism sitting under everything else: informers, work queue and reconciliation loop. It is there to explain why a controller has no end but a point of equilibrium, and why the same reconciliation will be called again. That is why it has to be idempotent.
What you will learn
- ✓ Expose services with an Ingress instead of a port-forward for every try
- ✓ Understand the reconciliation loop, and why a controller has no end but an equilibrium
Articles in the series
- 01From port-forward to Ingress: How to configure a professional local Kubernetes environment with NGINX 15 min
Complete guide to configuring an NGINX Ingress Controller on a local Kubernetes cluster (kind) to expose services in a stable and professional manner.
→ - 02Kubernetes Controllers: How the Heart of K8s Works 15 min
A guide to how Kubernetes controllers work, from the reconciliation loop to building a custom controller with controller-runtime
→