Kubernetes: the practical guide to container orchestration

• What is Kubernetes and why does it exist?
• How does a cluster's architecture work?
• Which objects do you actually need to know?
• How does Kubernetes scale and recover from failures?
• When should you NOT use Kubernetes?
• How do you get started with Kubernetes without suffering?

Kubernetes is the system that keeps containerized applications running the way you declared, without depending on someone being awake to fix them. You describe the desired state in YAML and the cluster continuously reconciles reality with that description.

What is Kubernetes and why does it exist?

Kubernetes (shortened to K8s) is an open source container orchestrator, born from Google's experience with the internal Borg system and donated to the Cloud Native Computing Foundation in 2015. It solves the problem that shows up right after Docker: packaging an application into a container is simple; keeping hundreds of them alive, distributed, updated and reachable is not.

The central concept is the declarative model. You do not give orders ("start two containers on server 3"), you declare a desired fact ("I want three replicas of this image"). A set of controllers compares the current state with the desired one and acts to eliminate the difference — the reconciliation loop.

The practical consequence is operational: a node dies at 3 a.m. and the cluster reschedules the affected Pods onto healthy nodes before anyone wakes up. A deploy breaks and the rollback is one command, because the previous version is still described in the object's history.

Practical example: with plain Docker, if the container process dies on one server, someone has to restart it. With Kubernetes, the kubelet detects the failure, recreates the container and — if the whole node goes down — the scheduler relocates the workload to another node, maintaining the three declared replicas.

How does a cluster's architecture work?

A cluster has two layers: the control plane, which decides, and the worker nodes, which execute.

In the control plane:

• kube-apiserver — the front door. Every command, controller and component talks through it. It is the only piece that speaks to the state store.
• etcd — a distributed key-value store holding the entire cluster state. Losing etcd without a backup is losing the cluster.
• kube-scheduler — decides which node each new Pod runs on, considering available resources, affinities and constraints.
• kube-controller-manager — runs the reconciliation loops (replicas, nodes, endpoints).

On the worker nodes:

• kubelet — the agent that ensures the containers described for that node are running and healthy.
• kube-proxy — maintains the network rules that get traffic to the right Pod.
• container runtime — what actually executes (containerd is the current default).

Practical example: when you run kubectl apply -f deploy.yaml, the apiserver writes the object to etcd, the Deployment controller creates a ReplicaSet, the ReplicaSet requests three Pods, the scheduler picks the nodes and each kubelet pulls the image and starts the container. You declared once; five components did the work.

Which objects do you actually need to know?

The documentation lists dozens of types, but five cover most of day-to-day work:

The minimal manifest for a web application looks like this:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: orders-api
spec:
  replicas: 3
  selector:
    matchLabels: { app: orders-api }
  template:
    metadata:
      labels: { app: orders-api }
    spec:
      containers:
        - name: api
          image: registry.example.com/orders-api:1.4.2
          ports: [{ containerPort: 3000 }]
          resources:
            requests: { cpu: 100m, memory: 128Mi }
            limits: { cpu: 500m, memory: 512Mi }
          readinessProbe:
            httpGet: { path: /health, port: 3000 }

Two fields deserve highlighting because they are the ones beginners most often skip. resources tells the scheduler how much the application needs: without requests, it allocates blindly and the node turns into a fight over CPU. readinessProbe says when the Pod is ready to receive traffic: without it, the Service sends requests to a container that is still starting, and the "zero-downtime" deploy produces 502 errors.

Practical example: a team was investigating sporadic errors on every deploy. The cause was a missing readinessProbe — Kubernetes considered the Pod ready as soon as the process started, ten seconds before the application finished opening its database connections.

How does Kubernetes scale and recover from failures?

Recovery is a direct consequence of the reconciliation loop, and it happens at three levels:

