Kubernetes for application teams
Your order service now ships as a small container image. This lesson puts it on a Kubernetes cluster the way an application team should: four copies behind a stable address, config and secrets kept out of the image, probes that restart only what is truly stuck, honest resource numbers, and a rollout you can watch and undo from the command line.
By the end you can
- Explain how a Deployment, its ReplicaSets, labels and a Service work together to keep pods running and reachable
- Choose readiness, liveness and startup probes for a real API, and avoid the restart storm
- Set CPU and memory requests and limits from measurements, and read throttling and OOMKilled correctly
- Tune a rolling update with maxSurge and maxUnavailable, then follow and undo it with kubectl
- Write and lint the manifests for the order service
The everyday picture
Picture the shift manager of a busy Mangrove store. On the wall is a roster: "four cashiers on the tills from 5 pm". She does not ring each cashier herself every minute. She walks the floor every few minutes, compares what she sees with the roster, and fixes the difference. A cashier goes home sick, so she calls in another. The roster changes to five, so she adds one.
She watches two things about each cashier. Is the till open right now? If a cashier is counting the float, she puts up a "this till closed" sign and sends customers to other tills, but nobody is sent home. And has the cashier actually fainted? Only then does she replace the person.
Kubernetes is that shift manager for your containers. You write the roster as a file, and it keeps reality matching it. The two kinds of checks have names: readiness (send customers here or not) and liveness (replace this one). The most expensive mistake on this page is the manager who sends every cashier home because the card machines went down for a minute. Then nobody can serve, not even the customers paying cash.
From roster to running pods: Deployments, labels and Services
A cluster has a control plane and some worker nodes. The control plane stores every object you create (in etcd) and runs controllers that keep comparing desired state with actual state. On each node, the kubelet starts containers and reports back. You never say "start a container on node 3". You declare "I want four copies of this", and the controllers keep making it true.
The smallest thing Kubernetes runs is a pod: one or more containers that share an IP address on one node. An order service pod holds one container, the NestJS API from Containers from the inside. Pods are replaced all the time, and each new one gets a new name and IP address.
You almost never create pods yourself. You create a Deployment. The chain works like this:
- The Deployment holds a pod template (image, ports, probes, resources) and a replica count.
- For each version of the template it creates a ReplicaSet. The ReplicaSet's only job is "keep exactly N pods like this alive".
- The ReplicaSet creates pods. If a node dies and takes two pods with it, the ReplicaSet notices the count is 2 instead of 4 and creates two more elsewhere.
How does a ReplicaSet know which pods are its own? Through labels and selectors. Every pod from the template carries app: order-service, and the Deployment's selector asks for exactly that. The selector must match the template labels, and in apps/v1 it cannot be changed after the Deployment is created. Labels are the glue of Kubernetes: nothing points at pods by name.
If pod IPs keep changing, how does checkout reach the order service? Through a Service. A Service of type ClusterIP gets a stable virtual IP and a DNS name such as order-service.orders.svc.cluster.local (or order-service from inside the same namespace). It uses a label selector too, and keeps a live list (EndpointSlices) of matching pods that are ready. A pod that is not ready is left out, so it gets no traffic.
A ClusterIP Service is reachable only inside the cluster. For traffic from outside, the older API is Ingress, which needs an ingress controller installed. The newer one is the Gateway API: a platform team runs a Gateway, and app teams attach an HTTPRoute such as "send /orders on this host to my Service". The Kubernetes docs describe the Ingress API as frozen: it still works, and new features go into the Gateway API.
Quick check
You change only the image tag in the order service Deployment and apply it. What happens to the ReplicaSets?
A new pod template means a new ReplicaSet. The Deployment moves pods from the old one to the new one step by step, and keeps the old ReplicaSet at zero replicas so kubectl rollout undo can scale it back up. Pods are never changed in place, and deleting everything first would cause an outage.