A running Linux container is fundamentally an isolated process environment built using three key technologies: Linux Namespaces for isolation, Cgroups for resource limits, and a root filesystem (rootfs) for the application’s view of the file system. This setup naturally divides a container into two conceptual parts:

• The container image, which is the static, immutable rootfs—typically layered via union mounts like AUFS or overlayfs.
• The container runtime, which provides the dynamic execution context through Namespaces and Cgroups.

In practice, developers primarily interact with and distribute container images. The runtime implementation is often abstracted away. This decoupling enabled the rapid rise of containre orchestration: cloud providers realized that if they could reliably run any standard container image, they could integrate directly into the developer workflow and build value-added services—CI/CD, observability, networking, storage—around that entry point.

This shift transformed containers from a local development tool into the foundation of cloud-native infrastructure. Among orchestration systems, Kubernetes emerged as the dominant platform, largely due to its origins in Google’s internal Borg system.

Unlike many infrastructure projects that evolve organically, Kubernetes was guided early on by published research—specifically, Google’s 2015 Borg paper. Borg, which underpinned Google’s entire production infrastructure, managed workloads at planetary scale. While Borg itself was never open-sourced, Kubernetes inherited its architectural philosophy and operational lessons, then refined them through community collaboration.

Kubernetes’ architecture mirrors Borg’s master–worker model:

• The control plane (Master) includes kube-apiserver (the central management endpoint), kube-scheduler (assigns workloads to nodes), and kube-controller-manager (ensures desired state). All cluster state is persisted in etcd.
• Each worker node runs kubelet, the primary agent responsible for managing containers on that host.

Crucially, kubelet interacts with container runtimes through the Container Runtime Interface (CRI), a gRPC-based API. This abstraction allows Kubernetes to support any OCI-compliant runtime—Docker, containerd, CRI-O—without being tightly coupled to any one implementation. Similarly, networking and storage are handled via standardized plugins: CNI (Container Networking Interface) and CSI (Container Storage Interface). GPU and specialized hardware support is managed through Device Plugins.

While kubelet shares a name with Borg’s borglet, it is a ground-up reimplementation designed specifically for modern container ecosystems—including image management and interface abstractions absent in Borg.

Where Kubernetes truly diverges from simpler orchestrators (like Docker Swarm) is in how it models relationships between workloads. Rather than treating containers as isolated units, Kubernetes introduces higher-level abstractions:

• A Pod groups tightly coupled containers that share network, IPC, and storage namespaces—ideal for co-located helper processes (e.g., a web server and a log shipper).
• A Service provides a stable network identity and load-balancing for a set of Pods, abstracting away their ephemeral IPs.
• Secrets and ConfigMaps inject sensitive or configuration data into Pods securely, typically via mounted volumes.
• Specialized controllers like Deployment (for scalable apps), DaemonSet (node-scoped daemons), Job (one-off tasks), and CronJob (scheduled tasks) extend the model to diverse workload patterns.

These constructs are managed through a declarative API: users describe the desired state (e.g., "run two Nginx replicas"), and Kubernetes continuously reconciles the actual state to match it. For example:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-app
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80

Applying this manifest with kubectl apply -f instructs Kubernetes to maintain two running instances of the Nginx container, automatically handling placement, networking, health checks, and recovery.

Unlike traditional PaaS or basic schedulers that focus only on launching containers, Kubernetes excels at modeling and automating the relationships and lifecycle behaviors of distributed appplications. Its true essence lies not just in orchestration, but in providing a foundational framework for building and operating cloud-native systems.