Demystifying Kubernetes: How Its Architecture Powers Modern Cloud‑Native Apps

Kubernetes Architecture

Kubernetes has become the dominant platform for container orchestration. It is a cluster‑orchestration engine that offers features such as cluster scaling, rolling upgrades and rollbacks, elastic scaling, self‑healing, and service discovery.

From a high‑level perspective, the architecture consists of a Master, Nodes, and Etcd.

The Master (control plane) controls the entire cluster and includes the API Server, Scheduler, and Controller components, all of which interact with Etcd for data storage.

API Server : Provides a unified entry point for resource operations, abstracting direct interaction with Etcd and handling security, registration, and discovery.

Scheduler : Assigns Pods to Nodes based on scheduling rules.

Controller : Acts as the resource control center, ensuring resources reach their desired state.

Nodes are the worker machines that run containers and include the kubelet and kube‑proxy.

kubelet : Manages the lifecycle of containers, monitors health via cAdvisor, performs health checks, and reports node status.

kube‑proxy : Implements service discovery and load balancing within the cluster by watching Service/Endpoints changes.

Starting from Creating a Deployment

A Deployment is a controller resource used to orchestrate Pods. The following steps illustrate how the various components cooperate when a Deployment is created:

kubectl sends a request to create a Deployment.

The API Server receives the request and writes the relevant resources to Etcd; subsequent interactions follow the same pattern.

The Deployment controller watches for resource changes and issues a request to create a ReplicaSet.

The ReplicaSet controller watches for changes and creates Pods.

The Scheduler detects the unscheduled Pod and selects an appropriate Node based on matching and filtering rules.

kubelet on the selected Node discovers the new Pod and handles its creation and lifecycle management.

kube‑proxy initializes Service‑related resources, including service discovery and network load‑balancing rules.

Through this coordinated effort, the Deployment request results in fully running Pods.

Pod

Among Kubernetes API resources, the Pod is the most fundamental and smallest deployable unit.

Pods are designed for tightly coupled containers that need to share network, storage, and configuration, such as a servlet container and a log collector.

Containers within a Pod share the same network namespace via an infra container and can share storage by mounting the same volume.

Container Orchestration

Kubernetes excels at container orchestration. It provides various controller resources such as Deployment (stateless apps), StatefulSet (stateful apps), DaemonSet (daemon processes), and Job/CronJob (batch workloads).

Using Deployment as an example, the relationship is: Deployment controls the version of a ReplicaSet, and the ReplicaSet controls the number of Pods. This design enables horizontal scaling and versioned updates/rollbacks.

Horizontal Scaling

Scaling is achieved by adjusting the replica count in the ReplicaSet, e.g., changing from 2 to 3 replicas.

Update / Rollback

When updating from version v1 to v2, the v1 ReplicaSet’s Pods are gradually reduced to zero while the v2 ReplicaSet’s Pods increase to the desired count, achieving a seamless update; the reverse process performs a rollback.

Rolling Update

During a rolling update, Pods are upgraded one by one, ensuring at least two Pods remain available while up to four may serve traffic. This guarantees service continuity and easy rollback if a new version has bugs.

The RollingUpdateStrategy can be tuned with maxSurge (how many new Pods can be created) and maxUnavailable (how many old Pods can be removed).

Kubernetes Networking

After understanding orchestration, the next question is how containers communicate.

Kubernetes requires three basic connectivity guarantees:

Node ↔ Pod communication.

Pod ↔ Pod communication on the same Node.

Pod ↔ Pod communication across different Nodes.

In practice, pods on the same or different nodes communicate via the cni0 / docker0 bridge. Cross‑node pod communication is often implemented with solutions like Flannel (VXLAN or host‑gateway mode), which uses Etcd to discover node network information and configures routing tables.

Microservices – Service

A Service abstracts a set of Pods as a microservice, solving two problems: Pods have non‑stable IPs, and load‑balancing across Pods is needed.

Service selects Pods using label selectors to build an Endpoints list. Typically, Pods are labeled, e.g., app=xxx, and the Service uses the same selector app=xxx.

Service Discovery and Network Calls in Kubernetes

With the three‑way connectivity in place, Kubernetes enables both intra‑cluster (east‑west) and external (north‑south) traffic.

Service‑to‑Service Calls

Two common intra‑cluster call methods are:

ClusterIP : kube‑proxy creates a virtual IP (VIP) using iptables or IPVS; accessing the VIP load‑balances traffic to the backing Pods.

DNS : Each Service gets an A record like service-name.namespace-name.svc.cluster.local that resolves to the ClusterIP, allowing callers to use the Service name directly.

External Access

External traffic (north‑south) can reach the cluster via three Service types:

NodePort : Exposes a port on each Node’s IP; traffic to that port is forwarded to the Service.

LoadBalancer : Provisions a cloud provider’s load balancer that routes traffic to the Service.

Ingress : Provides a unified entry point, routing external requests to different Services based on rules; it typically relies on NodePort or LoadBalancer underneath.

In summary, we have covered the core concepts of Kubernetes, how its components collaborate, and how microservices run on top of it.