Kubernetes: what is it and how it works

What is Kubernetes?

Kubernetes (often abbreviated as K8s) is the open-source platform that has become the de facto standard for managing containerised workloads at scale. Its name comes from the Greek for “helmsman” or “pilot” – a fitting image for a tool whose job is to steer fleets of containers across heterogeneous infrastructure.

Originally created by a team of Google engineers and donated to the Cloud Native Computing Foundation (CNCF) in 2015, Kubernetes is today maintained by one of the largest open-source communities in the world. According to the CNCF Annual Cloud Native Survey 2025 (published January 2026), 82% of container users now run Kubernetes in production, and 66% of organisations running generative-AI workloads use Kubernetes to manage some or all of their inference workloads.

For sysadmins and MSPs, the value proposition is straightforward: a declarative system that continuously reconciles the desired state of your applications against their actual state, automating everything from rollouts to recovery. The most recent stable release, Kubernetes v1.36 “Haru”, was published on 22 April 2026 and confirms the project’s direction toward stronger isolation, AI workload support, and a more secure default posture.

If you are wondering how Kubernetes relates to other container tools, check out our full guide: Docker vs Kubernetes in 2026: how they differ and how they work together.

Kubernetes cluster architecture

Every Kubernetes deployment is organised as a cluster, which consists of two main layers:

• The control plane: the set of components that manage the overall state of the cluster – which applications should be running, which container images they use, and how resources are allocated.
• The worker nodes: the machines (physical or virtual) where your containerised workloads actually run.

A production-grade cluster is designed to be:

• Highly available. The control plane can be replicated across multiple machines to avoid a single point of failure. In production, best practice is to run at least three control-plane nodes.
• Declarative. You describe the desired state of your application in YAML or JSON configuration files, and Kubernetes continuously works to match the actual state to the desired state. These manifests are typically version-controlled in Git, forming the basis of a GitOps workflow.
• Extensible. Kubernetes is not tied to any specific vendor and supports custom resources, operators, and plugins to adapt to virtually any workload.

Terminology note: the term “master” used in older Kubernetes documentation has been replaced project-wide by “control plane” since 2020. If you read legacy guides, treat the two as equivalent.

Control plane components

The control plane is the decision-making layer of the cluster. It exposes the Kubernetes API, stores the cluster state, and runs the controllers that reconcile the desired state with reality. In production, control-plane components are deployed across at least three nodes for high availability.

kube-apiserver

The API server is the central access point for all interactions with the cluster. Every command you run with kubectl, and every internal communication between components, goes through the API server. It validates and processes RESTful requests, handles authentication and RBAC, and is the only component that talks directly to etcd. It then updates the cluster state accordingly.

etcd

etcd is a distributed, consistent key-value store that serves as the single source of truth for the entire cluster state – including configuration data, the status of nodes and pods, secrets, and service-discovery information. Losing etcd means losing the cluster state, which is why backing up etcd regularly and encrypting it at rest are critical operational requirements in production environments.

kube-scheduler

The scheduler watches for newly created pods that have no node assigned and selects the best node for each pod based on resource requirements, hardware constraints, affinity/anti-affinity rules, taints, tolerations, and other scheduling policies.

kube-controller-manager

The controller manager runs a set of controller loops that continuously monitor the cluster state and take corrective action. Key controllers include:

• Node controller: monitors node health and responds when nodes become unreachable.
• ReplicaSet controller: ensures the desired number of pod replicas is running at all times.
• Endpoint controller: populates the endpoint objects that connect Services to pods.
• Job controller: manages pods that run to completion (batch workloads).

cloud-controller-manager

The cloud-controller-manager handles integration with the underlying cloud provider: load balancers, persistent volumes, and node lifecycle. It is only present in cloud-hosted clusters and separates cloud-specific logic from the core Kubernetes controllers.

Worker node components

Each worker node runs the components needed to execute and manage containers and reports status back to the control plane.

kubelet

The kubelet is an agent that runs on every node. It registers the node with the control plane, receives pod specifications from the API server, and ensures the containers described in those specs are running and healthy. If a container crashes, the kubelet restarts it.

Container runtime

The container runtime is the software responsible for actually pulling images and running containers. Kubernetes requires a runtime that implements the Container Runtime Interface (CRI). The two most widely used runtimes are:

• containerd – the industry-standard runtime, originally extracted from Docker Engine and now a graduated CNCF project. It is the default runtime in most managed Kubernetes services (EKS, GKE, AKS), kubeadm, and K3s.
• CRI-O – a lightweight runtime built specifically for Kubernetes, used by default in Red Hat OpenShift.

Note: Docker Engine was supported as a Kubernetes runtime through a component called dockershim, which was removed in Kubernetes 1.24 (May 2022). Docker images remain fully compatible with all CRI-compliant runtimes – only the runtime interface has changed.

kube-proxy

kube-proxy runs on each node and manages the network rules that enable the Service abstraction. It handles service discovery and load balancing by maintaining iptables or IPVS rules that route traffic to the correct pod endpoints, allowing communication to your pods from inside and outside the cluster.

Pods: the smallest deployable unit

A pod is the smallest unit that Kubernetes manages. A pod encapsulates one or more containers that share the same network namespace (IP address and ports), storage volumes, and lifecycle. In most cases a pod runs a single container, but multi-container pods are used for patterns like sidecars, init containers, and log collectors.

