Introduction to Kubernetes
Kubernetes (K8s) is the de facto standard for container orchestration — an open-source platform originally built at Google, now stewarded by the Cloud Native Computing Foundation (CNCF). It automates deploying, scaling, and managing containerised applications across clusters of machines.
Rather than manually placing containers on servers, you declare the desired state of your application. Kubernetes continuously reconciles the actual state of the cluster toward that desired state — restarting failed containers, rescheduling pods away from failed nodes, scaling replicas up or down — all without human intervention.
Kubernetes is a declarative, self-healing platform. You describe what you want (desired state). The control loop observes what exists (actual state) and takes action to close the gap. This convergence loop is the foundation of everything Kubernetes does.
High-Level Cluster Architecture
A Kubernetes cluster consists of a Control Plane (the brain — manages desired state, scheduling, and the API) and a Data Plane of Worker Nodes (the muscle — actually runs your workloads). A third concern, the Storage Layer, handles durable persistence for stateful applications.
Every component communicates exclusively through the kube-apiserver — never directly with each other. This centralises auth, RBAC, admission control, and audit logging. The API server is stateless; all state is durably persisted in etcd.
Worker Node Architecture
Worker Nodes are the machines in a Kubernetes cluster that actually run containerised workloads. Each node hosts one or more Pods and must run three core components: the kubelet, kube-proxy, and a container runtime.
3.1 kubelet — The Node Agent
The kubelet is the primary agent on every worker node. It watches the API server for Pods assigned to its node and instructs the container runtime to start, stop, and restart containers accordingly. It also reports node health and resource usage back to the API server.
| Responsibility | Detail |
|---|---|
| Pod Lifecycle | Starts/stops containers via CRI. Enforces restartPolicy. |
| Health Probing | Executes liveness, readiness, and startup probes. Takes corrective action on failure. |
| Resource Reporting | Reports node CPU/memory capacity and allocatable resources to the API server. |
| Volume Mounting | Mounts PVCs, ConfigMaps, Secrets, and ephemeral volumes into pod filesystems. |
| Image Management | Pulls container images. Enforces imagePullPolicy. Manages local image cache. |
| Node Registration | Registers the node with the API server on startup. Advertises labels and taints. |
3.2 kube-proxy — The Service Router
kube-proxy maintains network rules on each node that implement the Kubernetes Service abstraction — routing traffic from a stable virtual IP to backend pod IPs. It operates in one of three modes:
| Mode | Mechanism | Performance | Notes |
|---|---|---|---|
| iptables | Kernel netfilter rules | Good — O(n) rule lookup | Default in most clusters |
| IPVS | Kernel IP Virtual Server | Excellent — O(1) lookup | Best for 1000+ services |
| eBPF (Cilium) | Extended BPF programs | Best | Replaces kube-proxy entirely |
3.3 Container Runtime
The container runtime pulls images and manages container lifecycle at the OS level. The kubelet communicates with it via the Container Runtime Interface (CRI) — a gRPC API. Modern clusters use containerd as the default runtime.
Containers in Kubernetes
Containers are lightweight, isolated execution environments that package an application with all its runtime dependencies. In Kubernetes, containers always run inside a Pod — they cannot be scheduled independently. They are the atomic unit of execution.
Namespaces provide isolation (PID, Network, Mount, UTS, IPC, User). cgroups enforce resource limits for CPU and memory. OverlayFS stacks read-only image layers with a thin writable layer on top. seccomp/AppArmor restrict system calls to reduce the attack surface.
4.1 Health Probes
Kubernetes uses three types of probes to monitor and manage container health. These are critical for ensuring only healthy containers receive traffic and unhealthy ones are automatically remediated.
4.2 Container Security Context
Always configure a security context to follow the principle of least privilege in production:
4.3 Init Containers
Init containers run sequentially to completion before main application containers start. Each must succeed before the next begins. They share the pod's volumes but have their own images.
Waiting for a database to be ready before the app starts · Running DB schema migrations · Cloning git repos or fetching config into shared volumes · Fetching TLS certificates · Pre-populating a shared cache.
Pods — The Fundamental Unit
A Pod is the smallest deployable unit in Kubernetes. It encapsulates one or more containers, shared storage volumes, a unique cluster IP address, and configuration governing how containers run. Containers in a pod share the same network namespace — they communicate via localhost and share port space.
5.1 Pod Lifecycle Phases
5.2 Quality of Service (QoS) Classes
Kubernetes assigns a QoS class to every pod based on how its containers' resource requests and limits are configured. This directly determines eviction priority under node memory pressure.
5.3 Scheduling Controls
Kubernetes provides a rich set of mechanisms to control where pods are placed. These range from simple label matching to complex topology-aware spreading.
| Mechanism | Purpose | Hard / Soft |
|---|---|---|
| nodeSelector | Match pods to nodes by label key-value pairs | Hard (required) |
| nodeAffinity | Rich expression-based node selection | Both |
| podAffinity | Co-locate pods with other pods by label | Both |
| podAntiAffinity | Spread pods away from other pods | Both |
| Taints + Tolerations | Repel pods from nodes unless pod has a matching toleration | Hard |
| topologySpreadConstraints | Evenly distribute pods across zones/nodes | Both |
| PriorityClass | Preempt lower-priority pods when resources are scarce | Hard |
5.4 Pod Controllers
In production you never create pods directly. Higher-level controllers manage pod sets and handle resilience.
| Controller | Use Case | Key Feature |
|---|---|---|
| Deployment | Stateless apps | Rolling updates, rollbacks, replica management |
| StatefulSet | Databases, caches | Stable identity, ordered start/stop, per-pod PVC |
| DaemonSet | Node-level agents | One pod per node — CNI, log agents, CSI drivers |
| Job | One-off batch tasks | Run to completion with retry logic |
| CronJob | Scheduled batch tasks | Cron schedule syntax |
| ReplicaSet | Replica guarantee | Ensures N replicas are always running |
Storage Nodes & Persistent Volumes
Stateful workloads — databases, message brokers, object stores — require durable storage that outlives any individual pod. Kubernetes abstracts storage through a layered model that decouples provisioning from consumption.
6.1 What is a Storage Node?
A Storage Node is a worker node dedicated to or optimised for stateful workloads. It's configured with high-performance storage hardware (NVMe SSDs, high-IOPS disks) and is labelled and tainted so that only storage-intensive pods (PostgreSQL, Cassandra, Elasticsearch) are scheduled onto it.
6.2 The Storage Abstraction Model
Kubernetes provides four storage objects that form a clean separation between infrastructure and developer concerns:
| Access Mode | Short | Description | Typical Use |
|---|---|---|---|
| ReadWriteOnce | RWO | Read-write by a single node | Databases (MySQL, Postgres) |
| ReadOnlyMany | ROX | Read-only by many nodes | Shared config / static assets |
| ReadWriteMany | RWX | Read-write by many nodes | NFS shared content stores |
| ReadWriteOncePod | RWOP | Read-write by a single pod only | Strict single-writer workloads |
Always use Retain for production databases. With Delete, releasing a PVC permanently deletes the underlying storage — including all your data. Retain preserves the PV and data for manual recovery.
6.3 Container Storage Interface (CSI)
CSI is the standardised plugin API between Kubernetes and storage vendors. CSI drivers ship independently from Kubernetes, allowing any storage system to integrate without modifying core Kubernetes code.
Architecture Summary
The complete reference of all major Kubernetes components, their location, and function:
| Component | Location | Primary Function |
|---|---|---|
| kube-apiserver | Control Plane | Central API hub. All communication passes through. Enforces auth and admission. |
| etcd | Control Plane | Distributed key-value store. Single source of cluster truth. |
| kube-scheduler | Control Plane | Assigns unscheduled pods to nodes via filter + score phases. |
| kube-controller-manager | Control Plane | Runs all built-in control loops — Node, Deployment, HPA, etc. |
| cloud-controller-manager | Control Plane | Cloud API integration for load balancers, node lifecycle, volumes. |
| kubelet | Worker Node | Node agent. Manages pod/container lifecycle. Reports node status. |
| kube-proxy | Worker Node | Service routing. Maintains iptables/IPVS rules for virtual IPs. |
| Container Runtime | Worker Node | Pulls images and runs containers (containerd, CRI-O). |
| CNI Plugin | Worker Node | Pod networking. Assigns IPs. Enforces NetworkPolicies. |
| Pod | Worker Node | Smallest deployable unit. Wraps 1+ containers, network, storage. |
| PersistentVolume | Cluster-scoped | Represents a piece of durable storage in the cluster. |
| PersistentVolumeClaim | Namespace-scoped | Developer's request for persistent storage. Bound to a PV. |
| StorageClass | Cluster-scoped | Defines provisioner + parameters for dynamic PV creation. |
| CSI Driver | Cluster + Each Node | Plugin interface between Kubernetes and external storage systems. |
| Storage Node | Dedicated Worker Node | High-IOPS node tainted for stateful workloads only. |
| CoreDNS | kube-system | Cluster DNS. Resolves service and pod names to IPs. |
© Tech with Vishal Abhinav · Platform Ops Engineer · All rights reserved. This article is published as part of the Platform Ops Newsletter.