Kubernetes Any% Speedrun 2: Electric Kubealoo
Please note that this post is in draft. It may contain entirely incorrect opinions.
Way back in May I wrote a post about a super high-level, naive view of Kubernetes. It was informed predominantly by my limited experiences using it to run up the original version of the Fandom Supply in a way that meant I didn’t actually have to do any administration. I’ve since become a little more acquainted with it as a system and figured I’d write a follow-up after seeing this post still making the rounds in various secret underground multiplayer notepad fight clubs, or “internet relay chat channels”. If you know, you know.
While some things have changed since the Last Thursday™ that was the post in May, the base concepts haven’t. As a refresher course for those of you that have not completed your homework, the concepts are:
- Cluster: The whole apparatus. A cluster is made up of everything below.
- Node: Basically the host servers that run Kubernetes agents. In the old times, applying the ancient concepts of virtualisation, we’d call these “hypervisors”.
- Pod: A group of one or more containers (you know, the Docker things), alongside a specification for how to run them. The contents of a pod (i.e., the one or more containers) run in a shared context and can access each others’ resources. A pod more or less models an application-specific “logical host” - one or more containers that are tightly coupled together (e.g., a web application container and its image processing queue container). In the old times, being executed on the same physical or virtual machine is roughly analogous.
- Deployment: A declarative state for a pod (e.g., how many instances of it or how you want it to update to the latest container image). You describe the desired state and the Kubernetes blackbox deployment controller 3000™ changes the actual state to the state you describe at a controlled rate. In the old times, we called these “playbooks”.
- Service: Pods are mortal and - sadly - eventually even they have their time come. When they expire, they cycle out and are replaced with new Pods. A service is an abstract way to expose a pod or set of Pods as a network service to the Kubernetes cluster. Services are basically plumbing between Pods, providing an internal IP address and hostname to a Deployment set.
- Ingress: An abstract way to manage external access to your Services. Typically over HTTP. Ingresses can support load-balancing, TLS termination, and name-based internal virtual hosting a la Nginx’s load balancing / reverse proxying functionality. Staggeringly, you can embed things like Caddy in as an Ingress. Why? I don’t know.