Kubernetes Complete Guide: Architecture, Components and Key Concepts (2026)
Kubernetes has become the de-facto standard for container orchestration at scale. Whether you are running a handful of microservices or thousands of pods across multiple data centres, understanding the core architecture is the foundation for everything else. This guide walks you through every major component — from the API server to the kubelet — explains how they interact, and covers your practical options for spinning up a cluster in 2026.
Table of Contents
What Is Kubernetes?
Kubernetes (K8s) is an open-source container orchestration platform originally developed at Google and donated to the CNCF in 2014. It automates the deployment, scaling, and management of containerised workloads. At its heart, Kubernetes is a desired-state system: you declare what you want (e.g., "run 3 replicas of my API server") and the platform continuously works to match reality to that declaration.
Key capabilities Kubernetes gives you out of the box:
- Bin packing — schedules containers onto nodes to maximise resource utilisation
- Self-healing — restarts failed containers, reschedules pods from failed nodes
- Horizontal scaling — scale workloads up and down manually or automatically
- Service discovery and load balancing — DNS-based discovery and built-in load balancing
- Automated rollouts and rollbacks — deploy new versions with zero downtime
- Secret and configuration management — store and manage sensitive information separately from application code
Control Plane Components
The control plane is the brain of a Kubernetes cluster. It maintains the desired state of the cluster, makes scheduling decisions, and responds to cluster events. In production you always run multiple control-plane replicas for high availability.
kube-apiserver
The API server is the single front-end for the Kubernetes control plane. Every interaction — whether from kubectl, a controller, or a node's kubelet — goes through this RESTful API. It validates and processes requests, persists state to etcd, and serves the Kubernetes API specification.
etcd
etcd is a distributed, strongly-consistent key-value store that serves as Kubernetes' backing store for all cluster data. Every object you create — pods, services, configmaps — is serialised and stored in etcd. Backing up etcd regularly is critical in production.
# Snapshot etcd (run on a control-plane node)
ETCDCTL_API=3 etcdctl snapshot save /backup/etcd-snapshot.db \
--endpoints=https://127.0.0.1:2379 \
--cacert=/etc/kubernetes/pki/etcd/ca.crt \
--cert=/etc/kubernetes/pki/etcd/server.crt \
--key=/etc/kubernetes/pki/etcd/server.keykube-scheduler
The scheduler watches for newly created pods that have no node assigned, then selects the best node based on resource requirements, affinity/anti-affinity rules, taints and tolerations, and topology spread constraints. Scheduling happens in two phases: filtering (eliminate ineligible nodes) and scoring (rank remaining nodes).
kube-controller-manager
This single binary embeds dozens of control loops (controllers). Each controller watches the API server for its resource type and reconciles current state toward desired state. Important controllers include:
- ReplicaSet controller — ensures the correct number of pod replicas exist
- Deployment controller — manages rolling updates via ReplicaSets
- Node controller — monitors node health and evicts pods from unreachable nodes
- Job controller — manages batch workloads to completion
- Endpoints controller — populates Endpoints objects for Services
cloud-controller-manager
When running on a cloud provider (AWS, GCP, Azure), this component interacts with cloud APIs to manage cloud-specific resources: LoadBalancer Services, persistent volumes backed by cloud disks, and node lifecycle management.
Worker Node Components
Worker nodes (also called data-plane nodes) are where your application containers actually run. Each node runs three essential Kubernetes components.
kubelet
The kubelet is an agent that runs on every node. It watches the API server for pods assigned to its node, then instructs the container runtime to start/stop containers as needed. It also reports pod and node status back to the API server, runs liveness/readiness probes, and manages pod volumes.
kube-proxy
kube-proxy maintains network rules on each node that implement Kubernetes Service semantics. In the default iptables mode it programs netfilter rules to intercept traffic destined for Service ClusterIPs and forwards it to one of the backing pod IPs. In ipvs mode it uses Linux IPVS for better performance at large scale (thousands of services).
Container Runtime
Kubernetes delegates container operations to a CRI-compliant runtime. In 2026 the most common choices are:
- containerd — the default runtime for most distributions (extracted from Docker)
- CRI-O — lightweight runtime popular with OpenShift
- Docker Engine — still supported via cri-dockerd shim, though containerd is preferred
kubectl Basics
kubectl is the command-line interface for interacting with a Kubernetes cluster. It communicates with the kube-apiserver using credentials stored in ~/.kube/config.
# Check cluster info
kubectl cluster-info
# View all nodes
kubectl get nodes -o wide
# NAME STATUS ROLES AGE VERSION INTERNAL-IP
# control-plane Ready control-plane 10d v1.30.2 10.0.0.1
# worker-1 Ready <none> 10d v1.30.2 10.0.0.2
# worker-2 Ready <none> 10d v1.30.2 10.0.0.3
# View all pods across all namespaces
kubectl get pods -A
# Describe a resource (great for troubleshooting)
kubectl describe pod my-pod -n production
# View resource usage
kubectl top nodes
kubectl top pods -n productionkubectl config use-context to switch between clusters, and kubectl config get-contexts to list available contexts stored in your kubeconfig.
# Shorthand aliases used by most engineers
alias k=kubectl
alias kgp='kubectl get pods'
alias kgs='kubectl get svc'
alias kgd='kubectl get deploy'
# Get help for any resource type
kubectl explain deployment.spec.strategyNamespaces and Resource Model
Namespaces provide a mechanism for isolating groups of resources within a single cluster. They are useful for multi-team or multi-environment setups (e.g., dev/staging/production in the same cluster).
# Default namespaces after install
kubectl get namespaces
# NAME STATUS AGE
# default Active 10d
# kube-system Active 10d <-- Kubernetes system components
# kube-public Active 10d <-- Public readable resources
# kube-node-lease Active 10d <-- Node heartbeat leases# Create a namespace declaratively
apiVersion: v1
kind: Namespace
metadata:
name: production
labels:
environment: production
team: platformKubernetes resources are divided into namespaced (pods, services, deployments) and cluster-scoped (nodes, persistent volumes, cluster roles). ResourceQuota and LimitRange objects let you control resource consumption per namespace:
apiVersion: v1
kind: ResourceQuota
metadata:
name: production-quota
namespace: production
spec:
hard:
requests.cpu: "20"
requests.memory: 40Gi
limits.cpu: "40"
limits.memory: 80Gi
pods: "200"
services: "30"Cluster Setup Options
kubeadm (self-managed)
kubeadm is the official tool for bootstrapping a production-grade cluster on your own VMs or bare metal. It handles TLS certificate generation, etcd setup, and control-plane component manifests.
# Bootstrap a control-plane node
kubeadm init \
--control-plane-endpoint "k8s-lb.example.com:6443" \
--upload-certs \
--pod-network-cidr=10.244.0.0/16
# Copy kubeconfig
mkdir -p $HOME/.kube
cp /etc/kubernetes/admin.conf $HOME/.kube/config
# Install a CNI plugin (Flannel example)
kubectl apply -f https://raw.githubusercontent.com/flannel-io/flannel/master/Documentation/kube-flannel.yml
# Join a worker node (token from kubeadm init output)
kubeadm join k8s-lb.example.com:6443 \
--token abcdef.0123456789abcdef \
--discovery-token-ca-cert-hash sha256:<hash>k3s (lightweight)
k3s by Rancher is a CNCF-certified Kubernetes distribution that ships as a single ~70MB binary. It is ideal for edge nodes, IoT, CI/CD runners, and development environments. It embeds containerd, Flannel CNI, CoreDNS, Traefik ingress, and SQLite (or embedded etcd) out of the box.
# Install k3s server (single node or first control-plane)
curl -sfL https://get.k3s.io | sh -
# Add an agent node
curl -sfL https://get.k3s.io | K3S_URL=https://myserver:6443 \
K3S_TOKEN=mynodetoken sh -kind (Kubernetes in Docker)
kind runs Kubernetes nodes inside Docker containers. It is the fastest way to spin up a local multi-node cluster for development and CI pipelines.
# kind-config.yaml — 3-node cluster
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
- role: control-plane
- role: worker
- role: workerkind create cluster --config kind-config.yaml --name dev
kubectl cluster-info --context kind-devManaged Cloud Kubernetes
- EKS (AWS) — managed control plane, integrates with IAM, VPC, ALB
- GKE (Google Cloud) — Autopilot mode removes all node management; most mature managed offering
- AKS (Azure) — integrates with Azure AD, Azure CNI, AGIC ingress
Declarative vs Imperative
Kubernetes supports both interaction styles but strongly favours the declarative model in production.
Imperative commands act directly on the cluster and don't leave a record:
kubectl run nginx --image=nginx:1.25
kubectl scale deployment my-app --replicas=5
kubectl expose deployment my-app --port=80 --type=ClusterIPDeclarative management uses YAML manifests stored in version control. kubectl applies your desired state and the cluster reconciles:
kubectl apply -f manifests/ # apply an entire directory
kubectl diff -f manifests/ # preview changes before applying
kubectl delete -f deployment.yamlkubectl apply rather than create — apply is idempotent and safe to run multiple times. Imperative commands are fine for quick debugging and exploration, but never for anything that needs to survive a cluster rebuild.
Frequently Asked Questions
What is the difference between a pod and a container in Kubernetes?
A container is the actual process running your application (e.g., an nginx or Java process). A pod is the smallest deployable unit in Kubernetes — it is a wrapper around one or more containers that share the same network namespace (same IP address and port space) and can share storage volumes. In practice most pods run a single container, but the sidecar pattern uses multiple containers per pod.
How many nodes does a production Kubernetes cluster need?
For high availability you need at least 3 control-plane nodes (so etcd can form a quorum) and a minimum of 3 worker nodes so workloads survive a node failure. For real production workloads, size worker nodes based on your application resource requirements and add headroom for rolling updates (you need spare capacity to absorb pods evicted during a node drain).
Is Docker required to run Kubernetes?
No. Kubernetes uses the Container Runtime Interface (CRI) and works with any CRI-compliant runtime. containerd (which Docker itself uses internally) is now the most common choice. Docker Engine can be used via the cri-dockerd shim, but most new clusters use containerd directly.
What version of Kubernetes should I use in 2026?
The Kubernetes project maintains three concurrent minor version releases. In mid-2026 the supported versions are approximately 1.30, 1.31, and 1.32. For production, stay one minor version behind the latest to benefit from stability patches while staying current enough to receive security updates. Managed offerings (EKS/GKE/AKS) typically lag by one additional minor version.
What is the difference between kubectl apply and kubectl create?
kubectl create creates a resource and errors if it already exists. kubectl apply creates the resource if it doesn't exist, or updates it if it does by computing a three-way merge between the last-applied configuration, the live object, and your new manifest. Always use apply in scripts and CI/CD pipelines.