What Is Kubernetes and How Does It Work?

The problem Kubernetes solves

Containers are great for packaging applications. A container bundles your code, its runtime, and its dependencies into a single portable unit. Run it anywhere and it behaves the same way.

But containers alone do not solve the operational problems of running software at scale. What happens when a container crashes? Who restarts it? If traffic spikes, who starts more containers? If a machine goes down, who moves the containers to healthy machines? How do containers on different machines find and talk to each other?

Before Kubernetes, teams wrote custom scripts and used separate tools to handle each of these problems. It was fragile and inconsistent. Kubernetes made these capabilities standard and built-in.

What Kubernetes actually does

Kubernetes is a container orchestration platform. Orchestration means coordinating many moving parts. Kubernetes handles:

• Scheduling — deciding which machine (node) runs which container based on available resources
• Self-healing — restarting containers that crash, replacing containers on failed nodes
• Scaling — adding or removing containers based on load
• Networking — giving every container its own IP address and letting containers find each other by name
• Configuration management — passing environment variables, secrets, and config files to containers
• Rolling updates — updating your application without downtime by replacing containers incrementally

You describe the desired state — “I want three copies of my web server running” — and Kubernetes continuously works to make reality match that description.

The cluster architecture

A Kubernetes cluster consists of two types of machines: the control plane and worker nodes.

The control plane

The control plane is the brain of the cluster. It makes decisions about scheduling, watches for state changes, and responds to events. The control plane runs these components:

• API Server — every action goes through here. kubectl talks to the API server. Everything in Kubernetes is an API call.
• etcd — a distributed key-value store that holds the entire cluster state. If etcd goes down, Kubernetes cannot make decisions.
• Scheduler — watches for new pods with no assigned node and picks the best node to run them on.
• Controller Manager — runs background loops that watch cluster state and drive it toward the desired state. Responsible for restarts, replica counts, and more.

In Azure Kubernetes Service, Microsoft manages the control plane entirely. You never touch etcd or the API server directly.

Worker nodes

Worker nodes are the machines that actually run your containers. Each node runs:

• kubelet — an agent that communicates with the API server and ensures containers are running as instructed
• kube-proxy — handles network rules so containers can communicate
• Container runtime — the software that actually starts and stops containers (containerd is standard)

In AKS, your worker nodes are Azure Virtual Machines. You pay for these. You do not pay for the control plane.

Core Kubernetes objects

Everything in Kubernetes is an object — a record of intent stored in etcd. Here are the most important ones:

Declarative configuration and desired state

The most important idea in Kubernetes is declarative configuration. You write YAML files describing what you want — not instructions for how to get there. Kubernetes figures out the how.

Here is the simplest possible deployment YAML:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello-world
spec:
  replicas: 3
  selector:
    matchLabels:
      app: hello-world
  template:
    metadata:
      labels:
        app: hello-world
    spec:
      containers:
      - name: hello-world
        image: nginx:1.25
        ports:
        - containerPort: 80

This tells Kubernetes: “Keep three copies of an nginx container running, and label them app=hello-world.” You apply this file and Kubernetes makes it happen. If a pod crashes, Kubernetes starts a replacement. You never had to write a restart script.

Apply it with:

kubectl apply -f hello-world.yaml

Check the result:

kubectl get pods
kubectl get deployments

The reconciliation loop

Kubernetes runs a continuous reconciliation loop. It constantly compares the actual state of the cluster to the desired state you declared. When they diverge, it acts to fix the difference.

This is why Kubernetes is self-healing. If you say “I want 3 replicas” and one pod dies, the actual count drops to 2. Kubernetes detects the mismatch and creates a new pod to restore the count to 3.

This also means you should never fight Kubernetes by deleting pods manually and expecting them to stay gone. If a deployment says 3 replicas, a deleted pod will always come back. To stop a pod from running, you change the desired state — reduce replicas to 0 or delete the deployment.

# Scale down to 0 replicas
kubectl scale deployment hello-world --replicas=0

# Delete the deployment entirely
kubectl delete deployment hello-world

Labels and selectors

Labels are key-value pairs you attach to any Kubernetes object. They are how Kubernetes ties objects together. A Deployment uses a selector to find which pods it manages. A Service uses a selector to find which pods to send traffic to.

# See labels on running pods
kubectl get pods --show-labels

# Filter pods by label
kubectl get pods -l app=hello-world

# Add a label to a pod
kubectl label pod my-pod environment=production

Labels seem simple but they are fundamental. Get comfortable with them early.

Essential kubectl commands to know now

kubectl is the command-line tool for interacting with any Kubernetes cluster. Here are the commands you will use constantly:

# View cluster info
kubectl cluster-info

# List all nodes
kubectl get nodes

# List all pods across all namespaces
kubectl get pods -A

# Get detailed info on a resource
kubectl describe pod my-pod-name

# Stream logs from a pod
kubectl logs -f my-pod-name

# Open a shell inside a running pod
kubectl exec -it my-pod-name -- /bin/sh

# Apply a YAML manifest
kubectl apply -f my-file.yaml

# Delete a resource
kubectl delete -f my-file.yaml

You will use these hundreds of times. Run them against a real cluster and the concepts will click faster than any amount of reading.

Kubernetes is not a replacement for Docker

A common confusion: Docker builds images; Kubernetes runs them. They work together but do different things. You use Docker (or another tool like Buildah) to create a container image, push it to a registry, and then reference that image in your Kubernetes YAML. Kubernetes pulls and runs the image — it does not build it.

In Azure, you would typically store images in Azure Container Registry and run them in AKS. The flow is: build image → push to ACR → reference in AKS deployment → Kubernetes pulls and runs it.

Why use AKS instead of running Kubernetes yourself

Running Kubernetes from scratch means managing the control plane yourself — keeping etcd healthy, upgrading API server versions, handling control plane failures. This is difficult work that takes significant expertise.

Azure Kubernetes Service handles the control plane so you only manage worker nodes. You get:

• Automatic control plane upgrades
• Built-in integration with Azure AD, Azure Monitor, and Azure networking
• One-command cluster creation
• No charge for the control plane (you only pay for nodes)

For almost every team, AKS is the right choice over self-managed Kubernetes on Azure.