What is Kubernetes and how does container orchestration work?

What is Kubernetes?

Kubernetes is an open-source platform for managing containerized applications and services. The official documentation defines it as "a portable, extensible, open source platform for managing containerized workloads and services that facilitates both declarative configuration and automation."

It is just as important to understand what Kubernetes is not. It is not an AI model, nor a tool for building container images. It is also not a classic PaaS (Platform as a Service) — the documentation explicitly notes that "Kubernetes is not a traditional, all-inclusive PaaS system." The clearest way to describe it is as a container-orchestration layer^?container-orchestration layer: automatically placing, scaling and keeping many containers running across many machines: a system that coordinates the work of many containers spread across many machines so that an application runs reliably, scales, and repairs itself after failures. Kubernetes does not run containers directly — for that it relies on a separate container runtime^?container runtime: the software that actually runs containers on a machine, e.g. containerd or CRI-O.

The name comes from Greek and means "helmsman" or "pilot." The common abbreviation "K8s" derives from the eight letters between the "K" and the "s."

Who is behind it?

Kubernetes originated at Google. The company open-sourced the project in 2014, and according to the documentation it "combines over 15 years of Google's experience running production workloads at scale." Its direct ancestor was Google's internal system called Borg, which managed the company's services at massive scale.

Today the project no longer belongs to Google. In March 2016 Kubernetes was donated to the Cloud Native Computing Foundation (CNCF) — a foundation under the Linux Foundation that acts as a neutral steward for key projects in the "cloud native" ecosystem. On March 6, 2018, Kubernetes became, in the CNCF's own words, "CNCF's first project to graduate" — reaching the highest maturity level. This means Kubernetes is now developed by a distributed, multi-company community rather than a single corporation.

How does it work?

The foundation of how Kubernetes works is the model of desired state and reconciliation loops.

Users do not issue commands like "run this container on that machine right now." Instead, they declare a desired state: for example, "I want three copies of this application running at all times." Kubernetes takes that declaration and works to make reality match it.

The desired state is most often described in YAML files that declare the cluster's resources. A simple Deployment manifest can look like this:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: shop
spec:
  replicas: 3

The replicas: 3 field declares that the Deployment controller should keep three replicas of the application running — one element of the desired state described in the manifest. The desired state, however, covers not only the replica count but also the container image, ports, resources, environment variables, and other parts of the spec.

This is handled by controllers — processes that run in a continuous loop. Each controller constantly watches the current state of the cluster through the central API, compares it with the declared desired state, and takes actions that move one toward the other. If three copies of an application are declared and one of them fails, the controller detects the discrepancy and creates a new copy. The documentation describes this as "a set of independent, composable control processes that continuously drive the current state towards the provided desired state."

This mechanism is the source of Kubernetes' most important traits — self-healing and automation. The system does not wait for an administrator to intervene — it reacts on its own to node failures, crashing containers, and changes in load.

What are its key components?

A Kubernetes cluster is divided into two layers: the control plane, which makes global decisions, and the worker nodes, which run the actual applications.

Let's trace what happens along the way. When a user submits a YAML manifest, it first reaches the kube-apiserver. The information is saved in etcd, then the scheduler picks a suitable node, and the kubelet starts the containers on it. Overseeing all of it are the controllers, which continuously keep the actual state in line with the declared one. The list below shows who is who in that chain.

Control plane

• kube-apiserver — the front end for the entire control plane. It exposes the Kubernetes API through which all operations pass.
• etcd — a consistent, highly-available key-value store that holds all cluster data. The documentation stresses that in production environments it requires a backup plan.
• kube-scheduler — watches for newly created Pods with no assigned node and selects a suitable node for them, considering factors such as resource requirements and hardware constraints.
• kube-controller-manager — runs the controllers mentioned above (including the node, job, and service-account controllers), compiled into a single process to reduce complexity.
• cloud-controller-manager — an optional component that embeds logic specific to a given cloud provider.

Worker nodes

• kubelet — an agent that ensures the containers described in the Pod specs are actually running and healthy.
• kube-proxy — a network proxy that maintains the network rules enabling communication with Pods (optional if the network plugin provides this itself).
• container runtime — the actual container execution environment, such as containerd or CRI-O.

Core objects

The core object users work with is the Pod — "a set of one or more running containers," and also the smallest deployable unit. Rather than managing Pods by hand, users rely on higher-level resources: Deployment (for stateless applications where Pods are interchangeable), StatefulSet (for stateful applications such as databases), DaemonSet (runs a Pod on every node), and Job and CronJob (one-off and scheduled tasks).

Equally important are the networking and organizational objects. A Service gives Pods a stable address and load-balances traffic between them inside the cluster, while an Ingress (or the newer Gateway API) exposes services to the outside world. A Namespace, in turn, lets you logically split a single cluster into isolated areas — for example per team or per environment.

