If you have already explored what containers are and why they matter, the natural next step is understanding how to manage them at scale. That is where Kubernetes comes in. Kubernetes has become the dominant standard for container orchestration, used by enterprises and startups alike to deploy, scale, and operate containerized workloads reliably.
Why Container Orchestration Was Needed
When containers first emerged as a mainstream infrastructure pattern, it quickly became clear that running individual containers was only part of the challenge. Production environments demand networking between containers, high availability, health monitoring, and—especially for database workloads—persisted storage. A container management layer was needed to handle all of this.
Early contenders for this role included Docker Swarm and Apache Mesos. Both gained traction but were ultimately overtaken in adoption by Kubernetes, which originated as an internal Google system called Borg—a large-scale cluster management platform that Google used to run its own workloads. Borg was later reimagined as an open source project, and Kubernetes now benefits from broad contributions across the technology industry.
How Kubernetes Is Structured
At a high level, a Kubernetes cluster is composed of host servers—either physical machines or virtual machines—organised into two roles: the master node (also called the control plane) and worker nodes.
The Master Node (Control Plane)
- etcd: A distributed key-value store that holds all cluster state—API objects, configuration, and service discovery data. For security reasons, only the API server communicates directly with etcd.
- API Server: The central management endpoint. All REST calls for new deployments or cluster modifications go through the API server.
- Scheduler: Determines which worker node a new pod should run on, based on current resource availability and constraints.
- Controller Manager: A set of controller processes that continuously reconcile the actual state of the cluster against the desired state declared in deployment manifests.
Worker Nodes
Each worker node runs two critical services:
- kubelet: An agent that receives pod specifications, ensures the declared containers are running, and reports node health back to the control plane.
- kube-proxy: Manages network rules on the node, handles subnetting, and enables services to be reachable from outside the cluster.
Core Kubernetes Concepts
Pods
The pod is the fundamental unit of deployment in Kubernetes. A pod contains one or more containers that share network and storage resources. Best practice is to group containers of the same application tier into a single pod—for example, keeping web containers together—rather than mixing workloads such as a database container and a web container in the same pod.
Pods are ephemeral by design. If a pod develops a runaway process or fails a health check, Kubernetes will terminate and replace it. This is normal and expected behaviour.
Services
Because individual pods come and go, Kubernetes introduces Services to provide a stable networking endpoint. A Service represents a logical set of pods, exposes a consistent IP address, and acts as a gateway so that other parts of the application—or external clients—can reliably reach those pods regardless of which specific pod instances are currently running.
Volumes and Persistent Storage
Containers are stateless and ephemeral by default, which is a problem for workloads like databases that must persist data across restarts. Kubernetes addresses this by allowing volumes to be attached to container definitions. Persistent Volumes (PVs) and Persistent Volume Claims (PVCs) decouple the storage lifecycle from the pod lifecycle, so data survives pod restarts or replacements. This is conceptually similar to shared-disk storage in a traditional failover cluster.
Namespaces
Namespaces provide virtual partitions within a single Kubernetes cluster. They serve two main purposes:
- Isolation: Resources in one namespace cannot directly communicate with resources in another namespace by default, creating a useful security boundary.
- Resource quotas: A namespace can be assigned CPU and memory quotas, preventing any one team or workload from consuming all available cluster resources.
If you have used Azure Resource Groups to logically partition cloud resources, namespaces serve a similar organisational role—though the network isolation behaviour is distinct.
ReplicaSets and StatefulSets
ReplicaSets ensure a specified number of identical pod replicas are always running. If a pod dies, the ReplicaSet controller creates a replacement. StatefulSets extend this concept for workloads that require stable network identities and ordered deployment, such as databases.
Declaring Infrastructure with Manifests
One of the most important shifts Kubernetes introduces is declarative infrastructure as code. Instead of issuing imperative commands to configure servers, you describe the desired state of your workloads in YAML (or JSON) manifest files. Kubernetes continuously works to make the cluster match that declared state.
The following is a simple Deployment manifest that runs three replicas of an Nginx web server:
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.7.9
ports:
- containerPort: 80Breaking this down:
- apiVersion / kind: Declares the type of Kubernetes resource being created—in this case, a Deployment using the
apps/v1API. - metadata: Names the deployment and attaches labels that can be used by selectors elsewhere in the cluster.
- spec.replicas: Tells Kubernetes to keep three pod instances running at all times.
- spec.template.spec.containers: Defines the container image (
nginx:1.7.9) and the port it listens on (80).
Storing manifests in a Git repository gives your team a full audit trail of infrastructure changes, makes rollbacks straightforward, and enables CI/CD pipelines to deploy updates consistently.
High Availability in Kubernetes
Kubernetes is designed for resilience at multiple levels:
- Application level: ReplicaSets ensure that the correct number of pod replicas are always running, automatically replacing failed pods.
- Control plane level: The etcd cluster can be replicated across multiple nodes, and the API server and other control plane components can be run in a highly available configuration to eliminate single points of failure.
Getting Started with Kubernetes
There are several practical options for experimenting with Kubernetes, depending on how much complexity you want to take on:
- Docker Desktop: Includes a built-in option to enable a local single-node Kubernetes cluster. Ideal for quick local development and learning.
- Minikube: Runs a simulated Kubernetes cluster on a single local Linux, macOS, or Windows machine. Good for learning cluster concepts without cloud costs.
- Managed Kubernetes services: Azure Kubernetes Service (AKS), Amazon Elastic Kubernetes Service (EKS), and Google Kubernetes Engine (GKE) provision a production-grade, highly available cluster within minutes. These services abstract away control plane management, letting you focus on workloads.
Why Kubernetes Skills Matter
Kubernetes has moved from an emerging technology to a foundational platform across both enterprise IT and cloud-native startups. An increasing number of software products—including Microsoft SQL Server—now support Kubernetes as a deployment target. For DevOps engineers, platform engineers, and site reliability engineers, practical Kubernetes knowledge has become an expected core competency.
The concepts covered here—pods, services, volumes, namespaces, manifests, and the control plane—form the foundation you need to go deeper into topics such as Helm chart packaging, ingress controllers, role-based access control (RBAC), and cluster autoscaling.