A single container is easy to run. The problem appears when you have hundreds of them, spread across dozens of machines, that need to recover from failures, scale with demand and be updated without taking the service down. Kubernetes is the orchestrator that takes care of that. It looks intimidating, but the core concept is simple: you declare the desired state and it works to keep reality matching it.
Why orchestration
Running containers manually in production doesn't scale: machines go down, traffic varies, deploys have to happen without downtime. The orchestrator automates scheduling containers onto machines, restarts whatever dies, distributes load and manages updates. You take care of the "what"; it takes care of the "how" and the "where".
Reconciling the desired state
This is the concept that organizes everything else and always comes up in interviews. You declare, in a file, the state you want ("3 replicas of this application"). Kubernetes runs a continuous loop comparing the actual state to the desired one and acting to make them equal. If a pod dies, it creates another. If you ask for 5 replicas, it spins up 2 more.
Kubernetes doesn't execute commands, it chases a goal. You don't say "create a container"; you say "I want three to always exist" — and it keeps that true, no matter what happens.
Pod: the smallest unit
The pod is the smallest unit Kubernetes manages: one or more containers that live together, share a network and are treated as a single thing. In practice, you almost never create pods directly — they are ephemeral and disposable.
Deployment and Service
The Deployment manages a set of identical pods: it guarantees the number of replicas and performs a rolling update (replaces pods gradually during an update, without taking the service down). The Service solves the problem that pods are born and die with different IPs: it provides a stable network address and distributes traffic across the live pods. The namespace separates resources by team or environment within the same cluster.
| Resource | Responsibility | Lifespan |
|---|---|---|
| Pod | Runs the containers | Ephemeral |
| Deployment | Keeps N replicas and handles updates | Long-lived |
| Service | Stable networking + load balancing | Long-lived |
Architecture diagram
Service (IP estável)
|
+---------+---------+
| | |
Pod1 Pod2 Pod3 ← Deployment garante 3 réplicas
| | |
[container][container][container]The user talks to the Service; the Service distributes across the pods; the Deployment guarantees there are always three.
Autoscaling with HPA
The Horizontal Pod Autoscaler automatically adjusts the number of replicas based on metrics such as CPU usage. If traffic goes up, it creates more pods; when it drops, it removes them. This is where observability and orchestration meet: good metrics feed good scaling decisions.
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
spec:
minReplicas: 2
maxReplicas: 10
metrics:
- type: Resource
resource: { name: cpu, target: { averageUtilization: 70 } }Conclusion
Kubernetes stops being scary when you understand the central idea of reconciliation: declare the desired state and let the system chase it. Pods run, Deployments guarantee replicas and smooth updates, Services provide stable networking and the HPA scales on its own. This declarative model, combined with infrastructure as code, is what sustains large, resilient systems — and what is expected of a senior DevOps engineer.