Comprehensive Guide to Kubernetes Architecture, Service Discovery, and Load Balancing

Hello, I am a top‑level architect.

One Goal: Container Operations

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

Key functions:

Automated container deployment and replication.

Real‑time elastic scaling of container workloads.

Container grouping with built‑in load balancing.

Scheduling determines on which machine a container runs.

Components:

kubectl – command‑line client.

kube‑apiserver – REST API entry point.

kube‑controller‑manager – background tasks such as node status, pod counts, and service associations.

kube‑scheduler – assigns pods to nodes.

etcd – high‑availability, strongly consistent key‑value store for configuration sharing and service discovery.

kube‑proxy – runs on each node, proxies pod network traffic based on etcd service information.

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

DNS – optional service that creates DNS records for each Service, enabling pod‑to‑service name resolution.

Kubernetes architecture diagram:

Two Locations Three Centers

The "two locations three centers" model includes a local production center, a local disaster‑recovery center, and a remote disaster‑recovery center.

Data consistency is ensured by using etcd as a highly available, strongly consistent service‑discovery store, inspired by Zookeeper and doozer, with four notable characteristics: simplicity (HTTP+JSON API), security (optional SSL client authentication), speed (≈1000 writes/sec per instance), and trustworthiness (Raft‑based consensus).

Four‑Layer Service Discovery

Kubernetes provides two native service‑discovery mechanisms:

Environment variables: When a pod is created, kubelet injects environment variables for all services in the cluster. This method requires the service to exist before the pod, limiting its practicality.

DNS: Deploying the KubeDNS add‑on creates DNS records for services, allowing pods to resolve services by name. Both mechanisms operate over the transport layer (env vars use TCP, DNS uses UDP) and rely on the underlying four‑layer network.

Five Types of Pod‑Shared Resources

A pod is the basic unit in Kubernetes, containing one or more tightly coupled containers that share several resources:

PID namespace – processes in different containers can see each other's PIDs.

Network namespace – containers share the same IP address and port range.

IPC namespace – containers can communicate via SystemV IPC or POSIX message queues.

UTS namespace – containers share a hostname.

Volumes – containers can access shared storage defined at the pod level.

Pods are managed by a ReplicationController, defined via a template and scheduled onto nodes. Kubernetes assigns each pod a unique IP (IP‑per‑Pod model) and treats the pod as an independent logical host.

Six Common CNI Plugins

The Container Network Interface (CNI) defines standards for Linux container networking. Six widely used CNI plugins are illustrated below:

Seven‑Layer Load Balancing

Load balancing across servers involves various network devices within an IDC (Internet Data Center). The layers are:

Layer 2 – MAC‑based balancing.

Layer 3 – IP‑based balancing.

Layer 4 – IP + port balancing.

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

Traditional NodePort service exposure binds a host port to each service, which leads to port proliferation and firewall rule complications. The preferred approach is to use an external load balancer (e.g., Nginx) combined with an Ingress controller for layer‑7 routing.

Eight Isolation Dimensions

Kubernetes scheduling must respect these isolation dimensions, ranging from coarse‑grained to fine‑grained constraints.

Nine Network Model Principles

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

Each pod receives a unique IP address, assuming a flat, fully reachable network space where any pod can reach any other pod directly, regardless of node placement (IP‑per‑Pod model).

Pod IP is allocated by docker0.

Pod‑internal IP and ports are visible externally.

Containers within the same pod share the network stack and can communicate via localhost .

This model makes a pod behave like an independent VM or physical machine from the perspectives of port allocation, DNS, service discovery, load balancing, and application configuration.

Further diagrams illustrate IP flow from outside the cluster to the internal network.

At the end of the article, the author provides a collection of BAT‑level interview questions and invites readers to join a WeChat group for further discussion and to receive additional resources.