Kubernetes Architecture Boundary

Kubernetes Architecture Boundary is the precise line separating what falls within Kubernetes' own architecture, the control plane, nodes, and the standardized interfaces connecting them, from what is deliberately delegated to systems outside it: the underlying physical or virtual infrastructure, the container images workloads run, and higher-level concerns such as continuous delivery, service mesh routing, and multi-cluster coordination. Understanding this boundary is what prevents attributing responsibilities to Kubernetes that it was never architected to fulfill, and clarifies which problems require a separate system layered on top.

What Lies Inside the Boundary

The Control Plane and Data Plane

Everything described elsewhere as cluster architecture, kube-apiserver, etcd, kube-scheduler, kube-controller-manager, and the per-node kubelet, container runtime, kube-proxy, and CNI/CSI plugins, falls formally inside Kubernetes' own architectural boundary: these are the components whose behavior is specified, directly or through a defined interface, by the Kubernetes project itself.

The API and Object Model

The API server's request-handling pipeline, the object model it exposes, and the extension mechanisms, CRDs, admission webhooks, aggregated APIs, built atop that model are formally part of Kubernetes' architecture, since they define the contract every other component and client relies on.

What Lies Outside the Boundary

Physical and Virtual Infrastructure

The machines, virtual or physical, that nodes and control plane components run on, along with the underlying network fabric, storage hardware, and power and cooling infrastructure supporting them, are formally outside Kubernetes' architecture; Kubernetes assumes their existence and consumes their capacity through defined interfaces but does not itself provision or manage them.

# Infrastructure provisioning happens outside Kubernetes' own architecture
terraform apply

Container Images and Application Code

The contents of a container image, the application logic, its dependencies, its base operating system layer, are formally outside Kubernetes' architecture; Kubernetes schedules and runs whatever image a Pod specification references without any architectural involvement in how that image was built or what it contains.

CI/CD and Delivery Pipelines

The process by which a manifest is generated, tested, and promoted from one environment to another, continuous integration, continuous delivery, GitOps reconciliation controllers, operates architecturally outside Kubernetes; these systems produce and apply manifests through the ordinary API, but Kubernetes' own architecture has no concept of a pipeline, a build, or a promotion workflow.

Service Mesh Data Planes

A service mesh's sidecar proxies, mTLS enforcement, and traffic-shaping data plane are formally layered on top of Kubernetes' networking model rather than being part of it; Kubernetes provides the Pod and Service primitives a mesh builds upon, Pod-to-Pod connectivity, sidecar injection via admission webhooks, but the mesh's own routing and observability logic is an external system.

# Sidecar injection is implemented via Kubernetes' admission mechanism,
# but the sidecar's own traffic-management logic is outside Kubernetes' architecture
apiVersion: admissionregistration.k8s.io/v1
kind: MutatingWebhookConfiguration
metadata:
  name: sidecar-injector

Multi-Cluster Coordination

Kubernetes' own architecture is formally scoped to a single cluster; coordination across multiple clusters, federation, multi-cluster service discovery, cross-cluster failover, is addressed by separate systems layered above individual clusters, each of which remains architecturally self-contained.

The Interfaces That Define the Boundary Precisely

CRI, CNI, and CSI as the Formal Edges

The Container Runtime Interface, Container Network Interface, and Container Storage Interface each formally mark a precise point where Kubernetes' architecture ends and an external, pluggable implementation begins: Kubernetes specifies the interface contract, but the actual runtime, networking, and storage behavior behind it is supplied by external software the Kubernetes project does not itself provide.

kubectl get csidrivers
kubectl get runtimeclasses

Cloud Provider Integration

The cloud-controller-manager formally marks a similar boundary for infrastructure integration: it defines the interface through which Kubernetes requests cloud resources, load balancers, volumes, node metadata, but the actual provisioning logic behind that interface belongs to the cloud provider, outside Kubernetes' own architecture.

Why This Boundary Matters

Recognizing precisely where Kubernetes' architecture ends is what prevents two common errors: expecting Kubernetes itself to solve a problem that genuinely belongs to an external, complementary system, such as image building or service mesh routing, and, conversely, underestimating how much of a production platform's actual behavior, infrastructure provisioning, image supply chain, delivery pipeline, is determined by systems operating entirely outside Kubernetes' own architectural scope, even when they interact with it constantly through its API.