K8s Architecture: Master Node, Worker Node Components

K8s Architecture: Master Node, Worker Node & Components Guide

Understanding the Kubernetes architecture is the foundation for everything you’ll do with the platform – from debugging a CrashLoopBackOff to architecting a multi-region setup. This guide is for backend developers, DevOps practitioners, SREs, and platform engineers who want a solid mental model of how Kubernetes actually works under the hood. We’ll walk through the control plane components, worker node components, the scheduling flow, networking, storage, and how all the pieces interact in real production clusters.

K8s architecture has two main planes: the control plane (master components) and the data plane (worker nodes). The control plane runs API Server, etcd, Scheduler, Controller Manager, and Cloud Controller Manager – they collectively decide what should run where. Each worker node runs kubelet (manages pods on the node), kube-proxy (network rules), and a container runtime (containerd is current default). The kubernetes architecture diagram shows: API Server is the only component that talks to etcd; everything else flows through API Server. With DevOps job listings up 75% YoY (Spacelift 2025) and Kubernetes appearing in 80%+ of senior cloud-native listings, this Kubernetes architecture explained correctly is non-negotiable for engineering interviews.

Key Components at a Glance

Source: official Kubernetes Components documentation.

2. kubernetes cluster architecture – Worker Nodes

Direct answer: kubernetes cluster architecture’s data plane is where your application pods actually run. Worker nodes are EC2 instances (on EKS), VMs (on AKS), or any Linux box that joins the cluster. Each node runs three core components: kubelet, kube-proxy, and a container runtime.

2.1 kubelet – The Node Agent

kubelet runs on every worker node. It receives PodSpecs from the API Server (via the watch API), instructs the container runtime to start/stop containers, monitors their health, and reports node + pod status back to the API Server. It also implements liveness/readiness/startup probes, runs init containers in order, and handles volume mounting. If kubelet dies, the node goes NotReady and pods may be evicted.

2.2 kube-proxy – Service Networking

kube-proxy implements Kubernetes Service abstractions on each node. When you create a Service of type ClusterIP, kube-proxy programs iptables/IPVS/eBPF rules so that traffic to the Service’s virtual IP gets load-balanced to one of the matching Pods. Cilium replaces kube-proxy entirely with eBPF-based service load balancing – faster + more observable.

2.3 Container Runtime

The container runtime starts and stops containers. Kubernetes uses the Container Runtime Interface (CRI) to talk to it. Current production runtimes: containerd (default in most managed clusters), CRI-O (RHEL/OpenShift). Docker Engine is no longer a supported runtime since K8s 1.24 – though the same Docker images work fine via containerd.

3. K8s architecture diagram – Visual Walkthrough

Direct answer: A typical K8s architecture diagram shows the control plane on the left/top, worker nodes on the right/bottom, and arrows representing the API Server as the hub. Below is a text-rendering of the canonical layout plus the data flow when you apply a Deployment.

# Canonical Kubernetes architecture (text version) ┌─────────────────────────────────────────────────────────────┐ │ CONTROL PLANE │ │ │ │ ┌────────────┐ ┌──────┐ ┌──────────────┐ │ │ │ API Server │◄──►│ etcd │ │ Scheduler │ │ │ └─────▲──────┘ └──────┘ └──────────────┘ │ │ │ ┌──────────────┐ │ │ │ │ Controller │ │ │ │ │ Manager │ │ │ │ └──────────────┘ │ │ │ ┌──────────────┐ │ │ │ │ Cloud CCM │ │ │ │ └──────────────┘ │ └────────┼─────────────────────────────────────────────────────┘ │ │ (mTLS REST + watch streams) │ ┌────────┼──────────────────┐ ┌──────────────────────────┐ │ WORKER NODE 1 │ │ WORKER NODE 2 │ │ ┌─────────┐ ┌──────────┐│ │ ┌─────────┐ ┌─────────┐ │ │ │ kubelet │ │ kube- ││ │ │ kubelet │ │ kube- │ │ │ └────┬────┘ │ proxy ││ │ └────┬────┘ │ proxy │ │ │ │ └──────────┘│ │ │ └─────────┘ │ │ ┌────▼─────────┐ │ │ ┌────▼───────────┐ │ │ │ containerd │ │ │ │ containerd │ │ │ └──────────────┘ │ │ └────────────────┘ │ │ Pods: A, B, C │ │ Pods: D, E, F │ └───────────────────────────┘ └──────────────────────────┘

3.1 What Happens When You Run kubectl apply -f deployment.yaml

