Kubernetes

Kubernetes coordinates containers across a cluster so applications can run consistently despite failures, changing demand, or shifting infrastructure. Operators describe a desired state—such as the number of application replicas—and Kubernetes continually works to make the actual state match it.¹ The project emerged from Google’s experience with large-scale internal systems, particularly ideas associated with Borg, but was designed as an open-source platform with a broader ecosystem and extensible interfaces.

Rather than being a container runtime itself, Kubernetes schedules and manages workloads through runtimes that implement the Open Container Initiative standards. This separation lets a cluster use containerd, CRI-O, or another compatible runtime while Kubernetes handles orchestration.

A Kubernetes cluster combines a control plane, which makes global decisions, with worker nodes, which run application workloads. The API server provides the principal interface; the scheduler selects suitable nodes; controllers observe resources and reconcile them; and a backing key-value store, typically etcd, preserves cluster state.²

Applications are packaged into Pods, the smallest deployable Kubernetes unit. A Pod may contain one or more closely coupled containers sharing networking and storage. Higher-level resources such as Deployments, StatefulSets, DaemonSets, and Jobs manage Pods according to different operational patterns. This layered model separates application intent from the individual machines that execute it.

Kubernetes provides distinct abstractions for long-running services, batch processing, stateful systems, and node-level agents. A Deployment supports rolling updates and replica management, while a StatefulSet supplies stable identities and ordered behavior for applications that need persistent relationships between instances.³ Jobs and CronJobs handle finite or scheduled work.

Because Pod addresses are ephemeral, a Service supplies a stable network endpoint and selects matching Pods. Ingress and the newer Gateway API extend traffic management beyond basic internal discovery.⁴ PersistentVolumes and related claims decouple storage requests from the underlying disk or cloud provider, although data durability and backup remain responsibilities requiring deliberate infrastructure design.

Kubernetes is more than a deployment tool: its extensibility is a defining feature. Custom resources and operators allow organizations to represent domain-specific systems—such as databases, certificate authorities, or machine-learning workflows—as Kubernetes objects managed by reconciliation logic. Admission controllers can validate or mutate API requests, while namespaces, service accounts, and role-based access control divide authority inside a shared cluster.

The platform also has important boundaries. Kubernetes does not automatically make an application observable, secure, cost-efficient, or correctly designed for stateful operation. Cluster networking may depend on a Container Network Interface plugin, and storage behavior varies by provisioner. The project is governed within the Cloud Native Computing Foundation, whose ecosystem includes many independently developed components rather than a single all-inclusive product.⁵

Cluster

A group of machines managed together by Kubernetes.

Pod

The smallest deployable Kubernetes unit, containing one or more containers.

Control plane

The Kubernetes components that expose the API and reconcile cluster state.

Deployment

A workload resource for managing replicated, usually stateless, application Pods.

Service

A stable network endpoint that directs traffic to a set of selected Pods.