In production, pods are almost never created directly. They are managed by higher-level objects – Deployments, StatefulSets, DaemonSets – that handle replication, rolling updates, and scheduling policy.

You can create a simple pod with a YAML manifest:

apiVersion: v1
kind: Pod

metadata:

  name: my-nginx

spec:

  containers:

  - name: nginx

    image: nginx:alpine

    ports:

    - containerPort: 80

Apply it with:

$ kubectl apply -f my-nginx.yaml

$ kubectl get pods

Operators interact with the cluster through the kubectl command-line tool, which sends declarative YAML manifests to the kube-apiserver.

How it all works together in Kubernetes

Here is what happens when you deploy an application to a Kubernetes cluster:

1. You submit a deployment manifest to the API server (via kubectl apply).
2. The API server validates the request and stores the desired state in etcd.
3. The scheduler detects new pods without an assigned node and selects the best node for each.
4. The kubelet on the selected node pulls the container image and starts the container through the container runtime.
5. The controller manager continuously monitors the running state. If a pod crashes or a node fails, it creates replacement pods to match the desired state.
6. kube-proxy updates network rules so that traffic can reach the new pods.

This reconciliation loop runs continuously – Kubernetes does not just deploy your application, it actively maintains it.

What are the advantages of Kubernetes in 2026?

The original promise of Kubernetes – orchestrating containers on multiple hosts, automating deployments, managing scaling – still holds. What has changed in 2026 is the maturity and breadth of what is available out of the box.

Declarative and self-healing infrastructure. The entire desired state of the cluster lives in YAML manifests, version-controlled in Git and reconciled automatically. Failed pods are restarted, failed nodes drained, capacity adjusted by HPA, VPA and Cluster Autoscaler (or Karpenter on EKS) without operator intervention.

Workload portability. The same manifests run on EKS, GKE, AKS, OpenShift, on-premises kubeadm clusters, or K3s at the edge. No other platform offers comparable portability – a real argument for MSPs who manage heterogeneous customer estates.

Modern security posture. Since v1.25, the Pod Security Admission controller enforces the Pod Security Standards (Privileged, Baseline, Restricted) through namespace labels. In v1.36, User Namespaces graduated to Stable, providing a critical defence-in-depth layer that maps container root to a non-privileged user on the host – a long-awaited mitigation against container breakout vulnerabilities.

AI and ML workloads as first-class citizens. Dynamic Resource Allocation (DRA) graduated to GA in v1.34 and has continued to mature through v1.36 with additional features reaching stable, making Kubernetes the standard platform for GPU scheduling, gang scheduling for distributed training, and inference serving.

A managed-service ecosystem. Amazon EKS, Google GKE, and Azure AKS remove the burden of running the control plane and integrate natively with cloud identity (IRSA, Workload Identity, Entra ID), making them the default choice for organisations and MSPs without dedicated platform teams. For a detailed comparison, read our article on Kubernetes Cloud services.

A mature operational ecosystem. Observability (Prometheus, Grafana, OpenTelemetry), GitOps (Argo CD, Flux), backup (Velero), policy enforcement (Kyverno, OPA Gatekeeper), and service mesh (Istio, Linkerd, Cilium) are all production-grade open-source projects under active CNCF stewardship.

What this means for sysadmins and MSPs

Kubernetes in 2026 is a mature, security-hardened, AI-ready platform – but one that demands ongoing operational discipline. The project follows a four-month release cycle and an N−2 support policy: the supported branches are v1.34, v1.35, and v1.36, while v1.33 remains in maintenance mode until its end of life on 28 June 2026. Deferring upgrades is no longer a viable strategy, and one critical migration is now on every roadmap – the community Ingress NGINX project has been officially retired since March 2026, with the Gateway API as the recommended successor for traffic management.

For sysadmins and MSPs, the operational case rests on three points:

• Declarative infrastructure that scales without growing the team.
• Workload portability across any environment.
• An ecosystem mature enough to deliver platform services to customers at margins that simply were not possible a decade ago.

If you manage Kubernetes clusters in production, protecting your data is critical – especially the etcd state and persistent volumes. Uranium Backup supports backup of virtual machines, databases, and the infrastructure that powers your containerised environments.

Frequently Asked Questions on Kubernetes

What are the main components of Kubernetes?

Kubernetes consists of a control plane (kube-apiserver, etcd, kube-scheduler, kube-controller-manager) and worker nodes running kubelet, kube-proxy and a container runtime. The default runtime since Kubernetes 1.24 is containerd.

What is the difference between Docker and Kubernetes?

Docker is a tool for building and running individual containers. Kubernetes is an orchestration platform that manages fleets of containers across multiple hosts, handling scheduling, scaling, self-healing and rolling updates automatically.

Which versions of Kubernetes is supported in 2026?

As of mid-2026, the supported branches are v1.34, v1.35 and v1.36 (the latest stable release). Kubernetes follows an N-2 support policy with a 4-month release cycle. v1.33 v1.33 reaches end of life on 28 June 2026.

Is Kubernetes a good fit for MSPs?

Yes, particularly through managed services like Amazon EKS, Google GKE and Azure AKS, which remove control plane management overhead. The main advantage for MSPs is workload portability: the same manifests run across cloud providers and on-premises environments without changes.