Mastering Kubernetes Architecture: From Pods to Multi‑Center Deployments

Goal: Container Operations

Kubernetes (k8s) is an open‑source platform for automating container operations such as deployment, scaling, and scheduling across node clusters.

Key Functions

Automated container deployment and replication.

Real‑time elastic scaling of container workloads.

Pod orchestration with built‑in load balancing.

Core Components

kubectl : command‑line client, entry point for all operations.

kube‑apiserver : REST API server, central control interface.

kube‑controller‑manager : runs background tasks (node health, pod counts, service‑pod bindings, etc.).

kube‑scheduler : assigns newly created Pods to suitable nodes.

etcd : highly available, strongly consistent key‑value store for configuration and service discovery.

kube‑proxy : runs on each node, proxies Pod network traffic based on service information from etcd.

kubelet : node‑level agent that receives pod assignments, manages containers, and reports status to the apiserver.

DNS (optional) : provides DNS records for each Service so Pods can resolve services by name.

Two‑Site Three‑Center Model

The model consists of a local production center, a local disaster‑recovery center, and a remote disaster‑recovery center, addressing data‑consistency challenges.

etcd serves as a high‑availability, strongly consistent store for configuration sharing and service discovery, inheriting ideas from Zookeeper and doozer and offering simplicity (HTTP + JSON API), optional SSL, high write throughput (≈1000 writes/s per instance), and Raft‑based reliability.

Four‑Layer Service Discovery

Kubernetes provides two native service‑discovery mechanisms:

Environment variables : kubelet injects all Service IP/Port pairs into a Pod as environment variables at creation time. This requires the Service to exist before the Pod, limiting practical use.

DNS (kube‑dns) : a cluster‑add‑on that creates DNS records for Services, allowing Pods to resolve services by name. DNS operates over UDP (layer 4) while the env‑var method uses TCP.

Five Types of Pod‑Shared Resources

Containers within the same Pod share the following resources, enabling efficient intra‑Pod communication:

PID namespace – processes can see each other's IDs.

Network namespace – shared IP address and port range.

IPC namespace – SystemV IPC or POSIX message queues.

UTS namespace – common hostname.

Volumes – shared storage defined at the Pod level.

Six Common CNI Plugins

The Container Network Interface (CNI) defines a standard for configuring container networking. Six widely used plugins are illustrated below.

Seven‑Layer Load Balancing

Load balancing in Kubernetes spans multiple OSI layers:

Layer 2 – MAC‑based balancing.

Layer 3 – IP‑based balancing.

Layer 4 – IP + port balancing (NodePort).

Layer 7 – URL or application‑level balancing (Ingress).

NodePort exposes services on a fixed node port, but suffers from port‑exhaustion and firewall‑rule limitations. Ingress, backed by an external load balancer (e.g., Nginx), provides a single entry point (typically port 80) and routes traffic based on host or path.

Eight Isolation Dimensions

Kubernetes scheduling must respect these isolation levels, from coarse‑grained (cluster‑wide) to fine‑grained (pod‑level) constraints.

Nine Network Model Principles

Kubernetes networking follows four basic principles, three network‑requirement principles, one architectural principle, and one IP principle. Key points include:

Every Pod receives a unique IP address, forming a flat, routable network space.

The IP‑per‑Pod model treats each Pod like an independent VM or physical host.

Containers in the same Pod share the network stack, enabling localhost communication.

Ten IP Address Categories

Beyond the classic A‑E classes, Kubernetes clusters use additional special‑purpose ranges:

A class: 1.0.0.0‑126.255.255.255 (default mask /8)
B class: 128.0.0.0‑191.255.255.255 (default mask /16)
C class: 192.0.0.0‑223.255.255.255 (default mask /24)
D class: 224.0.0.0‑239.255.255.255 (multicast)
E class: 240.0.0.0‑255.255.255.255 (research)
0.0.0.0 – default route
127.0.0.1 – loopback
10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 – private address space

Understanding these ranges is essential for designing cluster networking, service IP allocation, and external access strategies.