6a:T4c6,The **kube-apiserver** is the central hub of all Kubernetes communication. Every interaction with the cluster—whether from kubectl, controllers, the scheduler, or kubelets—goes through the API server. It's not just a gateway; it's the single source of truth for the cluster's current state. **Core Responsibilities:** 1. **API Endpoint Exposure**: Serves the Kubernetes REST API over HTTPS, handling CRUD operations for all Kubernetes objects (Pods, Services, ConfigMaps, etc.) 2. **Authentication & Authorization**: Validates the identity of all requests (via certificates, tokens, etc.) and enforces RBAC policies to determine what actions are permitted. 3. **Admission Control**: Runs admission controllers that can mutate or validate requests before they're persisted. This is where policies like resource quotas, pod security standards, and webhook-based validations are enforced. 4. **etcd Gateway**: Serves as the only component that directly communicates with etcd. All cluster state changes go through the API server to etcd. 5. **Watch Mechanism**: Supports efficient watches that allow clients to subscribe to changes rather than polling. This is how controllers learn about new or modified resources.6b:Tbc9,Scheduling Decision Flow: Pod Created (no nodeName) ──► Scheduler Picks Up │ ▼ ┌─────────────────────┐ │ FILTERING PHASE │ └─────────────────────┘ │ ┌──────────────────────────┼──────────────────────────┐ ▼ ▼ ▼ Node Affinity? Resource Fit? Tolerations? │ │ │ ▼ ▼ ▼ ┌─────────────────────────────────────────────────────────────┐ │ Feasible Nodes (pass all filters) │ └─────────────────────────────────────────────────────────────┘ │ ▼ ┌─────────────────────┐ │ SCORING PHASE │ └─────────────────────┘ │ ┌──────────────────────────┼──────────────────────────┐ ▼ ▼ ▼ Resource Balance Spreading Score Locality Score (LeastRequested) (Pod Anti-Affinity) (Volume Zone) │ │ │ ▼ ▼ ▼ ┌─────────────────────────────────────────────────────────────┐ │ Final Score = Σ (weight × individual_score) │ └─────────────────────────────────────────────────────────────┘ │ ▼ Node with Highest Score Wins │ ▼ Bind Pod to Node (write to etcd)6c:Td6d,Cloud Controller Manager in Action: ┌────────────────────────────────────────────────────────────────┐ │ Service type: LoadBalancer │ │ created in API │ └────────────────────────────────────────────────────────────────┘ │ ▼ ┌────────────────────────────────────────────────────────────────┐ │ Service Controller (in CCM) watches │ └────────────────────────────────────────────────────────────────┘ │ ▼ ┌────────────────────────────────────────────────────────────────┐ │ CCM calls cloud provider API to create LB │ │ (e.g., CreateLoadBalancer on AWS ELB/NLB, GCP GCLB) │ └────────────────────────────────────────────────────────────────┘ │ ▼ ┌────────────────────────────────────────────────────────────────┐ │ Cloud provider provisions load balancer, returns IP │ └────────────────────────────────────────────────────────────────┘ │ ▼ ┌────────────────────────────────────────────────────────────────┐ │ CCM updates Service.status.loadBalancer.ingress │ │ with external IP/hostname │ └────────────────────────────────────────────────────────────────┘ │ ▼ ┌────────────────────────────────────────────────────────────────┐ │ Traffic flows: Internet → Cloud LB → NodePort → Pod │ └────────────────────────────────────────────────────────────────┘6d:T420,The **kubelet** is the primary node agent—it runs on every worker node and is responsible for ensuring containers are running as specified. It's the component that actually makes Pods come to life. **Core Responsibilities:** 1. **Pod Lifecycle Management** - Receives Pod specs (via API server or static Pod files) - Instructs container runtime to create/start/stop containers - Monitors container health and restarts failed containers - Reports Pod and container status back to API server 2. **Volume Management** - Mounts required volumes before containers start - Handles volume plugins (CSI drivers, etc.) - Unmounts volumes when Pods terminate 3. **Resource Enforcement** - Configures cgroups to enforce resource limits - Triggers eviction when node resources are exhausted - Reports node capacity and allocatable resources 4. **Health Monitoring** - Executes liveness, readiness, and startup probes - Updates container status based on probe results - Removes failed containers and signals for replacement6e:T14c5,kubelet Pod Lifecycle: ┌─────────────────────────────────────────────────────────────────┐ │ 1. Pod Scheduled to Node (nodeName set by scheduler) │ └─────────────────────────────────────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────────────────────┐ │ 2. kubelet Sees Pod (watching pods assigned to its node) │ └─────────────────────────────────────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────────────────────┐ │ 3. Volume Setup │ │ • Mount ConfigMaps, Secrets, PVCs │ │ • Wait for volume attachment (if cloud volumes) │ └─────────────────────────────────────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────────────────────┐ │ 4. Image Pull │ │ • Check local cache │ │ • Pull from registry if needed (using imagePullSecrets) │ └─────────────────────────────────────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────────────────────┐ │ 5. Container Creation │ │ • Create sandbox (pause container for networking) │ │ • Create app containers via Container Runtime Interface │ │ • Apply cgroup limits, security contexts │ └─────────────────────────────────────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────────────────────┐ │ 6. Container Start │ │ • Start containers in order (init containers first) │ │ • Execute postStart lifecycle hooks │ └─────────────────────────────────────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────────────────────┐ │ 7. Probe Execution (continuous) │ │ • Startup probe → Liveness probe → Readiness probe │ │ • Update container status based on results │ └─────────────────────────────────────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────────────────────┐ │ 8. Status Reporting │ │ • Update Pod status in API server │ │ • Report node conditions and capacity │ └─────────────────────────────────────────────────────────────────┘6f:T1892,Complete Workflow: kubectl apply -f deployment.yaml ┌──────────────────────────────────────────────────────────────────┐ │ 1. kubectl sends Deployment to API Server │ │ POST /apis/apps/v1/namespaces/default/deployments │ └──────────────────────────────────────────────────────────────────┘ ↓ ┌──────────────────────────────────────────────────────────────────┐ │ 2. API Server authenticates, authorizes, runs admission │ │ webhooks, then persists Deployment to etcd │ └──────────────────────────────────────────────────────────────────┘ ↓ ┌──────────────────────────────────────────────────────────────────┐ │ 3. Deployment Controller sees new Deployment (via watch) │ │ Creates ReplicaSet with pod template │ └──────────────────────────────────────────────────────────────────┘ ↓ ┌──────────────────────────────────────────────────────────────────┐ │ 4. ReplicaSet Controller sees new ReplicaSet │ │ Creates N Pod objects (pods have no nodeName yet) │ └──────────────────────────────────────────────────────────────────┘ ↓ ┌──────────────────────────────────────────────────────────────────┐ │ 5. Scheduler sees unscheduled Pods │ │ Runs filter/score, assigns each Pod to a node │ └──────────────────────────────────────────────────────────────────┘ ↓ ┌──────────────────────────────────────────────────────────────────┐ │ 6. kubelet on each assigned node sees Pod │ │ Pulls images, mounts volumes, creates containers │ └──────────────────────────────────────────────────────────────────┘ ↓ ┌──────────────────────────────────────────────────────────────────┐ │ 7. Container Runtime (containerd) runs containers │ │ OS-level isolation via namespaces, cgroups │ └──────────────────────────────────────────────────────────────────┘ ↓ ┌──────────────────────────────────────────────────────────────────┐ │ 8. kubelet updates Pod status → API Server → etcd │ │ Pod shows as Running │ └──────────────────────────────────────────────────────────────────┘ ↓ ┌──────────────────────────────────────────────────────────────────┐ │ 9. Endpoint Controller sees Running Pods │ │ Updates Endpoints for Services selecting these Pods │ └──────────────────────────────────────────────────────────────────┘ ↓ ┌──────────────────────────────────────────────────────────────────┐ │ 10. kube-proxy sees updated Endpoints │ │ Updates iptables/IPVS rules on all nodes │ └──────────────────────────────────────────────────────────────────┘ ↓ ┌──────────────────────────────────────────────────────────────────┐ │ RESULT: Traffic to Service ClusterIP reaches Pods 🎉 │ └──────────────────────────────────────────────────────────────────┘63:{"json":{"id":"seed_50fd99959bff28913708881896cb0503","slug":"kubernetes-architecture","category":"System Design HLD","topic":"Kubernetes Architecture","title":"Understanding Kubernetes Architecture","description":"Master the architectural foundations of Kubernetes—from the control plane components that manage cluster state to the node components that run your workloads. Learn how these components interact to provide a resilient, scalable, and self-healing container orchestration platform.","difficulty":"INTERMEDIATE","estimatedMinutes":120,"pages":[{"id":"seed_2e37e6d5da6daa2ef0c0e73a6a8d25d2","title":"Kubernetes Components: The Building Blocks of Container Orchestration","order":0,"content":[{"id":"opening-hook","title":"The Architecture That Powers Modern Infrastructure","content":[{"data":{"content":"Kubernetes has become the de facto standard for container orchestration, powering workloads from the smallest startups to the largest enterprises and hyperscalers. But beneath its powerful abstractions lies a carefully designed distributed system with distinct components, each serving a critical purpose.\n\nUnderstanding Kubernetes components isn't just academic knowledge—it's essential for debugging production issues, capacity planning, security hardening, and designing resilient architectures. When your application deployment fails, knowing whether the problem lies with the API Server, Scheduler, Controller Manager, or kubelet fundamentally changes your troubleshooting approach."},"type":"text"},{"data":{"icon":"Target","title":"What You Will Learn","content":"By the end of this page, you will have a comprehensive understanding of every core Kubernetes component, how they communicate, their failure modes, and how this architecture enables the self-healing, declarative nature of Kubernetes. You'll be able to reason about cluster behavior at the component level—a skill that separates operators who merely deploy from those who truly understand.","variant":"info"},"type":"callout"}]},{"id":"architectural-overview","title":"Architectural Overview: Control Plane and Data Plane","content":[{"data":{"content":"Kubernetes follows a **control plane / data plane** architecture pattern common in distributed systems. This separation provides clear boundaries between the components that make decisions and the components that execute work.\n\n**The Control Plane** (also called the master components) is the brain of the cluster. It maintains the desired state, makes scheduling decisions, responds to cluster events, and exposes the API. The control plane doesn't run your application workloads—it orchestrates them.\n\n**The Data Plane** (the worker nodes) is where your containers actually run. Each node hosts the components necessary to run Pods and communicate with the control plane. The data plane executes the decisions made by the control plane."},"type":"text"},{"data":{"rows":[["Control Plane","kube-apiserver, etcd, kube-scheduler, kube-controller-manager, cloud-controller-manager","Cluster state management, scheduling, reconciliation"],["Data Plane","kubelet, kube-proxy, container runtime","Running containers, networking, health monitoring"]],"caption":"Control Plane vs Data Plane Components","headers":["Component Type","Components","Primary Responsibility"]},"type":"table"},{"data":{"content":"**Why this separation matters:**\n\nThis architectural division enables several critical capabilities:\n\n1. **Scalability**: Control plane and data plane can scale independently. You can add hundreds of worker nodes without proportionally scaling control plane components.\n\n2. **Isolation**: Control plane failures don't immediately kill running workloads. If the API server goes down, existing Pods continue running—you just can't make changes.\n\n3. **Security**: The control plane can be isolated in separate network segments, reducing attack surface. Worker nodes only need limited access to specific control plane endpoints.\n\n4. **Maintenance**: Control plane components can be upgraded or restarted with minimal impact on running workloads."},"type":"text"},{"data":{"icon":"Info","title":"Production Reality","content":"In production, control plane components are typically run with high availability—usually three or more replicas spread across availability zones. Managed Kubernetes services (EKS, GKE, AKS) abstract this away, managing the control plane for you while you focus on the data plane.","variant":"note"},"type":"callout"}],"titleType":"number","titleNumber":1},{"id":"kube-apiserver","title":"kube-apiserver: The Cluster's Front Door","content":[{"data":{"content":"$6a"},"type":"text"},{"data":{"code":"Request Flow Through the API Server:\n\n1. Request Arrives\n └─► Authentication\n ├─ Client Certificate\n ├─ Bearer Token\n ├─ OpenID Connect\n └─ Webhook Token Authentication\n\n2. Authorization (after authentication succeeds)\n └─► RBAC Check\n ├─ Role/ClusterRole lookup\n ├─ RoleBinding/ClusterRoleBinding check\n └─ Decision: Allow/Deny\n\n3. Admission Controllers (if authorized)\n └─► Mutating Admission\n ├─ Default values injection\n ├─ Sidecar injection (Istio, etc.)\n └─ Label/annotation addition\n └─► Validating Admission\n ├─ Resource quota check\n ├─ Pod security policies\n └─ Custom webhook validations\n\n4. Persistence (if all checks pass)\n └─► Write to etcd\n └─► Return success response\n\n5. Notification\n └─► Watch subscribers notified of change","fileName":"apiserver-request-flow.txt","showLineNumbers":false},"type":"code"},{"data":{"content":"**Scalability Characteristics:**\n\nThe API server is designed to be horizontally scalable. In high-availability setups, multiple API server instances run behind a load balancer. Because all state is stored in etcd, any API server instance can handle any request. This stateless design is critical for production deployments.\n\n**Key Performance Considerations:**\n\n- **Request throttling**: The API server implements priority and fairness to prevent any single client from overwhelming the server\n- **Watch efficiency**: Long-running watch connections allow clients to receive events without constant polling\n- **Caching**: Frequently accessed data is cached to reduce etcd load\n- **Index-based queries**: Efficient label selectors use indexes for fast lookups"},"type":"text"},{"data":{"icon":"AlertCircle","title":"API Server as Single Point of Failure","content":"While the API server is horizontally scalable, it remains the central communication hub. If all API server instances become unavailable, you lose the ability to make any cluster changes—though existing workloads continue running. This makes API server availability critical for operational control.","variant":"warning"},"type":"callout"}],"titleType":"number","titleNumber":2},{"id":"etcd","title":"etcd: The Cluster's Distributed Memory","content":[{"data":{"content":"**etcd** is a distributed, consistent key-value store that serves as Kubernetes' backing store for all cluster data. Every object you create—every Pod, Service, ConfigMap, Secret—is persisted in etcd. It's not just storage; it's the foundation of Kubernetes' consistency guarantees.\n\n**Why etcd?**\n\nKubernetes requires a storage system with very specific properties:\n\n1. **Strong Consistency**: When the API server writes a Pod spec, that write must be immediately visible to all readers. etcd provides this through the Raft consensus algorithm.\n\n2. **Watch Support**: Controllers need to react to changes. etcd's native watch capability allows efficient event notification without polling.\n\n3. **Distributed & Fault-Tolerant**: etcd can tolerate node failures while maintaining consistency. A 3-node cluster survives 1 failure; a 5-node cluster survives 2.\n\n4. **Transactional Operations**: Compare-and-swap operations enable safe concurrent updates—critical for controllers competing to update resources."},"type":"text"},{"data":{"rows":[["1 node","0 failures","Development/testing only"],["3 nodes","1 failure","Small production clusters"],["5 nodes","2 failures","Large production clusters requiring higher availability"],["7 nodes","3 failures","Rarely needed; additional nodes add consensus overhead"]],"caption":"etcd Cluster Sizing Guidelines","headers":["Cluster Size","Failure Tolerance","Recommended Use Case"]},"type":"table"},{"data":{"content":"**Data Organization in etcd:**\n\nKubernetes organizes data in etcd using a hierarchical key structure:\n\n```\n/registry/pods//\n/registry/services//\n/registry/secrets//\n/registry/deployments//\n```\n\nThis organization enables efficient prefix-based watches (watch all pods in a namespace) and range queries.\n\n**The Raft Consensus Algorithm:**\n\netcd uses Raft for distributed consensus. Here's how it works at a high level:\n\n1. **Leader Election**: One node is elected leader; all writes go through the leader\n2. **Log Replication**: The leader replicates entries to followers before committing\n3. **Commit**: Once a majority acknowledges, the entry is committed and applied\n4. **Failover**: If the leader fails, a new election occurs within milliseconds"},"type":"text"},{"data":{"icon":"AlertCircle","title":"etcd is Critical—Back It Up","content":"Losing etcd data means losing your entire cluster configuration. Regular etcd snapshots are essential. Many production incidents have been caused by etcd corruption or loss. Use etcdctl snapshot save regularly and store backups off-cluster.","variant":"error"},"type":"callout"},{"data":{"content":"**Performance Tuning Considerations:**\n\n- **Disk I/O**: etcd is write-intensive; use SSDs with low latency. Network-attached storage can introduce unacceptable delays.\n- **Network Latency**: Keep etcd nodes close (same availability zone ideally). Cross-AZ latency impacts commit times.\n- **Compaction**: etcd stores historical revisions; periodic compaction prevents unbounded storage growth.\n- **Resource Isolation**: Run etcd on dedicated nodes in large clusters to prevent resource contention with other workloads."},"type":"text"}],"titleType":"number","titleNumber":3},{"id":"kube-scheduler","title":"kube-scheduler: Intelligent Workload Placement","content":[{"data":{"content":"The **kube-scheduler** watches for newly created Pods that have no assigned node and selects an appropriate node for them to run on. This is a non-trivial problem—the scheduler must consider resource requirements, affinity/anti-affinity rules, taints and tolerations, data locality, and many other factors.\n\n**The Scheduling Process:**\n\nScheduling happens in two phases:\n\n**1. Filtering Phase (Predicates)**\nThe scheduler filters out nodes that cannot run the Pod:\n- Does the node have sufficient CPU and memory?\n- Does the Pod tolerate the node's taints?\n- Does the node satisfy node affinity requirements?\n- Are required ports available?\n- Does the node's labels match node selectors?\n\n**2. Scoring Phase (Priorities)**\nAmong feasible nodes, the scheduler scores each to find the optimal placement:\n- Balanced resource utilization\n- Data locality (volume zones)\n- Pod anti-affinity spread\n- Custom priority functions"},"type":"text"},{"data":{"code":"$6b","fileName":"scheduling-decision-flow.txt","showLineNumbers":false},"type":"code"},{"data":{"content":"**Scheduler Extensibility:**\n\nThe default scheduler can be extended through several mechanisms:\n\n- **Scheduling Profiles**: Configure multiple scheduling behaviors and select per-Pod\n- **Scheduler Plugins**: The scheduling framework allows injecting custom logic at various extension points\n- **Custom Schedulers**: You can run completely separate schedulers alongside the default one\n\n**Common Scheduling Failures:**"},"type":"text"},{"data":{"rows":[["Insufficient cpu/memory","Resource requests exceed available capacity","Add nodes, reduce requests, or use cluster autoscaler"],["No nodes match node selector","Labels mismatch","Correct labels or update selector"],["Taints not tolerated","Node tainted without matching toleration","Add toleration or remove taint"],["Volume zone conflict","Volume in different zone than viable nodes","Create volume in correct zone"]],"headers":["Failure Reason","Typical Cause","Resolution"]},"type":"table"},{"data":{"icon":"Lightbulb","title":"Scheduler Performance at Scale","content":"In large clusters (thousands of nodes), scheduler performance becomes critical. The default scheduler uses techniques like node scoring caching and parallel evaluation. For extremely large clusters, consider running multiple schedulers or using scheduling policies to limit the search space.","variant":"tip"},"type":"callout"}],"titleType":"number","titleNumber":4},{"id":"kube-controller-manager","title":"kube-controller-manager: The Reconciliation Engine","content":[{"data":{"content":"The **kube-controller-manager** runs a collection of controllers that watch the cluster state and work to move the current state toward the desired state. This is the heart of Kubernetes' declarative model—you specify what you want, and controllers make it happen.\n\n**The Controller Pattern:**\n\nEvery controller follows the same pattern:\n\n1. **Watch**: Subscribe to relevant resource changes via the API server\n2. **Observe**: When changes occur, read the current state\n3. **Compare**: Calculate the difference between current and desired states\n4. **Act**: Take actions to reconcile the difference\n5. **Repeat**: Continue the loop indefinitely\n\n**Key Controllers Bundled in kube-controller-manager:**"},"type":"text"},{"data":{"rows":[["ReplicaSet Controller","ReplicaSets, Pods","Pod count","Creates/deletes Pods to match desired replica count"],["Deployment Controller","Deployments, ReplicaSets","ReplicaSet versions","Manages rolling updates, rollbacks, and revision history"],["Node Controller","Nodes","Node health","Marks nodes as unhealthy, evicts Pods from dead nodes"],["Service Account Controller","Namespaces","ServiceAccounts","Creates default service account in new namespaces"],["Endpoint Controller","Services, Pods","Endpoints","Updates endpoint lists as Pods come and go"],["Job Controller","Jobs, Pods","Job completions","Creates Pods for Jobs, tracks completion/failure"],["Namespace Controller","Namespaces","Namespace deletion","Cleans up all resources when namespace deleted"],["PV/PVC Controller","PersistentVolumes, PersistentVolumeClaims","Volume binding","Matches claims to volumes, handles reclaim"]],"caption":"Core Kubernetes Controllers","headers":["Controller","Watches","Manages","Key Behavior"]},"type":"table"},{"data":{"content":"**Reconciliation in Action—ReplicaSet Example:**\n\nConsider a ReplicaSet with `replicas: 3`:\n\n1. The ReplicaSet controller watches ReplicaSets and Pods\n2. When notified, it counts Pods matching the ReplicaSet's selector\n3. If count < 3: Create (3 - count) new Pods\n4. If count > 3: Delete (count - 3) excess Pods\n5. If count == 3: No action needed\n\nThis loop runs continuously. If a Pod dies, the controller creates a replacement. If you scale to 5, the controller creates 2 more. The desired state is always maintained.\n\n**Leader Election:**\n\nIn HA setups with multiple control plane nodes, only one instance of kube-controller-manager actively runs controllers—the leader. Others are on standby. If the leader fails, another instance acquires the leader lock and takes over. This prevents conflicting actions from multiple controllers."},"type":"text"},{"data":{"icon":"Info","title":"Controller Loops Are Eventually Consistent","content":"Controllers don't guarantee instant state convergence. They operate asynchronously in a level-triggered manner—they reconcile based on the current state, not individual events. This makes them resilient to missed events but means there's always some lag between desired state change and actual state convergence.","variant":"note"},"type":"callout"}],"titleType":"number","titleNumber":5},{"id":"cloud-controller-manager","title":"cloud-controller-manager: Cloud Provider Integration","content":[{"data":{"content":"The **cloud-controller-manager** (CCM) contains controllers that interact with cloud provider APIs. This component was extracted from kube-controller-manager to allow cloud providers to develop their integration at their own pace without being tied to Kubernetes release cycles.\n\n**Controllers in the CCM:**\n\n1. **Node Controller (Cloud Portion)**\n - Initializes nodes with cloud-specific metadata (zone, instance type, etc.)\n - Detects when cloud instances are deleted and removes corresponding Node objects\n - Updates node addresses from cloud provider\n\n2. **Route Controller**\n - Configures cloud provider routes for inter-node networking\n - Ensures Pod network routes exist between nodes\n\n3. **Service Controller**\n - Provisions cloud load balancers for `type: LoadBalancer` services\n - Updates load balancer configs as service endpoints change\n - Cleans up load balancers when services are deleted"},"type":"text"},{"data":{"code":"$6c","fileName":"cloud-integration-flow.txt","showLineNumbers":false},"type":"code"},{"data":{"content":"**Provider Implementations:**\n\nEach major cloud provider maintains their own CCM:\n\n- **AWS**: [cloud-provider-aws](https://github.com/kubernetes/cloud-provider-aws)\n- **GCP**: [cloud-provider-gcp](https://github.com/kubernetes/cloud-provider-gcp)\n- **Azure**: [cloud-provider-azure](https://github.com/kubernetes-sigs/cloud-provider-azure)\n\n**Running Without CCM:**\n\nOn bare-metal or on-premises deployments, you typically don't run a CCM. Without it:\n- LoadBalancer services stay in `Pending` state (use MetalLB or similar for bare-metal LB)\n- Node zone/region labels must be applied manually\n- No automatic cloud resource cleanup"},"type":"text"},{"data":{"icon":"Lightbulb","title":"Managed Kubernetes Hides This Complexity","content":"In managed Kubernetes services (EKS, GKE, AKS), the CCM is pre-configured and managed for you. You simply create a LoadBalancer service, and a real cloud load balancer appears. Understanding CCM matters when troubleshooting cloud integration issues or running self-managed clusters.","variant":"tip"},"type":"callout"}],"titleType":"number","titleNumber":6},{"id":"kubelet","title":"kubelet: The Agent That Runs Your Containers","content":[{"data":{"content":"$6d"},"type":"text"},{"data":{"code":"$6e","fileName":"kubelet-pod-lifecycle.txt","showLineNumbers":false},"type":"code"},{"data":{"content":"**Container Runtime Interface (CRI):**\n\nkubelet doesn't run containers directly—it delegates to a container runtime via CRI. This abstraction allows swapping runtimes:"},"type":"text"},{"data":{"rows":[["containerd","Industry-standard runtime, graduated CNCF project","Default for most distributions"],["CRI-O","Lightweight runtime optimized for Kubernetes","OpenShift, minimalist setups"],["Docker (via cri-dockerd)","Docker Engine with CRI shim","Legacy compatibility"]],"headers":["Runtime","Description","Use Case"]},"type":"table"},{"data":{"content":"**Pod Eviction:**\n\nWhen node resources are exhausted, kubelet evicts Pods based on priority:\n1. BestEffort Pods (no requests/limits) are evicted first\n2. Burstable Pods (requests < limits) are next\n3. Guaranteed Pods (requests == limits) are evicted last"},"type":"text"},{"data":{"icon":"AlertCircle","title":"kubelet Controls Node Health","content":"If kubelet fails, the node stops reporting status. After the node-monitor-grace-period (default 40s), the node is marked NotReady. After pod-eviction-timeout (default 5m), Pods are evicted to other nodes. Monitor kubelet health carefully—a silent kubelet failure can leave you with phantom nodes.","variant":"warning"},"type":"callout"}],"titleType":"number","titleNumber":7},{"id":"kube-proxy","title":"kube-proxy: Service Networking Made Possible","content":[{"data":{"content":"**kube-proxy** runs on every node and implements the Kubernetes Service concept. When you create a Service, kube-proxy configures the node's networking rules to direct traffic to the appropriate Pods.\n\n**What kube-proxy Does:**\n\n1. **Watches Services and Endpoints**: Subscribes to changes via API server\n2. **Configures Packet Forwarding**: Sets up rules to intercept service ClusterIP traffic and forward to Pod IPs\n3. **Load Balances**: Distributes traffic across endpoint Pods\n4. **Handles NodePort Services**: Opens ports on nodes for external access\n\n**Operating Modes:**\n\nkube-proxy can operate in different modes with significant performance implications:"},"type":"text"},{"data":{"rows":[["iptables","Linux iptables rules for NAT/forwarding","Good for <1000 services","Default, widely compatible"],["IPVS","Linux IPVS (IP Virtual Server) for load balancing","Better scalability, O(1) lookup","Large clusters with many services"],["userspace (legacy)","Traffic proxied through userspace process","Poor, high latency","Deprecated, avoid"]],"caption":"kube-proxy Operating Modes","headers":["Mode","Mechanism","Performance","When to Use"]},"type":"table"},{"data":{"content":"**How Service Traffic Flows (iptables mode):**\n\nWhen a Pod accesses a ClusterIP service:\n\n1. Pod sends packet to `10.96.0.1:80` (service ClusterIP)\n2. iptables rule intercepts the packet (DNAT)\n3. Random Pod endpoint is selected (e.g., `10.244.1.5:8080`)\n4. Packet destination is rewritten to the selected Pod IP\n5. Packet is routed to the target Pod\n6. Return traffic follows conntrack for consistent source NAT\n\n**IPVS Mode Advantages:**\n\nIPVS uses hash tables for O(1) rule lookup versus O(n) iptables chain traversal:\n\n- Better performance with thousands of services\n- Multiple load balancing algorithms (round-robin, least connections, etc.)\n- Kernel-level connection tracking\n- Better metrics and observability"},"type":"text"},{"data":{"icon":"Info","title":"kube-proxy Alternatives","content":"Some CNI plugins (Cilium, Calico eBPF mode) can replace kube-proxy entirely. They implement service load balancing using eBPF for even better performance and additional features like session affinity and native load balancing without NAT.","variant":"note"},"type":"callout"}],"titleType":"number","titleNumber":8},{"id":"container-runtime","title":"Container Runtime: Where Containers Actually Run","content":[{"data":{"content":"The **container runtime** is the software responsible for actually running containers. While often overlooked, choosing and understanding your container runtime affects security, performance, and compatibility.\n\n**The OCI Standard:**\n\nThe Open Container Initiative (OCI) defines standards for container images and runtimes:\n- **Image Spec**: Container image format\n- **Runtime Spec**: How to run a container (process, mounts, cgroups, etc.)\n\nOCI compliance means different runtimes are interchangeable at the low level.\n\n**Runtime Layers:**\n\nContainer runtimes exist in layers:\n\n```\nkubelet\n ↓ (CRI - Container Runtime Interface)\nHigh-Level Runtime (containerd, CRI-O)\n ↓ (OCI Runtime Spec)\nLow-Level Runtime (runc, crun, kata-runtime)\n ↓\nLinux Kernel (namespaces, cgroups, seccomp)\n```"},"type":"text"},{"data":{"rows":[["containerd","High-level","CNCF graduated, Docker-extracted, production-proven","General Kubernetes deployments"],["CRI-O","High-level","Kubernetes-focused, minimal, stable","OpenShift, security-focused deployments"],["runc","Low-level (OCI)","Reference implementation, standard Linux containers","Default low-level runtime"],["crun","Low-level (OCI)","Written in C, faster startup than runc","Performance-sensitive workloads"],["gVisor (runsc)","Low-level (OCI)","User-space kernel for isolation","Untrusted/multi-tenant workloads"],["Kata Containers","Low-level (OCI)","Lightweight VMs for containers","Strong isolation requirements"]],"caption":"Container Runtime Comparison","headers":["Runtime","Type","Key Characteristics","Best For"]},"type":"table"},{"data":{"content":"**containerd Architecture:**\n\ncontainerd (the most common high-level runtime) provides:\n\n- **Image pull and push**: Registry interaction, layer deduplication\n- **Snapshot management**: Copy-on-write filesystem layers\n- **Container lifecycle**: Create, start, stop, pause, resume\n- **Content storage**: Image and layer caching\n- **Namespace isolation**: Multiple independent container groups\n\n**Security Runtimes:**\n\nFor enhanced isolation (multi-tenant clusters, untrusted code), specialized runtimes provide stronger boundaries:\n\n- **gVisor**: Intercepts syscalls in userspace, providing a security boundary without full VM overhead\n- **Kata Containers**: Runs each Pod in a lightweight VM, hardware-level isolation\n- **Firecracker**: MicroVM technology (AWS Lambda/Fargate), millisecond boot times"},"type":"text"},{"data":{"icon":"Lightbulb","title":"RuntimeClass for Mixed Workloads","content":"Kubernetes RuntimeClass lets you specify different runtimes per Pod. Run trusted workloads with runc for performance, untrusted workloads with gVisor for security—all in the same cluster.","variant":"tip"},"type":"callout"}],"titleType":"number","titleNumber":9},{"id":"component-interaction","title":"How Components Interact: The Complete Picture","content":[{"data":{"content":"Now that we understand each component individually, let's trace a complete workflow to see how they work together. We'll follow the lifecycle of a Deployment from creation to running Pods.\n\n**Step-by-Step: Creating a Deployment**"},"type":"text"},{"data":{"code":"$6f","fileName":"complete-workflow.txt","showLineNumbers":false},"type":"code"},{"data":{"content":"**Key Observations:**\n\n1. **etcd is touched only by the API server**: All other components communicate via API server watches\n\n2. **Controllers are event-driven but level-triggered**: They react to changes but always reconcile based on current state, not event history\n\n3. **No component directly calls another**: Communication is via shared state in etcd, accessed through the API server\n\n4. **Asynchronous by design**: Each controller operates independently; there's no synchronous orchestration\n\n5. **Self-healing emerges from reconciliation**: If a Pod dies, ReplicaSet controller notices and creates a replacement—no central coordinator needed"},"type":"text"}],"titleType":"number","titleNumber":10},{"id":"summary","title":"Summary: Kubernetes Component Architecture","content":[{"data":{"content":"We've explored every core component of the Kubernetes architecture. Let's consolidate the key takeaways:"},"type":"text"},{"data":{"type":"ordered","items":["**Control Plane manages cluster state**: API server, etcd, scheduler, and controllers work together to maintain the desired state","**Data Plane runs workloads**: kubelet, kube-proxy, and container runtime execute the control plane's decisions on each node","**API Server is the single gateway**: All components communicate through the API server, never directly with each other","**etcd is the source of truth**: A consistent, distributed key-value store holding all cluster configuration","**Controllers implement the declarative model**: The reconciliation loop pattern continuously drives current state toward desired state","**Scheduler optimizes placement**: Filtering and scoring ensure Pods land on suitable nodes","**kubelet is the node-level executor**: It manages the full Pod lifecycle on each worker node","**Container runtime does the actual work**: OCI-compliant runtimes like containerd handle image and container operations"],"title":{"icon":"CheckCircle","text":"Key Takeaways","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"content":"**What's Next:**\n\nNow that you understand the components, the next page dives into the core Kubernetes objects—Pods, Deployments, and Services. You'll see how these abstractions build on the component architecture to provide powerful application management capabilities."},"type":"text"},{"data":{"icon":"CheckCircle","title":"Page Complete","content":"You now have a comprehensive understanding of Kubernetes component architecture. This foundation will inform your ability to debug cluster issues, design resilient deployments, and make informed decisions about Kubernetes configurations. Next, we'll explore how Pods, Deployments, and Services work together.","variant":"success"},"type":"callout"}],"titleType":"number","titleNumber":11}],"isLocked":false},{"id":"seed_fcdeb761c5960532ada1a951da1f8c12","title":"Pods, Deployments, and Services: The Kubernetes Resource Trinity","order":1,"content":null,"isLocked":true},{"id":"seed_1a1a356b49ecaf3c65b1154549c3664e","title":"Control Plane and Nodes: The Brain and Body of Kubernetes","order":2,"content":null,"isLocked":true},{"id":"seed_40056ab1ca0d42e4d888c3c1392dd4d6","title":"Declarative Configuration: Tell Kubernetes What, Not How","order":3,"content":null,"isLocked":true},{"id":"seed_c30accbaad9f5ceb71ddf1b02f814410","title":"Kubernetes Ecosystem: Tools, Extensions, and Best Practices","order":4,"content":null,"isLocked":true}]}}