Kubernetes for Operators

Just Enough Kubernetes

Kubernetes has a reputation for complexity, and most of that reputation is earned by people learning all of it. An operator does not need all of it. You need the mental model and the handful of objects you actually touch. This lesson teaches exactly that and deliberately stops there — no cargo cult, no reciting features you'll never use.

Here is the one idea everything else hangs from: Kubernetes is a reconcile loop. You declare the state you want — "three replicas of this image, behind this address" — and a set of controllers continuously work to make reality match your declaration. You don't run commands that do things; you write down what should be true and the system converges on it. That shift, from imperative to declarative, is the whole conceptual jump.

The Control Plane: Who Decides What

The cluster splits into two halves: the control plane that decides what should be true, and the worker nodes that make it real. Four components run the control plane.

The API server is the only door in. Every kubectl command, every controller, every kubelet talks to it and nothing else — it is the single front door to the cluster's state. etcd is the source of truth: a key-value store holding the desired state of everything. You never touch etcd directly; you change it by talking to the API server. The scheduler decides which node an unscheduled Pod lands on, based on resource requests, GPU availability, and affinity rules. The controller manager runs the reconcile loops — it's the component that recreates your deleted Pod.

On a worker node, the kubelet is the local agent: it talks to the API server, starts and stops containers through the container runtime (containerd), and reports health back. Your Pods — your running images — live here. That's the entire map. Four control-plane components, three things on a node.

The Five Objects You Actually Touch

You will spend almost all of your time with five objects, and they chain together in a clean ownership flow.

You write a Deployment: replicas, image, update strategy. The Deployment creates and owns a ReplicaSet, whose only job is to keep the right number of Pods alive — recreating any that die. The Pods run your container, but they are ephemeral cattle: they get new IPs on restart, so nothing should ever target a Pod directly. A Service sits in front of them with a stable virtual IP and DNS name, load-balancing across whatever Pods currently match its label selector. An Ingress sits further out still, routing HTTP(S) traffic from outside the cluster to the Service.

The critical insight is the ownership boundary. You write the Deployment, the Service, and the Ingress. ReplicaSet and Pods are derived and managed for you — you read them when debugging, but you do not create or edit them by hand. This is why creating a bare Pod is an anti-pattern: a Pod with no controller above it has nothing watching to recreate it when it dies.

Declare it yourself: a Deployment for a stateless inference service — with probes and resource bounds — and the Service that fronts it so callers target a stable name instead of an ephemeral Pod IP.

What an Operator Skips

Equally important is what you don't need on day one. Kubernetes ships with StatefulSets, DaemonSets, Jobs, CronJobs, NetworkPolicies, custom resource definitions, operators, admission webhooks, and a hundred more nouns. An inference-first single-stack operator reaches for a small subset:

• A Deployment for the stateless inference service.
• A Service to give it a stable address.
• A ConfigMap and Secret for configuration and credentials — never bake secrets into the image.
• An Ingress if it's reached from outside the cluster.
• A DaemonSet only when you add GPU nodes (the NVIDIA device plugin, the next lesson).
• An HPA when you need autoscaling (also the next lesson).

Everything else, learn when a concrete problem demands it. Learning Kubernetes nouns you have no use for is the cargo cult this lesson exists to prevent. The Semantic Memory Layer-style knowledge-OS from the prerequisite track maps cleanly onto this short list: one Deployment, one Service, a Secret for the bearer token, a ConfigMap for namespaces — and it is unambiguously production.

What's Next

You can now declare a service into a cluster and trust the control plane to keep it running. But an LLM service needs a GPU, and a production service needs to scale with load. The next lesson covers both: how the scheduler hands a whole GPU to a Pod that asks for one, and how the Horizontal Pod Autoscaler reconciles replica count against the metric that actually predicts an outage. You'll write the Deployment with GPU requests and the HPA yourself.