Kubernetes architecture becomes easier to operate when you stop seeing it as a pile of YAML and start seeing it as a distributed control system. You declare a desired state, controllers compare it with reality, and the platform continuously works to close the gap.

This practical guide follows a request from kubectl to the API server, through scheduling, Pod creation and ongoing reconciliation. It explains which components belong to the control plane, which run on every node, and what production teams should monitor under pressure.

What you will learn

  • The API server is the front door for cluster state; other components coordinate through the Kubernetes API.
  • The scheduler chooses a node, while the kubelet turns the accepted Pod specification into running containers.
  • Controllers continuously reconcile desired and observed state instead of executing a one-time deployment script.
  • High availability requires resilient control-plane endpoints, tested backups and worker capacity across failure domains.

The declarative model and reconciliation loop

A Kubernetes object is a record of intent. A Deployment stores an image, replica count, update policy, labels, resources and health checks. Controllers watch that state and take small, repeatable actions until the observed system matches it.

This model enables self-healing. If a node disappears, the replica count falls and replacement Pods are scheduled elsewhere. The same pattern powers rollouts, Jobs, autoscaling and operators built with custom resources.

Control-plane components

The kube-apiserver validates requests and exposes the API. etcd stores authoritative cluster state. The scheduler assigns unscheduled Pods to nodes. The controller manager runs reconciliation loops for Deployments, Nodes, Jobs and other resources.

Protect the control plane as critical infrastructure: restrict API reachability, use strong identity, export audit logs, monitor API latency and protect etcd with encryption plus restoration-tested backups.

What runs on worker nodes

Each node runs a kubelet that watches Pods assigned to it and works with a CRI-compatible runtime. A networking component implements Service traffic rules, while a CNI plugin provides Pod connectivity. The exact implementation varies by distribution.

The kubelet reports node and Pod status to the API. Troubleshoot in layers: workload object, Pod conditions, recent events, image pulls, volumes, container logs, Service endpoints and node health.

From Deployment to a running Pod

The Deployment controller creates a ReplicaSet, which creates Pod objects. The scheduler filters and scores nodes, then records a binding. The kubelet on that node pulls images, prepares networking and volumes, and asks the runtime to start containers.

A running process is not necessarily ready for traffic. Readiness controls Service endpoints, liveness can restart a stuck container, and the Deployment controller continues to evaluate rollout progress and availability.

Essential diagnostic commands

Use a small set of commands to connect desired state with runtime evidence. Events often explain Pending Pods, failed mounts and image pulls faster than application logs.

Avoid starting with random restarts. First identify which control loop is unable to reach its desired state, then correct the responsible layer.

kubectl get nodes
kubectl get pods -A -o wide
kubectl describe pod <pod-name> -n <namespace>
kubectl get events -n <namespace> --sort-by=.lastTimestamp

Production architecture decisions

Separate workloads by ownership and trust boundaries. Define resource requests, spread replicas across nodes and zones, and use disruption budgets when voluntary maintenance could remove too much capacity.

A highly available cluster does not automatically make an application highly available. Critical services also need multiple replicas, safe rollouts, graceful shutdown, dependency timeouts, data backups and enough spare capacity for rescheduling.

Production checklist

  • Use a redundant or managed control plane with a documented availability target.
  • Encrypt and back up etcd, then test restoration regularly.
  • Set resources, probes and multiple replicas for critical workloads.
  • Spread replicas across failure domains and reserve rescheduling capacity.
  • Monitor API latency, node readiness, restarts and rollout health.
  • Keep versions within the support and version-skew policy of your distribution.

Frequently asked questions

Is the control plane the same as a master node?

Control plane is the preferred term because it describes a set of components and responsibilities, commonly replicated or delivered as a managed service.

Does Kubernetes run containers directly?

No. The kubelet coordinates with a CRI-compatible container runtime while Kubernetes manages the desired workload state.

Why is etcd important?

etcd stores authoritative API state. Losing it without a recoverable backup can mean losing cluster configuration even when application data lives elsewhere.

Continue learning Kubernetes

Official Kubernetes references