Kubernetes architecture: control plane, nodes and failure boundaries

TL;DR: Kubernetes stores desired state through its API and uses controllers and node agents to work toward it. The scheduler assigns eligible Pods to nodes; the kubelet coordinates their execution. Accepting an object, scheduling a Pod and serving a request are separate events.

Start with the API boundary

When kubectl submits a Deployment, the API server processes the request through authentication, authorization, admission and validation as applicable. Accepted object state is persisted through the cluster's storage path. The Deployment's existence establishes that the desired object was recorded. It does not prove containers are running.

The controller responsible for Deployments observes that desired state and manages ReplicaSets. The ReplicaSet controller manages the required Pods. A scheduler selects a node for an unscheduled Pod that meets its constraints. On the selected node, the kubelet works with a container runtime to run the Pod's containers, with networking and storage integrations providing their parts of the execution environment.

The Kubernetes component overview defines these responsibilities. Managed Kubernetes can hide control-plane machines from you while leaving the same conceptual boundaries relevant for diagnosis.

Components communicate through declared state

This is a responsibility diagram. It does not imply that the scheduler sends a shell command directly to a container or that customer requests normally pass through etcd. Most application traffic follows the configured data plane.

A pending Pod is a boundary clue

These are starting points, not exclusive diagnoses. For example, admission can reject Pods created by a controller after the Deployment itself was accepted. Follow the relevant object's conditions rather than assuming one successful API call authorizes all later objects.

Work through an unschedulable replica

A Deployment requests three replicas. Two are running; the third has a FailedScheduling event stating insufficient memory. The scheduler considers resource requests and placement constraints. A dashboard showing low current memory use does not mean the requested capacity fits.

Inspect the pending Pod's requests, available allocatable resources after existing reservations, and any node selector or affinity requirements. If it can run only on one node pool, free capacity elsewhere is irrelevant. A quota or admission policy may also prevent the Pod from being created in the first place, which is a different boundary from scheduling an existing Pod.

See requests and scheduling for the arithmetic. A sensible fix might reduce an inflated request after measurement or add capacity to the eligible pool. Deleting a healthy replica to “make room” can reduce availability without addressing the constraint.

Control-plane loss and application availability

Existing application containers may continue serving during an API outage. However, new deployments, scheduling and many reconciliation operations cannot proceed normally. If a worker fails while the control plane is unavailable, replacing its workloads is impaired. Applications that call the Kubernetes API for their own request handling can also experience immediate impact.

A control-plane backup protects recoverability of API state, subject to a tested restore procedure. It is not automatically a backup of every application database or persistent volume. Define separate backup and restoration responsibilities for cluster state and application data. The etcd operations guide covers snapshot and restore considerations for the storage component.

Likewise, multiple control-plane instances improve availability only when their storage quorum, networking and failure domains support the design. Count independent failure domains, then test the failure you claim to tolerate.

Separate Service implementation from Pod execution

A Service gives clients a stable abstraction over changing backends. Many clusters implement Service forwarding with kube-proxy; other supported networking implementations provide an alternative data plane. Do not diagnose every Service issue by assuming a particular iptables or IPVS layout.

Establish the cluster's implementation, then inspect selectors, ready endpoints and forwarding behavior. The Service and EndpointSlice concept follows that request path separately from this control-plane path.

Explain a failure without reciting component names

Self-check: an interviewer says, “The API accepted our Deployment, so the scheduler must be broken because no traffic is arriving.” What evidence would you request?

First establish whether Pods exist and have node assignments. Then inspect container startup, readiness, Service endpoint selection and the external request path. A successful Deployment write proves none of those later outcomes. Assign the suspected component only after identifying the transition that failed.

Practice a Pod stuck Pending, and connect each observation to the object hierarchy in Pods, ReplicaSets and Deployments.

A Pending pod needs a node that satisfies the intersection of its scheduling constraints, including resource requests and placement policy.

OpenShift platform operations adds Cluster Operators, application Operators and SCC admission to this architecture, with a worked admission-versus-routing failure.