K8s Architecture

This section explains the complete Kubernetes architecture and dives into each of its core components in detail.

Kubernetes is built on a master–worker architecture, designed to manage containerized applications at scale. It brings together multiple loosely coupled components that communicate through the Kubernetes API to maintain a desired system state.

At a high level, Kubernetes has two major layers:

1. The Control Plane - the brain of the cluster that makes global decisions about scheduling, scaling, and management.

2. The Worker Nodes - the machines (physical or virtual) that run the actual application workloads.

Together, these layers form a self-healing, declarative system that continuously monitors and adjusts resources to match the desired configuration defined by users or automation tools.

The Control Plane

The Control Plane is responsible for the overall management of the Kubernetes cluster. It acts as the cluster’s central nervous system, storing data, making scheduling decisions, handling authentication, and orchestrating every workload.

Each component within the control plane has a dedicated responsibility but works in sync with others through the kube-apiserver.

Let’s break down each component technically.

1. kube-apiserver

The API Server is the heart of Kubernetes. It’s the single entry point through which every operation in the cluster passes whether from kubectl, the Kubernetes dashboard, other control plane components, or automation scripts.

• It exposes RESTful APIs that define how users and internal components interact with cluster resources (Pods, Deployments, Services, etc.).

• The API server performs:

  • Authentication & Authorization - verifies user identity and permissions.

  • Admission Control - validates or modifies requests before persisting them.

  • Object Validation - ensures submitted resource manifests are valid.

• Once validated, the API server stores the resource data in etcd (the cluster’s database).

The API server is stateless, which means it can be scaled horizontally by running multiple replicas behind a load balancer for high availability.

In essence:

The API server is the gatekeeper and communication hub of the entire Kubernetes cluster.

2. etcd

etcd is a distributed, consistent key-value store that holds the entire cluster state and configuration.

Everything in Kubernetes from Pod definitions to ConfigMaps and Secrets is stored in etcd as key-value pairs. If you lose etcd, you lose the cluster’s brain.

Technical aspects:

• Built on the Raft consensus algorithm, which ensures consistency across multiple etcd nodes.

• Every modification request (like creating a Pod or updating a Deployment) goes through the API server and is persisted in etcd.

• etcd provides watch mechanisms, allowing other components to subscribe and react to changes (e.g., a new Pod gets created → controllers act).

• In a high-availability setup, etcd runs as a clustered service (odd number of members, typically 3 or 5) to maintain quorum.

Think of etcd as the source of truth for your Kubernetes cluster.

3. kube-scheduler

The kube-scheduler is responsible for assigning newly created Pods to nodes in the cluster.

When a Pod is created and has no node assigned, the scheduler steps in to decide where it should run.

It makes this decision based on multiple criteria:

• Resource availability - CPU, memory, GPU, and ephemeral storage.

• Affinity and Anti-Affinity rules - preferences for co-locating or separating Pods.

• Taints and Tolerations - to restrict which Pods can run on specific nodes.

• Node Selectors / Labels - to target workloads to specific nodes.

• Topology and constraints - like zones, regions, and topology spread.

Once the scheduler chooses a node, it updates the Pod definition in the API server with that assignment. From there, the kubelet on that node takes over and starts the Pod.

In simpler terms:

The scheduler’s job is to find the best possible home for every Pod in the cluster.

4. kube-controller-manager

The Controller Manager runs a set of control loops that continuously monitor the state of the cluster.

Each controller watches the current state (from etcd) and compares it against the desired state. If there’s a difference, it acts to reconcile the two.

Examples of controllers include:

• Replication Controller / ReplicaSet Controller - ensures the desired number of Pod replicas are running.

• Node Controller - monitors node health and handles node failures.

• Endpoints Controller - manages Service endpoint objects that link Services to Pods.

• ServiceAccount and Token Controllers - manage default access tokens and accounts for Pods.

All these controllers run as separate processes within the kube-controller-manager binary for efficiency.

Essentially:

The Controller Manager keeps the cluster in the state you defined, no more, no less.

5. cloud-controller-manager

