Kubernetes Architecture: Components, Control Flow and Failure Boundaries

Kubernetes architecture separates the control plane, which manages cluster state, from worker nodes, which run containerised workloads. A client submits desired state to the API server. Controllers, the scheduler and kubelets then act on API state within their own responsibilities; the container runtime executes requests from the kubelet through the Container Runtime Interface, or CRI. This is not one central process issuing a fixed sequence of commands to every component.

This guide follows that division of work from an API request to a running Pod, then uses it to distinguish failure boundaries. It is based on upstream documentation, not measurements of a cloud provider's internal network. Guance publishes the article; Guance product documentation describes collection options rather than proving Kubernetes behaviour. All three failure exercises below remain unexecuted. No observed output or recovery time is claimed.

For the definition, adoption trade-offs and relationship to Docker, start with What is Kubernetes?.

A logical architecture, not a universal physical topology

The components documentation describes a cluster as a control plane and one or more worker nodes. A self-managed deployment may leave component placement, upgrades and recovery to your team. A managed service transfers some responsibilities to its provider. Components may share machines or be distributed across hosts and availability zones.

Network, storage and cloud integration depend on the chosen implementations. The model here explains logical responsibilities; it does not claim that every EKS, GKE, AKS or private cluster has the same physical paths. Check the actual service documentation and contract for the ownership boundary.

The control plane preserves intent and coordinates change

The API server is the shared state interface, not a central executor for all work. Controllers repeatedly observe resources and request changes. The scheduler and kubelets also work through API state independently. Retries and reconciliation are asynchronous, so the system should not be read as one long synchronous function.

Likewise, etcd is not a general application database that every component should access directly. Its role as the backing store for API state needs its own access controls, backup and recovery procedures.

Worker nodes turn Pod specifications into execution

The runtime documentation defines the CRI boundary. Docker Engine does not implement CRI directly, and built-in dockershim was removed in Kubernetes 1.24. Do not treat one runtime or socket path as a permanent default for all versions.

The kubelet runs the probes you configure. Readiness success does not establish data correctness, dependency health or a successful user journey. A Ready condition is especially weak evidence of application health when no application readiness probe has been configured.

From an API request to a running Pod

For a Deployment, the conceptual sequence is:

1. A client submits the desired object through kubectl or another API client.
2. The API server handles the request, and accepted API state is persisted in etcd. The client does not write directly to etcd.
3. Workload controllers observe desired and current state, creating or adjusting ReplicaSets and Pod objects as needed.
4. The scheduler selects a node for an unassigned Pod using resource requests, constraints, policy and available nodes.
5. The selected node's kubelet observes its assigned Pod and asks the runtime to prepare and run the containers through CRI.
6. The kubelet reports container state and Pod conditions and runs configured probes. Other components and users continue observing through the API.

client → kube-apiserver ↔ etcd (API state)
                  ↑
       ┌──────────┼──────────┐
       │          │          │
  controller   scheduler   kubelet
  watch/write  watch/bind  watch assigned Pods/write status
                             │
                             ▼
                    CRI-compatible runtime → containers

The arrows describe logical relationships, not a measured packet sequence. During an incident, align object changes, Events, component logs, metrics and runtime evidence in time. A single status snapshot does not identify the faulty component.

Keep workload state and the traffic path separate

A Deployment manages declarative Pod updates through ReplicaSets. Deployment, ReplicaSet and Pod are not three names for one object. A Service supplies the access abstraction; EndpointSlices describe backend addresses and conditions.

An endpoint's presence is not proof of successful requests. Conversely, an application 5xx does not by itself establish a control-plane outage. Match resource identity and timestamps before drawing a connection between layers.

Communication and security boundaries

The control-plane communication guide distinguishes node-to-API communication from API-server access to kubelets, Pods and Services.

• Kubelets and node components using the Kubernetes API communicate with the API server. Authentication, authorisation and transport protection are separate requirements.
• The container runtime normally receives local CRI requests from the kubelet. Do not assume the runtime itself watches the Kubernetes API.
• Successful authentication does not grant all resource permissions.
• Kubelet APIs, API-to-node paths, tunnels and provider-specific connections vary by deployment.
• Verify ports, certificates, ServiceAccounts, network policies and hardening against the target version's documentation.

