Kubernetes

A control loop, not a command runner

The mental model that makes everything else fall into place is a thermostat. You do not tell a thermostat to turn on the heating; you tell it the temperature you want, and it keeps measuring and acting until the room matches — and then keeps measuring. Kubernetes works the same way. You submit an object describing what should be true, the API server stores it, and a controller loops forever: read the desired state, read the actual state, act on the difference.

This is why deleting a Pod by hand accomplishes nothing lasting: the Deployment still says three replicas, so a controller notices two and makes a third. It is why applying the same manifest twice is harmless — you restated a fact rather than issued a second instruction. And it is why the interesting question during an incident is never "did the command run" but "what does the cluster currently believe should be true, and what is stopping it". The answer is in the object's status and its events, which is the first place to look and the last place people look.

The objects you actually need

The API surface is enormous and the working set is small. Six objects cover most of what a service needs, and each exists because a controller reconciles it against something.

• Pod

  One or more containers that share a network address and can share a volume. The smallest thing scheduled — and never created directly.

• Deployment

  Says how many identical Pods should exist and from which image. Handles rolling updates and rollbacks. This is what you write.

• Service

  A stable name and address in front of a changing set of Pods. Pods come and go with new addresses; the Service does not.

• Ingress

  Routes outside HTTP traffic to Services by host and path, and terminates TLS. One entry point instead of one per service.

• ConfigMap & Secret

  Configuration and credentials supplied to Pods as env vars or files. A Secret is base64-encoded, not encrypted — enable encryption at rest.

• StatefulSet

  For Pods that need stable identity and their own persistent storage. Necessary for databases, and a reason to ask whether you want one here at all.

A Service is worth one extra sentence because it is where the naming confusion lives. Inside the cluster, a Service gives you a DNS name that resolves to a stable virtual address, and traffic to it is spread across whichever Pods currently match its selector. That indirection is the whole reason a Pod can be replaced at any moment without anything else being reconfigured — and it is also why "the Pod is running but nothing can reach it" is almost always a selector that does not match the Pod's labels.

Where the incidents come from

Two settings cause more production trouble than everything else combined, and both look like boilerplate. The first is resources. A request is what the scheduler reserves when deciding which node a Pod fits on; a limit is the ceiling enforced while it runs. Set requests too low and the node is oversubscribed, so Pods land where there is no room to grow. Set them too high and you pay for capacity nobody uses. Omit them entirely and the scheduler is guessing, which is how one service ends up starving its neighbours on the same node.

The two limits behave differently when reached, and confusing them wastes hours. Exceeding the memory limit gets the process killed by the kernel: the Pod shows OOMKilled, restarts, and there is no stack trace because no exception was ever raised. Exceeding the CPU limit kills nothing — the process is throttled, so the symptom is latency that grows under load with no error anywhere, which people spend a day blaming on the database. Memory kills, CPU slows: that sentence saves the day it takes to learn it.

How this shows up in real delivery

The honest question is whether you need it at all, and the answer is less often yes than the industry conversation suggests. Kubernetes buys you scheduling across many machines, self-healing, rolling updates and one declarative interface for teams that each run several services. It charges for that in a permanent operational surface: upgrades, networking, storage classes, access control, and a class of failure whose cause is the platform rather than your code. Three services on two machines get most of the benefit from a container runtime and a load balancer, at a fraction of the cost — and a managed platform that hides the control plane is the middle option worth considering before either extreme.

If you do run it, the practice that pays for itself fastest is keeping manifests in a repository and having something apply them, rather than people running commands against the cluster. The cluster then has a reviewable history, a rollback is a revert, and the difference between what should be running and what is running becomes visible instead of anecdotal. Templating — Helm, Kustomize or either of their descendants — earns its place the moment the same manifests exist per environment, and stops earning it the moment nobody can tell what the templates produce.

On stateful workloads: the platform can run a database, and the question is whether it should. A StatefulSet plus persistent volumes gives you identity and storage that survive rescheduling, and it also gives you responsibility for backups, failover, version upgrades and the storage layer's own failure modes — on top of a scheduler that is designed to move things. Teams that run their own databases this way generally have someone whose job that is. Teams that do not are usually better served by a managed database and a cluster that holds only stateless work.

Where it degrades

• Adopting it for three services on two machines, and paying the operational cost for none of the benefit.
• A liveness probe with a dependency in its path, which turns a slow database into a cluster-wide restart storm.
• No resource requests, so the scheduler guesses and one service starves its neighbours.
• Chasing an OOMKilled restart for a stack trace that was never produced, because the kernel did the killing.
• Changes made with kubectl edit on a live cluster, which the next apply silently discards.
• Secrets committed as manifests, base64-encoded and mistaken for encrypted.
• A Service whose selector does not match the Pod labels, so a healthy Pod receives nothing.
• Running your own database in-cluster with nobody owning backups, failover or storage.
• Templating layered on templating, until no one can say what is actually applied.

When to use it

Related pages

• InfrastructureDockerDocker packages an application with everything it needs to run into one image, and runs that image as a container. A container is not a small virtual machine. It is an ordinary process on the host kernel, given a restricted view of the filesystem, the network and the process table, and a limit on what it may consume. The image it starts from is a stack of read-only layers. Those two facts explain almost everything: why containers start in milliseconds, why the order of your Dockerfile decides your build time, why the state inside one disappears, and what isolation actually protects you from.
• InfrastructureCI/CDContinuous integration is not a server that runs your tests — it is the habit of merging into one shared branch often enough that conflicts stay small, and the automation exists to make that habit safe. Continuous delivery is the second half: one artifact, built once, promoted through environments without being rebuilt. This page covers how to order the stages, why a flaky test destroys the pipeline's authority, what the deployment strategies actually trade, and the four numbers that tell you whether any of it is working.
• DevelopmentMicroservicesMicroservices are an architecture in which a system is built as a set of services that can each be deployed on their own. The defining property is independent deployability, not size — a service is the right size when one team can own it end to end. Everything good about the style follows from that independence, and everything hard about it follows from the fact that the calls between services now cross a network.