The Cloud Controller Manager is used in clusters running on public or private clouds. It allows Kubernetes to interact with cloud provider APIs (like AWS, GCP, Azure, etc.) without embedding cloud-specific logic inside core components.

Its main functions:

• Node Controller - adds or removes nodes from the cluster when cloud instances come and go.

• Route Controller - configures network routes in the cloud.

• Service Controller - creates load balancers for exposed services.

• Volume Controller - manages cloud-based storage volumes.

This separation ensures Kubernetes remains cloud-agnostic meaning you can run it anywhere, with cloud-specific integrations handled externally.

The Worker Node

The Worker Node is where your actual workloads the Pods and containers run. Each worker node runs a set of components that communicate with the control plane and manage local execution.

1. kubelet

The kubelet is an agent running on every worker node. It’s the bridge between the control plane and the node’s local environment.

It performs the following tasks:

• Watches the API server for new Pod assignments to its node.

• Ensures the containers defined in the Pod specs are running and healthy.

• Collects resource usage stats (CPU, memory) and reports them to the control plane.

• Performs liveness and readiness probe checks.

• Communicates with the container runtime (through the CRI Container Runtime Interface) to start, stop, or restart containers.

If a container crashes or becomes unhealthy, the kubelet ensures it’s restarted automatically.

You can think of the kubelet as the on-node manager that guarantees Pods run as intended.

2. kube-proxy

The kube-proxy handles networking on each node. It ensures that network traffic destined for Kubernetes Services is properly routed to the correct Pods, even as Pods scale up or move around.

Technical behavior:

• Manages iptables or IPVS rules to forward traffic.

• Provides cluster-wide service discovery so that applications can reach each other using stable DNS names instead of IPs.

• Supports Session Affinity when required (e.g., sticky sessions).

• Works with the CNI (Container Networking Interface) plugin to ensure Pods can communicate across nodes.

Essentially:

kube-proxy abstracts the complexity of dynamic container IPs and ensures networking “just works” inside the cluster.

3. Container Runtime

The Container Runtime is the actual engine responsible for running containers. Kubernetes uses a standardized interface called the Container Runtime Interface (CRI) to support different runtimes such as:

• containerd (default and most widely used)

• CRI-O

• Docker Engine (deprecated since v1.24, replaced by containerd)

Its responsibilities include:

• Pulling container images from registries.

• Creating and starting containers.

• Managing container lifecycle and resource isolation (CPU, memory, cgroups).

• Reporting container status to the kubelet.

Without a runtime, Kubernetes can’t actually execute the workloads.

4. Pods

A Pod is the smallest deployable unit in Kubernetes it represents one or more containers that share storage, networking, and lifecycle.

• All containers inside a Pod share the same network namespace and can communicate via localhost.

• Pods are ephemeral by design if one fails, Kubernetes replaces it automatically.

• Pods are scheduled onto nodes by the scheduler and managed by the kubelet.

In short:

A Pod is a wrapper around one or more containers that lets Kubernetes treat them as a single logical unit.

How It All Works Together

Here’s how the lifecycle flows through these components:

1. You run a command like kubectl apply -f deployment.yaml.

2. The API Server validates the request and stores it in etcd.

3. The Controller Manager notices a new Deployment and ensures a corresponding ReplicaSet exists.

4. The Scheduler assigns unscheduled Pods to worker nodes based on constraints and availability.

5. The Kubelet on the chosen node picks up the Pod spec, pulls the container image using the Container Runtime, and starts it.

6. The Kube-proxy configures networking so the Pod can communicate with other Pods and Services.

7. The Controller Manager continuously monitors to ensure that the desired number of Pods remain running.

This feedback loop continues indefinitely Kubernetes keeps reconciling the actual state with the desired state.

In a Nutshell

Kubernetes architecture is designed for declarative automation, scalability, and self-healing. Every component has a single, well-defined purpose, and together they form a resilient distributed system where the control plane makes decisions and the worker nodes carry them out.

When you understand how each piece fits, debugging, securing, or optimizing a cluster becomes much easier which is exactly what makes Kubernetes both powerful and elegant.