← Back to DevOps and CI/CD

Kubernetes

Kubernetes reconciles container workloads to a declared cluster state.

DevOps and CI/CDContainersKubernetes

Kubernetes, often shortened to k8s, is a container orchestration platform that manages how applications are deployed, scaled, and kept running across a cluster of machines. Its central idea is declarative control. Operators describe the desired state of the system, and Kubernetes works continuously to make the actual state match it.

The smallest deployable unit in Kubernetes is usually a Pod, which groups one or more tightly coupled containers that share networking and storage context. Pods are normally created and replaced by higher level controllers such as Deployments for stateless applications, StatefulSets for stateful workloads, and Jobs for finite tasks. A Service gives stable network access to a changing set of Pods, so other components do not need to know which instance is currently running where.

Behind the scenes, the control plane stores desired state and schedules workloads onto nodes. Node agents then pull container images, start containers, report health, and restart failed workloads when needed. This is why Kubernetes is often described as self healing. If a node dies or a container crashes, the system tries to reschedule a replacement automatically.

The benefits are real. Kubernetes standardises deployment patterns across teams, supports rolling updates and rollbacks, and makes it easier to scale services horizontally. It also creates a consistent place for secrets, configuration, service discovery, and resource limits. In organisations with many services, that consistency is often more valuable than any one feature.

The cost is complexity. Kubernetes has many abstractions, and the gap between a YAML manifest and actual runtime behaviour can be large. A deployment that looks correct can still fail because probes are wrong, resource requests are unrealistic, image pulls time out, or network policies block traffic. Debugging often requires understanding several layers at once: container image, runtime, scheduler, service routing, ingress, and the application itself.

Kubernetes also does not remove the need for good application design. If a service stores critical state on the local filesystem, scaling or rescheduling it may break that assumption. If health checks are naive, the platform may route traffic to a process that has started but is not truly ready. If autoscaling is configured without request limits or workload understanding, the cluster may thrash under bursty traffic.

The best way to think about Kubernetes is as a control system for running disposable application instances reliably. It is powerful when you need repeatable deployment across many services and environments. It is less attractive when the application estate is small or the team cannot support the operational overhead. Kubernetes solves many recurring infrastructure problems, but it does so by introducing a platform that must itself be understood, secured, and operated with care.