The evolutionary path for virtual infrastructure in enterprise data centers has converged on a single platform. Historically, convergence meant vendor lock-in. This time it does not — because Kubernetes is open-source, governed by the Cloud Native Computing Foundation (CNCF), and backed by every major cloud and platform vendor.
This article is an independent technical explanation of Kubernetes for DevOps engineers and technical decision-makers. It draws on the subject matter originally summarised in a ZDNet overview published in October 2019.
What Is Kubernetes?
Kubernetes is an open-source workload orchestration and distribution system for clustered servers. It ensures resource availability, accessibility, and balanced execution for multiple services running concurrently across a pool of machines.
In practical terms, Kubernetes lets any number of servers — physical or virtual, on-premises or in the cloud, separated by any distance — share workloads for a common set of tenants. It then exposes those workloads to clients as services: a client system contacts a service over the network, passes data to it, and receives a response. The underlying server or servers handling that request are invisible to the caller.
This model — distributed data processing, previously locked inside monolithic applications — is what Kubernetes brings into the open, making it observable and manageable at scale.
One of Kubernetes’ most celebrated capabilities is horizontal scaling. As client demand for a particular workload rises, the orchestrator provisions more replicas of it. As demand falls, it removes them. When applications are decomposed into microservices — independent functions that communicate over the network rather than through shared memory — Kubernetes can scale individual microservices up and down independently, just as it would a complete application.
The Business Case for Kubernetes
Kubernetes is not purely a technology argument; it is an economic one. The costs of maintaining aging, monolithic infrastructure are rising, while the business case for replacing it with modern, distributed architectures is strengthening across several dimensions:
- First-generation virtualisation is ageing. Classic VM-based cloud infrastructure — where a server image runs on a remote hypervisor as if it were local — is being supplanted by container-based models that do not require software to behave as it always has. The business case for monolithic application development is eroding, even in high-complexity domains like massively multiplayer gaming.
- Service meshes are replacing address-based routing. The internet’s DNS system maps addresses to owners, not to functions. Service meshes overlay that system with function-aware maps, enabling distributed applications to locate each other across dispersed networks. These meshes are tightly integrated with Kubernetes.
- Client-side compute assumptions are shifting. Mobile applications pushed intelligence to the client partly to conserve wireless bandwidth. As bandwidth becomes less of a constraint, it may become practical to shift more logic back to the server side, enabling a new generation of lighter-weight client devices.
- Edge and distributed data centres are emerging. Hyperscale public cloud facilities serve tens of thousands of tenants from centralised locations, often hundreds of miles from end users. Highly distributable compute makes smaller, geographically dispersed data centres more viable and, in latency-sensitive applications, more desirable.
- AI workloads can be decomposed. Machine learning and inference workloads are resource-intensive in monolithic form. Distributed, containerised service models can reduce per-component footprint, potentially making AI capabilities far more pervasive in everyday software.
- Containerisation simplifies software delivery. Containers package workloads as portable, self-contained units hosted by an operating system (rather than a hypervisor). Code is pulled from a registry and deployed directly into production. This enables continuous deployment — updates daily rather than quarterly — and improves both operational integrity and security posture.
What “Orchestration” Actually Means
Orchestration is the coordinated management and execution of multiple workloads sharing an IT platform. In Kubernetes’ case, workloads often arrive pre-decomposed into microservices — independent units that cooperate but run separately. Kubernetes orchestration allows those units to be replicated, redistributed, and retired as demand requires.
A common misconception is that an orchestrator plays the role of a conductor — keeping everything in time and rhythm. That is actually the operating system’s role; Kubernetes does not change it. The orchestrator’s job is closer to that of a logistics coordinator: ensuring that every part of a composition has the resources it needs, that no single part starves the others, and that the whole performs efficiently even when its components are spread across multiple locations.
Orchestrator vs. Operating System
An operating system marshals the safe execution of programs on a single machine. Kubernetes fulfils an analogous role across a cluster: it oversees the execution of workloads across a pool of servers whose processing, memory, storage, and networking resources have been collectively abstracted.
This does not make Kubernetes a distributed operating system. Each node’s OS still governs program execution at the machine level. In a containerised environment, the container’s host is the OS — not a hypervisor, as in vSphere or KVM. Kubernetes operates one level above this, coordinating across nodes rather than within them.
Registries, Deployment, and the Concept of a Workload
In the modern data centre, software is not installed in the traditional sense. Instead, it is stored in a registry — a repository of container images — and pulled on demand. Making a containerised application available via a registry for introduction into a Kubernetes-managed cluster is called deployment.
A workload is a running deployment: one or more software components operating together as a cohesive unit with a defined purpose. Developers still write programs; but in the act of packaging those programs into containers and declaring their operating parameters to Kubernetes, the software becomes a workload whose resource consumption can be measured, managed, and constrained.
Services, APIs, and Serverless Functions
A service, architecturally, is software that accepts specified inputs and produces predictable outputs — independently of any user interface. A microservice is a self-contained, self-reliant service, typically focused on a single function. Kubernetes’ core competency is orchestrating services and microservices.
An API (Application Programming Interface) is a collection of services with a defined communication protocol, typically addressed over HTTP. Kubernetes orchestrates the services that respond to those API calls.
A serverless function is an extreme form of service abstraction: the caller does not address any specific server or cluster. The infrastructure details are resolved transparently by the platform, giving the caller the impression that the function runs locally. From an orchestration standpoint, serverless functions are workloads like any other — Kubernetes (or a serverless layer built on top of it) handles the placement and scaling.
The Components of Kubernetes
Understanding Kubernetes requires separating its control plane (the brain) from its data plane (the workers).
The Control Plane
The control plane is an isolated network of components responsible for governing the cluster. It contains three primary components:
- kube-apiserver — The API server validates and processes all incoming requests, including requests directed to services running inside pods. It is the single entry point to the cluster’s control logic.
- kube-controller-manager — A collection of controllers, each responsible for managing a specific type of cluster resource. For example, a Job controller handles batch workloads assigned to pods. Critically, Kubernetes allows additional controllers to be added, making it capable of orchestrating resources beyond containers.
- kube-scheduler — The scheduler assigns pods to worker nodes. When a new pod needs to be placed, the scheduler evaluates the current state of available nodes and delegates the pod to whichever node is best positioned to handle it.
Controllers watch the cluster’s state continuously. When an event signals a change — a node fails, demand spikes, a deployment is updated — the controller evaluates the situation and triggers the appropriate response. Operators are specialised controllers that encode the operational knowledge needed to manage complex, stateful applications automatically.
Pods: The Scheduling Unit
The basic scheduling unit in Kubernetes is the pod — a group of one or more containers that share a network namespace and storage volumes, and are always co-located and co-scheduled on the same node. Kubernetes schedules pods, not individual containers.
The Data Plane: Nodes and kubelet
Every server in the cluster — physical or virtual — is a node. Worker nodes run workloads. Each worker node runs a local agent called kubelet, which receives instructions from the control plane and manages the containers running in pods on that node. It is kubelet that interfaces with the container runtime.
Docker’s runC was for a long time the de facto container runtime in Kubernetes. The Kubernetes project has since developed its own alternative, CRI-O, which implements the Container Runtime Interface (CRI) directly and is the preferred runtime for distributions such as Red Hat OpenShift.
Manifests: Declaring Intent
Each workload is described to Kubernetes by a manifest — a YAML file that declares the desired state of the object: what container image to run, how many replicas to maintain, what storage and network resources to request, and under what conditions to restart. Kubernetes continuously reconciles the actual state of the cluster with the declared desired state in these manifests.
Custom Resource Definitions (CRDs): Extending Kubernetes Beyond Containers
One of the most consequential architectural decisions in Kubernetes is the Custom Resource Definition (CRD) mechanism. CRDs allow operators to teach Kubernetes to recognise and orchestrate resources that are not containers. Practically, this means Kubernetes can be extended to manage:
- Virtual machines — VMware has invested in making Kubernetes a first-class VM orchestrator via projects such as KubeVirt and its own Tanzu portfolio.
- Large-scale data workloads — Frameworks such as Apache Spark can be provisioned and managed through Kubernetes operators, replacing dedicated cluster managers for many use cases.
- HPC workloads — High-performance computing schedulers such as Slurm have historically governed supercomputer workloads. Kubernetes is increasingly evaluated as an alternative or complement as it approaches broader adoption.
- Machine learning pipelines — Projects like Kubeflow allow Kubernetes to orchestrate the databases, schedulers, and training jobs that ML workloads require, even where Kubernetes itself lacks native support for deterministic scheduling or large-scale parallel data access.
How Kubernetes Won the Orchestration Wars
The container orchestration market had credible competitors. The battle was decided faster than most observers expected, and for reasons that were not purely technical.
Docker Swarm
Docker Inc. ignited the container revolution and built its own orchestrator, Docker Swarm. Swarm had genuine technical merits: operators reported a significantly lower learning curve than Kubernetes, and its overlay networking model — which separated container-to-container traffic from host traffic on distinct planes — was considered elegant. In multi-cloud scenarios, Swarm’s network segmentation offered practical latency advantages.
Docker’s business philosophy — open-source core with commercial attachments it called “Batteries Included but Replaceable” — led it to found the Open Container Initiative (OCI) in 2015 under the Linux Foundation, standardising container image and runtime formats via runC. In the same week, many of the same organisations announced the Cloud Native Computing Foundation (CNCF), also under the Linux Foundation, whose first major stewardship project would be Kubernetes.
Google threw its full marketing weight behind Kubernetes, branding its managed service as Google Kubernetes Engine (GKE). In enterprise sales conversations at the time, Kubernetes was widely perceived as a Google product. Against Google’s credibility in cloud infrastructure, Docker — a much smaller company — could not compete for perception, regardless of Swarm’s technical qualities.
The CNCF simultaneously built an entire ecosystem around Kubernetes: service discovery, performance monitoring, storage management, security tooling, and more. Docker’s attempts to build a comparable extensibility ecosystem got entangled in internal architectural debates.
Red Hat’s 2015 decision to rebuild OpenShift on Kubernetes proved pivotal. By 2017 Red Hat had become a top-tier Kubernetes contributor. Microsoft hired key open-source engineers — including Brendan Burns, one of the original Kubernetes creators at Google — and rebuilt significant parts of Azure around Kubernetes. The industry alignment became self-reinforcing.
By late 2019, Docker was publicly recommending that users try running Kubernetes and Swarm side by side, acknowledging that Kubernetes had “evolved to add a lot of functionality.”
Apache Mesos
Apache Mesos was the established leader in distributed workload scheduling before Kubernetes arrived. It pioneered the master/worker cluster architecture and was extended into a private PaaS platform called Marathon. Its first major production deployment was at Twitter. In 2013, Mesos engineer Ben Hindman co-founded Mesosphere, the primary commercial vendor for Mesos, which produced DC/OS — an early contender for becoming the default orchestration layer on Microsoft Azure.
Mesos had years of production credibility. But the Kubernetes ecosystem’s momentum proved insurmountable. In 2017, VMware and Pivotal launched a Kubernetes-based platform (Pivotal Container Service). Azure followed by deprioritising DC/OS. Amazon opened its managed Kubernetes service (EKS) in 2018. IBM’s acquisition of Red Hat — and with it, OpenShift — brought another major platform fully into the Kubernetes orbit.
Mesosphere rebranded as D2iQ in 2019 and pivoted to a Kubernetes-centred strategy. The orchestration question was settled.
Where Kubernetes Goes from Here
The central challenge facing organisations adopting Kubernetes is the migration of existing monolithic applications. These are large, tightly coupled systems whose internal logic is opaque to all but their original authors. There are three broad strategies for dealing with them:
- Full decomposition: Rebuild the monolith as a network of microservices that replicate its behaviour. High fidelity, high effort.
- API wrapping: Place an API façade around the monolith and distribute that API through a microservices-friendly network. Lower effort, but the monolith’s internal complexity remains.
- Kubernetes extension via CRDs: Rather than forcing existing workloads to conform to Kubernetes, extend Kubernetes to meet the workloads where they are. Custom controllers and operators can automate the management of workloads that predate the container era entirely.
This third path — Kubernetes adapting to existing workloads rather than the other way around — may prove to be the most consequential long-term contribution of the CRD mechanism. With hundreds of active contributors and broad commercial backing, the Kubernetes project has the capacity to build or adapt controllers for almost any class of workload an enterprise runs.
The original Kubernetes creators predicted that their platform would eventually become so embedded in data centre operations that it would be unremarkable — infrastructure, like TCP/IP. That day has not yet arrived. Kubernetes is still being actively shaped, and decisions made in its project today will define how distributed computing operates for the next decade.