2.18 Kubernetes Architecture Boundary
Kubernetes Architecture Boundary separates control plane and worker nodes, enabling scalable, secure containerized operations.
Kubernetes Architecture Boundary is the precise delineation of what falls inside Kubernetes's own architectural responsibility versus what is deliberately delegated to external, pluggable components, describing the specific interfaces, the CRI, CNI, and CSI, at which Kubernetes's own architecture ends and vendor- or environment-specific implementation begins.
The General Principle Behind the Boundary
Interfaces as Explicit Handoff Points
Kubernetes's architecture is deliberately drawn so that certain categories of functionality, running containers, connecting networks, and attaching storage, are not implemented within Kubernetes itself but are instead handed off at a defined interface boundary to a separately maintained implementation.
Consistency of the Pattern Across Domains
The same underlying pattern, a narrow, standardized interface with the actual implementation living entirely outside the core codebase, is applied consistently across all three of these domains, making the boundary itself, not any particular plugin, the architecturally significant element.
The Boundary at Container Execution
CRI as the Line Between Kubelet and Runtime
The Container Runtime Interface marks the boundary beyond which Kubernetes's own architecture has no further involvement in how a container is actually created; everything on the far side of that interface, image handling, namespace and cgroup configuration, and process supervision, is the responsibility of the runtime, not of Kubernetes.
The Boundary at Networking
CNI as the Line Between Kubelet and Network Fabric
The Container Network Interface marks a similar boundary for networking; Kubernetes's architecture requires that Pods receive addresses and connectivity satisfying its networking model, but the specific mechanism, whether overlay-based or routed, is entirely outside Kubernetes's own architectural scope once the CNI boundary is crossed.
The Boundary at Storage
CSI as the Line Between Kubelet and Storage Backend
The Container Storage Interface marks the corresponding boundary for storage; Kubernetes's architecture defines how volumes are requested and consumed through PersistentVolumeClaims, but the mechanics of provisioning, attaching, and mounting underlying storage are delegated entirely to the CSI driver beyond that boundary.
Why This Boundary Is Architecturally Significant
Decoupling the Core from Rapidly Changing External Ecosystems
Drawing these boundaries explicitly is what allows the core Kubernetes codebase to remain stable while runtimes, networking technologies, and storage systems continue to evolve independently, each only needing to conform to a defined interface rather than requiring changes to Kubernetes itself.
A Boundary, Not an Absence of Requirements
Importantly, this boundary does not mean Kubernetes has no requirements of what lies beyond it; each interface encodes a specific contract that any conforming implementation must satisfy, meaning the boundary shifts responsibility for implementation, not responsibility for correctness.