• kubectl sends the Deployment spec to the API Server via REST
• API Server validates + authorises (RBAC), then writes to etcd
• Deployment Controller watches → creates a ReplicaSet
• ReplicaSet Controller watches → creates Pods (still unassigned)
• Scheduler watches for unassigned Pods → picks a node, writes back to API Server
• kubelet on the chosen node watches → pulls images, starts containers via containerd
• kubelet reports Pod status back to API Server (Running, Ready, etc.)
• If you created a Service: kube-proxy on every node programs iptables/IPVS rules

5. Production Architecture Variants

5.1 HA Control Plane

• 3-5 control plane replicas across availability zones – survives single AZ failure
• etcd as 3 or 5-node Raft cluster – odd number, quorum-based
• Load balancer in front of API Server replicas
• On EKS/AKS/GKE – managed by the cloud provider; you don’t see these details

5.2 Worker Node Pools

• Multiple node pools (system, application, GPU, spot) for workload isolation
• Taints + tolerations to keep node pools dedicated
• Pod Disruption Budgets to survive node drains during upgrades
• Cluster Autoscaler or Karpenter for node-level autoscaling

5.3 Add-Ons

• CoreDNS for cluster-internal DNS
• CNI plugin (Cilium recommended for new production clusters)
• Metrics Server for HPA (CPU/memory autoscaling)
• Cert-manager for automated TLS certificates
• Prometheus + Grafana stack for observability
• ArgoCD or Flux for GitOps deployment

6. Best Practices and Gotchas

• Never expose etcd directly – only the API Server should ever write to it
• Use HA control plane in production – single replica = single point of failure
• Run multiple worker node pools – don’t put system pods on the same nodes as your apps
• Set resource requests + limits on every container – prevents noisy-neighbour issues
• Use Pod Security Standards (Restricted) by default; opt-in to Privileged only where needed
• Keep K8s versions current – minor versions get ~14 months support; falling behind = security debt
• Use NetworkPolicy by default; cluster without policies = flat network = lateral movement risk
• Tag all workloads with app/env/team labels – cost visibility + RBAC scoping rely on labels

7. Why This Knowledge Pays in India

Direct answer: Indian senior DevOps and platform engineering interviews increasingly probe Kubernetes internals deeply. Engineers who can draw the architecture from memory, explain the data flow on `kubectl apply`, and trace a production failure through the components are 2-3x more likely to land senior offers.

7.1 Market Signals

• DevOps job listings grew 75% YoY (Spacelift 2025) – Kubernetes appears in 80%+ of senior cloud-native listings
• AWS holds ~29-30% of global cloud (Synergy Q3 2025) – most Indian K8s workloads run on AWS / Azure / GCP managed services
• Senior SRE interviews at Razorpay, Flipkart, Zomato, Cred routinely ask ‘walk through what happens when you kubectl apply’
• Engineers fluent in Kubernetes internals + observability + GitOps consistently command 30-45% premiums

7.2 What Hero Vired DevOps Course Covers

• 8-month duration with 70-90% live instructor-led sessions
• 7+ industry projects – multi-tier microservices on EKS/AKS/GKE, GitOps deploys, progressive delivery
• Skills covered: Advanced CI/CD Pipeline Architecture, Kubernetes at Scale, Infrastructure as Code (Terraform, Ansible), Container Orchestration, GitOps & Deployment Strategies, Advanced Monitoring & Logging, Security at Scale (DevSecOps)
• Multi-cloud – AWS, Azure (with Microsoft Azure content access), GCP – managed Kubernetes on each (EKS, AKS, GKE)
• Apply and master GenAI in DevOps – agentic AI for cluster cost optimisation, alert triage, manifest generation
• Career services – CV and LinkedIn branding, mock interviews, 1:1 personalised career coaching

7.3 Salary Impact in India

Ranges from Naukri, AmbitionBox, LinkedIn – see DevOps engineer salary, DevOps engineer skills, DevOps roadmap, and how to become a DevOps engineer.

8. Final Takeaway

Kubernetes architecture is the foundation for every cloud-native engineering decision. Master the control plane (API Server, etcd, Scheduler, Controllers, Cloud CCM) and the data plane (kubelet, kube-proxy, container runtime); understand the watch-and-reconcile flow; know how networking + storage + DNS plug in. For senior platform-engineering interviews, demonstrate fluency: ‘When I `kubectl apply`, the API Server validates and persists to etcd; the Deployment Controller creates a ReplicaSet; the Scheduler picks a node; kubelet pulls the image via containerd and starts the container; kube-proxy programs Service rules; status flows back through API Server.’ That’s the kind of practical answer that separates senior offers from rejections.

Related reads: Kubernetes interview questions, Kubernetes architecture deep-dive, Docker vs Kubernetes, Docker Swarm vs Kubernetes, and DevOps tools.