Why Kubernetes Exists and How It Really Works

A story to begin with

That system is what Kubernetes provides. Its job, in one sentence: you describe what you want running, and Kubernetes continuously works to make reality match that description.

The problem in three parts

1. Packaging. Containers solve "it works on my machine" by bundling an app with its dependencies into an image that runs the same everywhere.
2. Placement. With dozens or thousands of containers, something has to decide which machine runs which one, based on free CPU, memory and rules you set.
3. Care and feeding. Containers crash, machines fail and traffic changes. Something has to restart, replace, scale and reconnect things all day, without a human in the loop.

Kubernetes handles the second and third problems, and gives you a common API for describing them.

The big idea: desired state and reconciliation

Almost everything in Kubernetes follows one loop.

flowchart LR
  A[You declare desired state<br/>3 copies of web, version 2] --> B[API server stores it]
  B --> C[Controller compares<br/>desired vs actual]
  C --> D{Different?}
  D -- yes --> E[Take action:<br/>create, delete, update]
  E --> C
  D -- no --> F[Do nothing, keep watching]
  F --> C
  style C fill:#6366f1,color:#fff
  style E fill:#22d3ee,color:#012

You never tell Kubernetes "start container X on machine Y". You say "I want three healthy copies of this app". If a machine disappears and two copies vanish, a controller notices the difference and creates two new ones elsewhere. This is called a control loop, and the cluster is a large collection of them, each watching one kind of object. Once this clicks, the rest of Kubernetes stops feeling random.

What is in a cluster

flowchart TB
  subgraph CP[Control plane: the brain]
    API[API server<br/>front door for everything]
    ETCD[(etcd<br/>cluster database)]
    SCH[Scheduler<br/>picks a node for each pod]
    CM[Controllers<br/>reconciliation loops]
  end
  subgraph N1[Worker node 1]
    K1[kubelet<br/>runs and reports pods]
    P1[Pod]
    P2[Pod]
  end
  subgraph N2[Worker node 2]
    K2[kubelet]
    P3[Pod]
  end
  U[You: kubectl or CI] --> API
  API <--> ETCD
  SCH --> API
  CM --> API
  K1 --> API
  K2 --> API
  style API fill:#6366f1,color:#fff
  style ETCD fill:#22d3ee,color:#012

The objects you will use every day

What happens when you deploy something

sequenceDiagram
  participant U as You
  participant A as API server
  participant E as etcd
  participant D as Deployment controller
  participant S as Scheduler
  participant K as kubelet on a node
  U->>A: kubectl apply deployment.yaml
  A->>E: store the Deployment
  D->>A: sees new Deployment, creates ReplicaSet and Pods
  S->>A: sees unscheduled Pods, assigns a node
  K->>A: sees a Pod assigned to me
  K->>K: pull image, start containers
  K->>A: report Pod Running and Ready

Notice that nothing talks directly to anything else: every component only talks to the API server, watching for changes that concern it. That loose coupling is why Kubernetes is extensible and why it recovers well from failures.

Your first look

# deployment.yaml: "I want three copies of this web app"
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 3
  selector:
    matchLabels: {app: web}
  template:
    metadata:
      labels: {app: web}
    spec:
      containers:
      - name: web
        image: nginx:1.27
        ports: [{containerPort: 80}]

kubectl apply -f deployment.yaml     # declare the desired state
kubectl get pods                     # see three pods appear
kubectl delete pod <one-pod-name>    # break something on purpose
kubectl get pods                     # a replacement is already starting

That last step is the whole value proposition: you deleted a pod, and the system quietly put it back.

What Kubernetes does not do

• It does not make a badly designed application reliable. It makes good practices easier to automate.
• It is not a free lunch: you take on a platform with its own learning curve, upgrades and security duties.
• It does not remove the need for monitoring, backups and incident response.
• It is not the right answer for every workload. A single small app may be better on a managed platform or simple containers.

How to decide and adopt it in your organization

Many teams adopt Kubernetes because it is fashionable, then struggle. A calm, staged approach works better.

flowchart TD
  A[Do we have the problem?<br/>many services, frequent releases,<br/>scaling and recovery pain] -->|no| B[Stay simple:<br/>managed app platform or plain containers]
  A -->|yes| C[Choose managed Kubernetes<br/>from a cloud provider]
  C --> D[Pilot: one non-critical service]
  D --> E[Platform basics:<br/>namespaces, RBAC, CI/CD,<br/>monitoring, backups]
  E --> F[Migrate services in waves]
  F --> G[Improve: autoscaling, policy,<br/>cost control, GitOps]
  style C fill:#6366f1,color:#fff
  style D fill:#22d3ee,color:#012

Step 1: write down the problem. List the pains you expect Kubernetes to fix (slow releases, manual scaling, noisy deployments). If you cannot name any, wait.

Step 2: prefer a managed control plane. Services such as EKS, GKE and AKS run the control plane for you. Operating your own control plane is a specialist job; start managed.

Step 3: run a pilot. Pick one stateless, non-critical service with a willing owning team. Containerise it, deploy it to a small cluster, and learn from every rough edge.

Step 4: build the platform basics before migrating much. Namespaces per team, access control, a CI/CD path to the cluster, logging and metrics, backups of cluster state, and a basic upgrade routine.

Step 5: migrate in waves. Stateless web services first, then batch jobs, and only later stateful systems.

Step 6: measure. Track release frequency, time to recover from failures, cost per service and on-call load before and after, so you can show the value.

Step 7: train people. Run hands-on workshops and keep a short internal guide for "how we run things on Kubernetes".

Pitfalls

• Moving everything at once, including databases, on day one.
• Running many tiny clusters or one giant shared cluster with no plan for either.
• Skipping resource requests and limits, then wondering why nodes are unstable.
• No owner for the platform, so upgrades fall behind.
• Copying another company's setup without matching your size and skills.

Interview questions

Q1. What problem does Kubernetes solve? It automates running containers at scale: placing them on machines, restarting and replacing failures, scaling, rolling out updates and connecting services, driven by a declarative description of the desired state.

Q2. Explain the control loop idea. Each controller repeatedly compares the desired state stored in the API with the observed actual state and takes actions to close the gap. This is why deleted pods return and why the system self-heals.

Q3. Name the control plane components and their roles. The API server (front door), etcd (state store), scheduler (assigns pods to nodes) and controller manager (runs reconciliation loops). Nodes run the kubelet, a container runtime and networking components.

Q4. What happens when you run kubectl apply on a Deployment? The API server validates and stores it. The Deployment controller creates a ReplicaSet and pods, the scheduler assigns nodes, and each node's kubelet pulls images and starts the containers, reporting status back through the API server.

Q5. When would you not use Kubernetes? When you have one or a few simple applications, no scaling or release pain, or no capacity to run and secure a platform. A managed app platform or simple container hosting is often better.

Q6. Why start with a managed Kubernetes service? It removes the burden of operating the control plane, upgrades and etcd, so the team can focus on workloads and platform basics.

Next: Containers and Images covers the building block everything here depends on.