Introduction
Kubernetes has established itself as the standard for container orchestration in modern cloud environments. As enterprises shift to containerized microservices and multi-cloud infrastructure, understanding how a Kubernetes cluster manages, schedules, and maintains application containers is essential for engineering teams. Without a clear grasp of its internal architecture, teams often struggle with cluster performance, troubleshooting pipeline failures, and configuring resilient production environments.This deep dive breaks down the internal architecture of Kubernetes, examining the interaction between control plane services and worker nodes, traffic movement across cluster networks, state management, and workload lifecycle execution. Whether you are managing containerized apps, designing internal platforms, or preparing for advanced Kubernetes credentials, this guide provides a structured foundation. For hands-on guidance and professional upskilling across cloud-native domains, platforms like DevOpsSchool.cn offer structured engineering pathways and certification tracks.
What Is Kubernetes Architecture?
Kubernetes architecture follows a master-worker model designed to decouple cluster management from workload execution. The cluster is divided into two primary zones: the Control Plane (traditionally called the master node) and Worker Nodes.
+-------------------------------------------------+
| CONTROL PLANE |
| |
| +------------------+ +------------------+ |
| | kube-apiserver| | kube-scheduler | |
| +--------+---------+ +--------+---------+ |
| | | |
| +--------+---------+ +--------+---------+ |
| | etcd | | kube-controller- | |
| | | | manager | |
| +------------------+ +------------------+ |
+-----------------------+-------------------------+
|
+--------------+--------------+
| |
v v
+---------------------------------+ +---------------------------------+
| WORKER NODE 1 | | WORKER NODE 2 |
| | | |
| +--------------------------+ | | +--------------------------+ |
| | kubelet | | | | kubelet | |
| +------------+-------------+ | | +------------+-------------+ |
| | | | | |
| +------------+-------------+ | | +------------+-------------+ |
| | kube-proxy | | | | kube-proxy | |
| +------------+-------------+ | | +------------+-------------+ |
| | | | | |
| +------------+-------------+ | | +------------+-------------+ |
| | Container Runtime | | | | Container Runtime | |
| | (e.g., containerd) | | | | (e.g., containerd) | |
| +------------+-------------+ | | +------------+-------------+ |
| | | | | |
| +------------+-------------+ | | +------------+-------------+ |
| | Pod A | Pod B | | | | Pod C | Pod D | |
| +--------------------------+ | | +--------------------------+ |
+---------------------------------+ +---------------------------------+
The control plane makes global decisions about the cluster—such as scheduling workloads, detecting node failures, and maintaining the desired state defined in your declarative configurations. The worker nodes host the application workloads in the form of Pods and run runtime agents to execute and monitor those containers.
Core Components of the Control Plane
The Control Plane acts as the brain of the cluster. It processes API requests, manages state storage, schedules resources, and maintains system convergence.
1. kube-apiserver
The API Server is the central administrative hub of the Kubernetes cluster. It exposes the Kubernetes API (HTTP/JSON or gRPC) and serves as the front door for all internal and external communication.
-
Function: Validates and processes configuration requests from users (via
kubectl), worker nodes, and internal controllers. - Statelessness: The API Server is stateless and scales horizontally across multiple instances to handle heavy control plane traffic.
2. etcd
etcd is a strongly consistent, distributed key-value store used as Kubernetes’ backing store for all cluster data.
- Function: Stores the complete state of the cluster, including configuration settings, secrets, configmaps, and live status of running workloads.
- Consensus Algorithm: Operates on the Raft consensus algorithm, requiring an odd number of instances (e.g., 3 or 5 nodes) to maintain a quorum and survive failures.
3. kube-scheduler
The scheduler assigns newly created Pods without assigned nodes to healthy worker nodes based on resource demands and policy constraints.
- Filtering and Scoring: Filters nodes based on hardware resource requests (CPU/Memory), node selectors, taints, and tolerations, then scores eligible nodes to select the optimal placement.
- Decoupled Operation: The scheduler only decides where a Pod should run; it does not directly launch the container on the node.
4. kube-controller-manager
This component runs background controller loops to continuously track the current state of the cluster and drive it toward the desired state defined in manifest files.
- Node Controller: Monitors worker nodes for health and availability.
- ReplicaSet Controller: Ensures the exact number of Pod instances are running.
- Endpoints Controller: Populates EndpointSlice and Endpoints objects to link Services and Pods.
5. cloud-controller-manager
Interactions with underlying cloud provider APIs (such as AWS, Azure, or Google Cloud) are segregated into the cloud-controller-manager.
- Function: Manages cloud-specific resources like load balancers, storage volumes, and routing rules without embedding cloud-vendor logic directly into the core Kubernetes codebase.
Core Components of Worker Nodes
Worker nodes perform the actual compute work, running containers and reporting node status back to the control plane.
1. kubelet
kubelet is the primary agent running on every worker node in the cluster.
-
Function: Receives Pod specifications (
PodSpecs) from the API server and verifies that the described containers are running and remaining healthy. -
Health Checks: Executes liveness, readiness, and startup probes to ensure application health and communicates node status back to
kube-apiserver.
2. Container Runtime
The underlying engine responsible for pulling container images from registries, running, and managing container lifecycles.
-
Interface: Communicates with
kubeletusing the Container Runtime Interface (CRI). Common runtimes includecontainerdandCRI-O.
3. kube-proxy
kube-proxy manages network communication on each node, enabling Kubernetes Service abstractions.
-
Function: Maintains network rules on the node, forwarding traffic sent to Service IP addresses directly to the correct backend Pods using mechanisms like
iptablesorIPVS.
Kubernetes Workload Abstractions and Networking
Kubernetes abstracts physical compute infrastructure into logical resources to simplify management and scaling.
+---------------------------------------------------------------------------------------+
| KUBERNETES CLUSTER |
| |
| +---------------------------------------------------------------------------------+ |
| | Service (ClusterIP / NodePort) | |
| +---------------------------------------+-----------------------------------------+ |
| | |
| +---------------------+---------------------+ |
| | | |
| v v |
| +-----------------------------------+ +-----------------------------------+ |
| | WORKER NODE 1 | | WORKER NODE 2 | |
| | | | | |
| | +-----------------------------+ | | +-----------------------------+ | |
| | | Pod A | | | | Pod B | | |
| | | +-----------------------+ | | | | +-----------------------+ | | |
| | | | App Container | | | | | | App Container | | | |
| | | +-----------------------+ | | | | +-----------------------+ | | |
| | | | Sidecar Container | | | | | | PersistentVolumeClaim | | | |
| | | +-----------------------+ | | | | +-----------------------+ | | |
| | +-----------------------------+ | | +-----------------------------+ | |
| +-----------------------------------+ +-----------------------------------+ |
+---------------------------------------------------------------------------------------+
- Pods: The smallest deployable unit in Kubernetes. A Pod houses one or more containers that share network namespaces, IP addresses, and storage volumes.
- Deployments: Declarative objects that manage stateless Pod scaling, rolling updates, and automated rollbacks.
- StatefulSets: Designed for stateful applications (such as databases), guaranteeing unique network identities and persistent storage ordering across restarts.
- Services: Expose Pod workloads internally or externally using stable virtual IPs, performing built-in load balancing across target Pods.
- Ingress / Gateway API: Manages external HTTP/HTTPS routing into cluster services, offering features like SSL termination, path-based routing, and virtual hosting.
Understanding the Control Loop and State Management
Kubernetes relies on an open-loop system called the reconciliation loop. The control plane constantly compares the Actual State (reported by kubelet and node agents) against the Desired State (stored in etcd).
-
User Action: A user submits a manifest file via
kubectl apply -f deployment.yaml. -
API Verification:
kube-apiserverauthenticates, authorizes, and validates the request, writing the updated state intoetcd. - Controller Processing: The deployment controller notices the change and creates matching ReplicaSet specifications.
-
Scheduling:
kube-schedulerevaluates unassigned Pods and selects suitable worker nodes based on available capacity and scheduling rules. -
Execution: The
kubeleton the assigned node reads the updated instruction, delegates container creation to the CRI, andconfigures local networking via CNI (Container Network Interface).
Comparison: Control Plane vs. Worker Nodes
| Architectural Domain | Control Plane | Worker Node |
|---|---|---|
| Primary Role | Cluster management, state persistence, and scheduling decision-making. | Workload execution, compute processing, and local networking. |
| Core Components |
kube-apiserver, etcd, kube-scheduler, kube-controller-manager. |
kubelet, kube-proxy, Container Runtime (containerd/CRI-O). |
| State Storage | Stores persistent cluster configuration and state directly inside etcd. |
Stateless execution; stores local runtime logs and ephemeral cache. |
| User Access | Direct REST API exposure via kube-apiserver for admin tools (kubectl). |
Indirect interaction managed by kubelet through API server requests. |
| Scalability Focus | Scaled via control plane API instances and etcd raft cluster size. |
Scaled horizontally by adding compute nodes to meet application capacity. |
Common Architectural Pitfalls in Kubernetes
Even experienced engineering teams encounter operational friction when designing or maintaining Kubernetes environments. Avoiding these structural mistakes ensures long-term cluster stability:
-
Overloading single-node etcd setups: Running a single
etcdinstance in production creates a catastrophic single point of failure. Always deploy odd-numbered clusters across isolated fault domains. -
Omitting resource requests and limits: Failing to configure
requestsandlimitsfor CPU and memory leads to noisy neighbor issues and unexpected node OOM (Out Of Memory) kills. - Neglecting CNI network policies: Assuming internal cluster traffic is isolated by default. Without NetworkPolicies, any Pod inside a cluster can communicate with any other Pod.
-
Misunderstanding ingress controllers vs. services: Using
NodePortorLoadBalancerfor every application instead of using an Ingress controller or Gateway API, driving up cloud infrastructure overhead. -
Bypassing control plane security: Exposing
kube-apiserverdirectly to public IP ranges without strong RBAC policies or network restriction rules.
Practical Guidance for Engineering Teams
+---------------------------------------------------------------------------------+
| KUBERNETES ADOPTION ROADMAP |
+---------------------------------------------------------------------------------+
| |
| [Phase 1: Containerization] --> [Phase 2: Core Concepts] |
| - Docker, OCI standards - Pods, Services, Deployments |
| - Image optimization - Declarative YAML manifests |
| |
| | |
| v |
| |
| [Phase 3: Managed Cluster] --> [Phase 4: Advanced Operations] |
| - Cloud EKS / AKS / GKE - GitOps (ArgoCD, Flux) |
| - Network Policies & RBAC - Observability (Prometheus/Grafana) |
| |
+---------------------------------------------------------------------------------+
- Master Docker and Container Standards First: Build clean, multi-stage, small container images before attempting complex orchestration scenarios.
- Standardize on Managed Kubernetes for Production: Reduce control plane management overhead by leveraging managed cloud engines like Amazon EKS, Azure AKS, or Google GKE.
- Adopt Infrastructure as Code and GitOps: Declare all cluster states using Terraform, Helm, or Kustomize, driving synchronization through GitOps engines like Argo CD or Flux.
- Implement Declarative Security: Enforce strict Role-Based Access Control (RBAC), pod security standards (PSS), and container image scanning across your CI/CD build pipelines.
- Invest in Practitioner Training: Upskill development and operations teams through practical, lab-based programs. Institutions like DevOpsSchoo offer specialized training in Kubernetes, GitOps, SRE, and DevSecOps.
Frequently Asked Questions
1. What is the primary purpose of Kubernetes architecture?
Kubernetes architecture automates the deployment, scaling, management, and networking of containerized applications across cluster infrastructure. It abstracts physical servers into unified pool resources, maintaining high availability through automated self-healing mechanisms and declarative control loops.
2. What is the difference between the control plane and worker nodes?
The control plane handles global cluster management, workload scheduling, state persistence, and event processing. Worker nodes provide the underlying compute, memory, and networking resources needed to host, run, and monitor individual application containers.
3. What is the role of etcd in a Kubernetes cluster?
etcd is a distributed, consistent key-value store that acts as Kubernetes' primary database. It records the complete state of the cluster, including node information, pod configurations, secrets, configmaps, and network settings.
4. How does kubelet interact with the container runtime?
kubelet communicates with the container runtime (e.g., containerd) through the Container Runtime Interface (CRI). It instructs the runtime to pull container images, start or stop containers, and execute health checks based on specifications provided by the control plane.
5. What happens when a worker node fails in a cluster?
When a worker node becomes unresponsive, kube-controller-manager detects the missing heartbeat, updates the node status to NotReady, and triggers the scheduler to reschedule affected Pods onto healthy worker nodes.
6. Why is etcd configured with an odd number of nodes?
etcd relies on the Raft consensus algorithm, which requires a majority quorum to perform state writes. Configuring odd node counts (e.g., 3, 5) prevents split-brain scenarios and optimizes fault tolerance without adding unnecessary node overhead.
7. What is the difference between kube-proxy and a CNI plugin?
kube-proxy configures networking rules (such as iptables or IPVS) on nodes to route traffic sent to Kubernetes Services. A Container Network Interface (CNI) plugin handles pod-to-pod networking and IP address assignment across physical nodes.
8. How do managed Kubernetes services affect control plane management?
Managed services like Amazon EKS, Azure AKS, and Google GKE automate control plane management, handling provisioning, patching, scaling, and etcd backups, allowing engineering teams to focus on worker nodes and application workloads.
9. What core skills are needed to manage Kubernetes architecture?
Engineers need containerization knowledge (Docker/OCI), Linux administration, networking fundamentals, YAML syntax, security practices (RBAC), and tool mastery across CI/CD, Terraform, Helm, and observability frameworks.
10. How can teams build practical hands-on experience with Kubernetes?
Teams can start by running local clusters using tools like Minikube or Kind, practice building declarative deployment manifests, and participate in practical training programs available on platform sites like DevOpsSchool.cn.
Conclusion
Understanding Kubernetes architecture is vital for modern cloud engineering, platform design, and production operations. By dissecting how control plane services like kube-apiserver, etcd, and kube-scheduler orchestrate worker node runtimes and networking abstractions, engineering teams can build resilient, scalable container platforms.
Navigating containerized infrastructure requires hands-on familiarity with core scheduling models, failure recovery patterns, and cluster security. As container adoption continues to expand across multi-cloud environments, developing technical expertise through structured learning tracks—such as those available at DevOpsSchool.cn—helps developers and operations specialists build reliable, production-ready cloud systems.
Top comments (0)