What can it be used for?

Kubernetes automates tasks that would be unmanageable if you were hand-managing hundreds of containers. The documentation lists its key uses directly:

• Service discovery and load balancing — Kubernetes can expose a container using a DNS name or its own IP address and distribute network traffic so the deployment stays stable.
• Automated rollouts and rollbacks — the system gradually brings the application's state to the declared one and can roll a change back if something goes wrong.
• Self-healing — it restarts containers that fail, replaces them, and kills those that do not pass defined health checks.
• Horizontal scaling — the number of application copies can be increased and decreased with a command, through an interface, or automatically based on CPU usage (via the Horizontal Pod Autoscaler, HPA).
• Automatic bin packing, storage orchestration, and secret and configuration management (passwords, tokens, SSH keys).

This is easiest to see with a simple example. Imagine an online store running on five servers. Under normal traffic, three copies of the application are enough, but during Black Friday demand grows tenfold. Kubernetes can then automatically increase the number of copies to thirty, spread them across the available nodes, and scale them back down once the sale ends — with no manual intervention.

In practice, Kubernetes is the foundation of microservice architectures^?microservice architectures: building applications from many small, independently deployed services, CI/CD platforms, data-processing systems, and increasingly the training and serving of AI models — with platforms such as Kubeflow^?Kubeflow: an open-source platform for running machine-learning (ML) workflows on Kubernetes — from data prep through training to model deployment or KServe^?KServe: an open-source component for serving ML models on Kubernetes as scalable inference services, with autoscaling (including scale-to-zero) — where it provides orchestration of compute resources.

How does it differ from other approaches?

The most common misunderstanding concerns the Kubernetes–Docker relationship. They are not competitors operating at the same level. Docker is primarily a tool for building, packaging and running containers locally. Kubernetes works one floor above — it manages many containers spread across many machines, and to actually run them it needs a container runtime. In Kubernetes clusters that role is today most often filled by containerd or CRI-O, which Kubernetes talks to through the Container Runtime Interface (CRI). Support for Docker via a compatibility layer (dockershim) was removed in Kubernetes 1.24. It is a complementary relationship, not a competitive one.

The differences stand out most clearly side by side:

The project's philosophy also matters. The documentation stresses that "Kubernetes is not monolithic, and these default solutions are optional and pluggable." Kubernetes "provides the building blocks for building developer platforms, but preserves user choice and flexibility where it is important." It therefore does not impose a specific solution for logging, monitoring, or CI/CD — you choose those yourself.

Key limitations and challenges

Kubernetes' biggest challenge is its complexity. The flexibility that is its strength comes at a price: the number of concepts, components, and configuration options means that deploying and maintaining a production cluster requires specialist knowledge. This is a real operational cost — both in team time and in the risk of misconfiguration.

Kubernetes deliberately does not provide many things out of the box. There is no built-in CI/CD, it imposes no logging, monitoring, or alerting solution, and it does not offer databases or caches as services. All of this has to be chosen and integrated separately, which further raises the barrier to entry.

A sensitive point is etcd — the store holding the entire cluster state. Losing it without a backup means losing the state of the whole cluster, which is why the documentation explicitly points to the need for a backup plan. It is also worth remembering the Pod failure model: a critical node failure means all Pods running on it are lost — Kubernetes treats this as final and creates new Pods rather than reviving the old ones.

Why does it matter?

Kubernetes has stopped being "one of the options" and become the de facto industry standard for container orchestration. Its status as the first project to complete the CNCF maturity path is not merely a formality — it signals that the entire cloud-native ecosystem began organizing itself around it. For anyone entering the world of modern infrastructure, this means Kubernetes is now a baseline skill, much as knowing Linux once was.

Its significance goes beyond simply running web applications. The declarative "desired state" model proved so universal that it became a design pattern for managing almost any kind of resource — from networking to AI infrastructure. It is increasingly on Kubernetes that the training and serving of machine-learning models rest, where orchestrating thousands of compute tasks is critical.

Kubernetes is best understood not as a tool but as a foundation — a layer that hides the complexity of managing distributed containers and lets you describe infrastructure declaratively. It is precisely this shift in thinking — from "how do I run this" to "what state do I want to reach" — that is its most lasting contribution to the industry.

Sources

• Kubernetes — Overview / definition and purpose — link
• Kubernetes — Cluster Architecture (components and controllers) — link
• Kubernetes — Workloads (Pods, Deployment, StatefulSet, Job) — link
• Kubernetes — What is Kubernetes (philosophy, boundaries) — link
• Kubernetes Blog — Dockershim removal FAQ (CRI, removed in 1.24) — link
• CNCF — Kubernetes project (acceptance and graduation dates) — link
• CNCF — Kubernetes: CNCF's first graduated project — link