Restrict access to raw experiment records and remove credentials, kubeconfig contents, private keys, customer data and internal addresses from public copies. None of those secrets is needed in an article screenshot.

High availability and failure domains are different concerns

Several control-plane instances do not make an application highly available on their own. The kubeadm HA topology guide distinguishes stacked and external etcd. The multiple-zones guide addresses distribution across failure domains. Review the layers separately.

Pending includes both scheduling wait and image or container preparation after a node is assigned. In contrast, a ResourceQuota violation can reject creation with 403 Forbidden before there is a Pod to schedule. Those cases need different starting points.

The table is a triage aid, not an automatic root-cause tree. One symptom can cross several boundaries. Recovery-time or availability promises require their own contractual or repeatable test evidence.

Connect the layers with observability

The observability guide explains component and application metrics, logs and traces. Central log retention also needs a collection design that survives container replacement.

First fix the time window, cluster, namespace, workload, Pod UID and node. Inspect object state and ownership relationships for a reconciliation gap. Events can reveal scheduling, image or probe changes; they are clues rather than proof of a root cause. Use the relevant component's logs and metrics to narrow the boundary, then verify that application requests and user outcomes recover with the proposed fix.

Guance's Kubernetes integration, Prometheus discovery and ServiceMonitor / PodMonitor field subset are implementation entry points. They document collection paths, not validation of every cluster. Check permissions, versions, mappings and exclusions in the target environment.

Three failure exercises, all unexecuted

These protocols are designed to distinguish boundaries. They do not compare vendors or demonstrate automatic root-cause detection. None has observed results, screenshots or elapsed-time measurements in this article.

Shared prerequisites

Use a disposable non-production kind cluster or equivalent. Pin the Kubernetes patch, cluster tool, runtime, CNI, host OS and architecture. Version the image source and digest, manifests, resource constraints and probes. Preserve commands, raw output, exit codes, timestamps, object YAML, Events, component evidence and cleanup results. Sanitise the public copy, and have a second engineer repeat the experiment with the same inputs.

Exercise 1: Scheduling

Submit a Pod requiring a nonexistent node label or another unsatisfied constraint. Record phase, conditions, scheduler Events and candidate-node details, then correct the constraint and observe binding. Distinguish “no node selected” from “node selected but execution failed.” This article has not observed the actual Pending state, Event wording or binding time.

Exercise 2: Node and runtime

Use an unavailable image digest or tag. Collect container states, Events, kubelet/runtime evidence and registry-request information, then restore a known image. Successful scheduling does not prove the image was pulled or the container started. No ErrImagePull, ImagePullBackOff or other specific outcome has been measured here.

Exercise 3: Readiness and EndpointSlice

Configure a consistently failing readiness probe and a Service, then correct the probe. Record Pod Ready, probe output, selectors, EndpointSlice addresses and ready/serving/terminating conditions, the Service's publishNotReadyAddresses setting and actual requests.

Container execution, Pod readiness, address presence, traffic eligibility and a correct response are five separate facts. An unready Pod may remain in an EndpointSlice, and publishNotReadyAddresses can make its endpoint appear ready. The sequence of changes and recovery time have not been measured.

Until raw output and an independent rerun exist, these remain proposed methods. Upstream documentation supports the mechanism; a test supports only what was observed under its recorded conditions.

Continue from concept to implementation

Return to What is Kubernetes? for the definition and adoption boundary. Use the current architecture and components documentation, plus the target version's setup and security guides, for implementation.

For a commercial monitoring evaluation, the Guance Kubernetes monitoring solution provides product context. Use a test cluster to check objects, metrics, logs, permissions and missing data. Neither product copy nor an architecture diagram replaces that evaluation.

Primary sources

Technical mechanisms were reviewed against first-party documentation on 27 October 2026. The exercises were not run.

• Architecture, components and controllers
• Scheduler, Pod lifecycle and container runtimes
• Deployments, Services, EndpointSlices and probes
• ResourceQuotas and control-plane communication
• HA topology, multiple zones and observability
• CNCF Kubernetes project