The Kubernetes platform orchestrates containerized workloads across a cluster of machines. Before diving into operational details, understanding a few common workload abstractions is essential.

Pods

The Pod serves as the fundamental deployable unit. It encapsulates one or more containers that share network and storage resources, co-located on the same node. Pods can arise in two forms: standalone pods created imperatively, which disappear permanently after deletion, and pods managed by controllers, which are automatically recreated upon failure to maintain a desired state.

# Example pod specification
apiVersion: v1
kind: Pod
metadata:
  name: demo-pod
  labels:
    component: api
spec:
  containers:
  - name: app-container
    image: nginx:1.21
    ports:
      - containerPort: 8080

Deployments

A Deployment provides declarative updates for Pods and ReplicaSets. Instead of interacting directly with Pods, users define the intended state, and the Deployment controller achieves it through rolling updates, rollbacks, and scaling operations. Under the hood, a Deployment creates and manages a ReplicaSet.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-frontend
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
  selector:
    matchLabels:
      stack: frontend
  template:
    metadata:
      labels:
        stack: frontend
    spec:
      containers:
        - name: webserver
          image: nginx:alpine
          ports:
            - containerPort: 80

StatefulSets

StatefulSet controllers are designed for applications requiring stable network identities, persistent storage, and ordered deployment or scaling. Typical candidates include databases and distributed coordination systems like etcd.

Every Pod in a StatefulSet receives a consistent hostname following the pattern {statefulset-name}-{ordinal-index}. When a Pod is rescheduled, it retains its identity and associated PersistentVolume claims.

DaemonSets

A DaemonSet guarantees that a copy of a specific Pod runs on all or a subset of cluster nodes. This pattern works well for node-level monitoring collectors, log shippers, or storage daemons. When a node joins the cluster, the DaemonSet automatically schedules a new Pod on it; when a node is drained, the Pod is garbage collected.

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: node-monitor
spec:
  selector:
    matchLabels:
      purpose: monitoring
  template:
    metadata:
      labels:
        purpose: monitoring
    spec:
      containers:
        - name: agent
          image: monitoring-agent:latest

Jobs and CronJobs

A Job supervises batch processes that run to completion. You can define the number of parallel executions and desired completions. Jobs support retry logic and time limits.

apiVersion: batch/v1
kind: Job
metadata:
  name: data-migrator
spec:
  completions: 1
  parallelism: 2
  backoffLimit: 4
  template:
    spec:
      restartPolicy: Never
      containers:
        - name: worker
          image: busybox:1.35
          command: ["sh", "-c", "echo processing items... && sleep 15"]

CronJobs build on Jobs to execute recurring tasks according to a cron schedule.

apiVersion: batch/v1
kind: CronJob
metadata:
  name: daily-report
spec:
  schedule: "0 3 * * *"
  jobTemplate:
    spec:
      template:
        spec:
          restartPolicy: OnFailure
          containers:
            - name: report-gen
              image: reporter:stable
              command: ["generate-report.sh"]

Horizontal Pod Autoscaler

The Horizontal Pod Autoscaler (HPA) scales the number of Pod replicas dynamically based on observed resource consumption or custom metrics. It periodically queries metrics APIs and adjusts replicas to match a target utilization threshold, helping maintain performance while controlling costs.

Service Discovery and Traffic Routing

Because Pod IPs are ephemeral, Kubernetes offers Service objects to present a consistent endpoint and load balance requests across backend Pods.

• ClusterIP publishes a service internally within the cluster using a virtual IP, reachable only from within the cluster.
• NodePort builds on ClusterIP by exposing a specifci port on each node’s IP, allowing external clients to contact the service.
• Headless services omit a ClusterIP and instead return individual Pod IPs through DNS, giving clients direct Pod-level access—valuable for stateful workloads.

Ingress resources extend routing capabilities to layer-7, enabling path-based and host-based forwarding to different backend services. An Ingress Controller (such as NGINX or Traefik) implements these rules, centralising TLS termination and domain routing.

Storage Abstractions

For workloads that require durable data, Kubernetes defines PersistentVolumes (PVs) as cluster-wide storage pieces, and PersistentVolumeClaims (PVCs) as user requests for those resources. This separation decouples storage provisioning from Pod configuration. Several volume types can back PVs:

• emptyDir: temporary directory tied to a Pod’s lifecycle.
• hostPath: mounts a specific node filesystem path into the Pod, increasing node affinity.
• nfs: mounts a Network File System share, presisting beyond the Pod lifespan.
• ConfigMap: injects configuration artefacts as files.

Architectural Control Plane

Internally, the cluster control plane comprises several components:

• kube-apiserver: central management endpoint handling authentication, validation, and API requests.
• etcd: consistent key-value store persisting cluster state.
• kube-scheduler: assigns unscheduled Pods to Nodes based on resource requirements and constraints.
• kube-controller-manager: runs controller processes that reconcile actual state with desired state.

On every node, kubelet registers the node with the apiserver and ensures containers are running. kube-proxy maintains network rules, implementing the Service abstraction through iptables or IPVS. CoreDNS resolves cluster-internal DNS names, and CNI plugins like Flannel or Calico handle pod-to-pod networking.

OCI and Runtime Evolution

The Open Container Initiative (OCI) standardised image format and runtime specifications, fostering interoperability across container runtimes. Kubernetes originally depended on Docker via a compatibility layer called dockershim. Since dockershim’s deprecation in v1.20, clusters use OCI-compatible runtimes like containerd or CRI-O directly through the Container Runtime Interface (CRI), streamlining the architecture and removing unnecessary abstraction layers.