K8s Request Processing Full Chain

In modern cloud-native ecosystems, Kubernetes has established itself as the de facto standard for container orchestration. Mastering the platform’s request handling full chain not only equips operators with the intuition to troubleshoot live incidents efficiently but also reveals the architectural wisdom behind its distributed design. This article adopts a macro perspective to dissect the complete lifecycle of a request—from the moment it leaves a client until it is materialized within a cluster.

Before tracing individual requests, it is essential to clarify the boundary between Kubernetes’s control plane and data plane, and the core components that inhabit each sphere. Kubernetes embraces a declarative API paradigm; virtually all components communicate through the API server, which serves as the cluster’s central communication bus.

API Server (kube-apiserver) acts as the unified entry point for the entire cluster. It receives incoming REST requests, performs authentication and authorization checks, validates the request body, and persists or retrieves data from the key-value store etcd. etcd provides highly available, consistent storage for all cluster configuration, state, and metadata.

Controller Manager (kube-controller-manager) runs a suite of control loops that observe the cluster’s state via the API server and work to reconcile the current state with the desired state defined by users. This includes the Deployment controller, Node controller, and others that drive the system toward its intended configuration.

Scheduler (kube-scheduler) is responsible for placing pods onto nodes. When a new pod enters a Pending state, the scheduler evaluates candidate nodes against a set of predicates and priorities, then binds the pod to the most suitable node.

Kubelet operates on each worker node as the primary agent. It communicates with the container runtime (e.g., containerd, Docker) to pull images, create and manage containers, monitor pod health, and report the pod’s status back to the API server.

Kube-proxy maintains network rules on every node, enabling service abstraction and traffic forwarding. Whether operating in iptables, ipvs, or nftables mode, kube-proxy ensures that requests directed at a Service endpoint are correctly routed to the backing pod endpoints.

A distinguishing characteristic of Kubernetes is the high degree of decoupling among these components. Communication is predominantly asynchronous and mediated by the API server, often via watch mechanisms that notify components of state changes. This design yields exceptional scalability and fault tolerance, as no single component represents a tight bottleneck or single point of failure beyond the API server itself.
A typical client request—whether kubectl apply creating a Deployment or an external client hitting a LoadBalancer Service—traverses a well-defined sequence of stages. Each stage involves specific components and guarantees, forming a cohesive chain from edge to cluster.

Stage One: Authentication, Authorization, and Admission Control

The moment a request arrives at the API server, it first passes through the security gateway.

• Authentication verifies the identity of the requester. Kubernetes supports multiple methods, including X.509 client certificates, bearer tokens (such as ServiceAccount tokens), and OpenID Connect. The authentication step produces a user or service identity that subsequent stages can reference.
• Authorization determines whether that identity is permitted to perform the requested operation on the targeted resources. The most common model is RBAC (Role-Based Access Control), which evaluates Role/ClusterRole objects and their bindings to decide if a verb (e.g., get, create, delete) is allowed on a specific API resource.
• Admission Control executes after authentication and authorization but before the object is persisted in etcd. Admission controllers intercept the request, perform validation, and may mutate the object. Common controllers include LimitRanger, which enforces resource defaults and constraints; ResourceQuota, which tracks consumption against namespace quotas; and ValidatingAdmissionWebhook, which allows external services to validate or reject requests based on custom logic. Mutating admission webhooks (e.g., injecting sidecar containers) can alter the object before it is stored, while validating webhooks can only reject or accept the request as-is.

Stage Two: Persistence and Controller Reconciliation

Once a request clears all prior checks, the API server writes the corresponding resource object into etcd. The response returned to the client is often immediate, but the actual work of bringing the desired state into reality is asynchronous.

Consider the creation of a Deployment as an illustrative example. After the Deployment manifest is stored in etcd, the Deployment Controller—a watcher within the Controller Manager—detects the change. It calculates the desired ReplicaSet specification and issues a create request to the API server for the new ReplicaSet resource. Subsequently, the ReplicaSet Controller monitors for ReplicaSet changes and computes the gap between the desired and current pod count. It then creates individual Pod resources, each initially in a Pending state, indicating that no node has yet been assigned.

Stage Three: Scheduling and Node Execution

With Pod objects now existing in etcd but marked Pending, the scheduler steps in to bind them to concrete nodes.

1. Predicates (Pre-filtering): The scheduler discards any node that cannot satisfy the pod’s resource requirements (CPU, memory), respects node affinity/anti-affinity rules, tolerates existing node taints, and adheres to any other scheduling constraints.
2. Priorities (Filtering and Scoring): Among the remaining candidates, the scheduler assigns scores based on factors such as pod topology spread, node utilization, custom weights, and anti-affinity. The node with the highest composite score is selected.
3. Binding: The scheduler writes the binding decision back to the API server, updating the pod’s spec.nodeName.

The newly assigned node’s Kubelet detects the pod assignment and begins local execution. It instructs the container runtime to pull the container image, set up volumes, configure networking (e.g., CNI plugins), and start the container processes. Kubelet continuously monitors container health via liveness and readiness probes, and feeds the updated pod status back to the API server, transitioning the pod through Running and Ready phases.

Stage Four: Networking and Traffic Routing

Once applications are running, the question of how to reach them arises. Kubernetes Services and the underlying networking subsystem provide the answer.

When a Service resource is created, the API server persists its specification. Every node’s Kube-proxy monitors changes to Service and Endpoint objects. Based on the configured mode, kube-proxy installs rules that intercept traffic destined for the Service’s virtual IP (ClusterIP, NodePort, or LoadBalancer IP). These rules typically employ load balancing algorithms (round-robin, least-connections, etc.) to distribute requests across the set of ready pod IP addresses. For cluster-internal clients, the kube-proxy rules ensure that traffic reaches the correct endpoint; for external access, cloud provider integrators or ingress controllers add additional layers of routing, TLS termination, and traffic management.

Architectural Perspective: Declarative API and Eventual Consistency

Viewed holistically, Kubernetes’s request handling full chain is a vivid manifestation of its core design philosophy: the declarative API and eventual consistency.

Users express intent—“run three replicas of this container” or “expose port 80 via a Service”—without prescribing the step-by-step mechanics of how that intent is realized. The system’s various components—API server, etcd, controllers, scheduler, kubelet, and kube-proxy—operate in a loosely coupled, asynchronous manner. They do not engage in tight synchronous RPC chains; instead, they listen for state changes, reconcile their local view, and push updates forward.

This watch-reconcile pattern means that the system continuously strives toward a desired global state, tolerating transient divergences. It is this architectural choice that enables Kubernetes to scale to thousands of nodes and tens of thousands of pods while maintaining high availability. The separation of concerns—authentication at the gate, persistence in etcd, control logic in controllers, placement in the scheduler, execution on kubelet, and networking via kube-proxy—creates a robust pipeline that is both expressive and resilient.

In summary, the K8s request handling full chain is not merely a sequence of technical steps; it is a carefully orchestrated dance of components, each playing its part in transforming declarative intent into concrete, running workloads. Understanding this chain empowers operators to diagnose issues faster, optimize resource placement, and appreciate the elegant balance between flexibility, control, and automation that defines modern container orchestration.