1. Container. If the process dies, the kubelet restarts it according to the defined policy. If the livenessProbe fails repeatedly, the container is restarted even while technically alive — that is how deadlock is detected.
2. Pod. If a Pod is destroyed or the node becomes unavailable, the ReplicaSet notices the drift from the declared count and creates another.
3. Node. If the whole machine disappears, the controller marks the node not ready and relocates the workload; with a cluster autoscaler, a new node is provisioned.

Scalability has two dimensions. The HorizontalPodAutoscaler (HPA) increases the replica count based on metrics — CPU, memory or custom metrics such as requests per second. The Cluster Autoscaler adds or removes nodes when Pods no longer fit on the existing machines.

The combination is what delivers the promise of elasticity: traffic rises, the HPA creates replicas; replicas do not fit, the autoscaler adds nodes; traffic falls, the process unwinds in reverse. Worth remembering that the second step costs real money — and that is exactly where FinOps discipline prevents the end-of-month surprise.

Practical example: an e-commerce site configured the HPA between 3 and 30 replicas at 70% CPU. On Black Friday, the cluster went to 24 replicas and 6 extra nodes at 8 a.m. and returned to the minimum by 2 a.m. the next morning, with nobody touching anything.

When should you NOT use Kubernetes?

This is the section most tutorials omit. Kubernetes is a multiplier of operational capability — and multiplying zero still gives zero. It tends to be the wrong choice when:

1. The application is a monolith with stable traffic. A VM with Docker Compose and a load balancer delivers the same result for a fraction of the effort.
2. The team has nobody dedicated to the platform. A cluster requires maintenance: version upgrades, certificate management, network policies, access control. With no owner, it degrades silently.
3. The product is still searching for market fit. Infrastructure complexity competes directly with iteration speed at the stage where speed is everything.
4. There is a PaaS that fits. Cloud Run, App Runner, Render, Fly.io and Vercel solve managed containers without exposing you to YAML — and several run Kubernetes underneath without charging you the complexity.

The clear signal that the time has come is the opposite: many independent services, teams that need to deploy without coordinating, real elastic scale requirements and multiple environments that must be identical. In that scenario, the pattern naturally evolves toward platform engineering, with the cluster as the base and a self-service layer on top.

Practical example: a five-person startup migrated to Kubernetes "to be ready to scale" and spent six weeks on network and permission problems — with the same traffic as before. It went back to a PaaS and recovered its delivery pace in an afternoon.

How do you get started with Kubernetes without suffering?

A learning roadmap that avoids the most common dead ends:

1. Start local, with a disposable cluster. kind, k3d or minikube spin up a cluster on your machine in minutes. Break it freely, recreate it at no cost.
2. Write YAML by hand before using Helm. Understanding raw Deployment, Service and Ingress is what makes Helm comprehensible later — and not the other way around.
3. Learn to debug before learning to optimize. kubectl describe pod, kubectl logs --previous and kubectl get events --sort-by=.lastTimestamp solve most real problems.
4. Use a managed service for your first production cluster. GKE, EKS or AKS remove control plane operations, which is the hardest and least differentiating part.
5. Treat the cluster as code. Manifests versioned in Git, applied by a pipeline. Manual changes in production are like editing a file directly on the server: it works until the day nobody remembers what was done.

Practical example: a team took its first service to production exactly like that — kind on a laptop for two weeks, a hand-written Deployment, migration to GKE with the same manifests and only then Helm to parameterize environments. Not a single incident on launch.

Conclusion

Kubernetes delivers one very specific and very valuable thing: the ability to describe how your application should be and trust that a system will keep that description true, even when machines fail and traffic swings. The price is real operational complexity — network, permissions, upgrades, debugging — that only pays for itself when scale, service count or team independence justify it. If you are starting out, use a disposable local cluster to understand Pod, Deployment, Service and Ingress by hand, adopt a managed service for your first production deployment and keep everything versioned. And if the honest answer to "why Kubernetes?" is "because everyone uses it", the more mature decision is probably to postpone.