Kubernetes Algorithms

The smallest thing Kubernetes handles is not a container but a Pod. A Pod wraps one or more containers, and the containers inside share a single IP and their volumes. That lets them call each other over localhost and read the same files. Placement and lifetime are shared too, which makes the Pod both the unit that gets scheduled onto a node and the unit that gets restarted.

A Node is a machine that lends its resources to the cluster; a Pod is something placed on it for a while. A Node does not decide what it runs — a controller creates the workload, the scheduler picks the seat, and the Node's kubelet takes it and starts it. That is why Pods do not travel between Nodes: what looks like a move is a Pod being deleted here and a new one created there.

A Deployment keeps a number of Pods up; a Job counts how many have succeeded. Hand work that has to finish — a nightly reconciliation, a data migration — to a Deployment and every finished Pod looks like an empty slot, so the same work starts over forever. A Job stops creating Pods once the declared number of completions is reached, and a CronJob stamps out that Job on a schedule.

You don't hand Kubernetes a procedure; you declare a result. Write down that there should be three web servers, and a controller keeps looking at what's actually running and closes the gap whenever reality differs. When a node dies and a Pod vanishes, nobody issues a repair command. The mere fact that there are two where there should be three is what creates a new Pod.

A Deployment doesn't patch Pods — it replaces them. Declare a new version and it creates a new ReplicaSet, then takes an old Pod down only after a new one has finished starting. That ordering is why the available count never falls below what you declared for the whole rollout. Zero downtime isn't a special mechanism; it falls out of the order of operations.

Instead of writing down a count, you write down a goal. The autoscaler samples the Pods' average utilisation and multiplies the current count by how far off the goal it is. The Pods it adds share the same load, which pulls utilisation back down — and that value becomes the input to the next decision. Count and metric pull on each other.

A container being up and a container being able to take requests are two different things. The kubelet asks each container on a schedule, and it answers the same silence in two ways: a failed readiness probe only removes the Pod from the Service endpoints, while a failed liveness probe kills the container and starts it again. Which one you attach decides whether an incident merely cuts traffic or restarts the process.

Pods die and are reborn, taking a new IP each time. A Service puts an unchanging address in front of them and picks what stands behind it by label, not by name. Matching Pods join the list as they appear and drop out as they vanish — while the address callers use never changes.

The address a Service puts up only answers inside the cluster. Taking traffic from outside means a door per Service, and every door drags along an IP and a certificate. An Ingress collects those doors into one and decides the destination by which rule the request's host and path match. However many domains you serve, there is one way in.

The same code has to behave differently in development and in production. Bake the values into the image and the code stays identical while the images multiply — one per environment, rebuilt for every value you change. Move the settings into a ConfigMap and a Secret and one image is enough; the values are laid on as environment variables or files when the Pod starts.

Files a container writes share the container's lifetime. Restart the Pod and the place is empty; move it to another node and that becomes obvious. Data that has to survive belongs outside the Pod — and there the Pod doesn't pick a disk itself, it writes down how much and in what mode it needs as a PersistentVolumeClaim.

Creating a Pod doesn't start it. A node has to be chosen first. What the scheduler looks at is not what is being used right now but the sum of the requests the Pods declared — the reserved share. Nodes that can't take the request are filtered out, and the remaining candidates are scored to pick one.