Kubernetes Architecture Overview: Container Operations, Service Discovery, Networking, and Load Balancing

One Goal: Container Operations

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

Specific functions:

Automated container deployment and replication.

Real‑time elastic scaling of container instances.

Container orchestration into groups with built‑in load balancing.

Scheduling determines on which machine a container runs.

Components: kubectl: client command‑line tool, the entry point for operating the whole system. kube-apiserver: provides a REST API interface and serves as the control entry point. kube-controller-manager: runs background tasks such as node status, pod counts, and pod‑service associations. kube-scheduler: manages node resources, receives pod creation requests from the API server and assigns them to nodes. etcd: stores configuration and service‑discovery data with strong consistency. kube-proxy: runs on each node, proxies pod network traffic and periodically fetches service information from etcd. kubelet: runs on each node as an agent, receives pod assignments, manages containers, and reports status to the API server.

DNS (optional): creates DNS records for each Service so pods can reach services via DNS names.

Kubernetes architecture topology 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.

The three‑center model solves the important problem of data consistency; k8s uses etcd as a highly available, strongly consistent service‑discovery store for configuration sharing.

etcd was inspired by Zookeeper and doozer, inheriting all their features and adding four key characteristics:

Simple: HTTP + JSON API usable with curl.

Secure: optional SSL client authentication.

Fast: each instance supports up to 1 000 writes per second.

Trustworthy: uses the Raft consensus algorithm.

Four‑Layer Service Discovery

First, a diagram explains the OSI seven‑layer protocol stack.

Kubernetes provides two ways to perform service discovery:

Environment variables : when a pod is created, kubelet injects environment variables for all services in the cluster. This method is rarely usable because a service must exist before the pod that consumes its variables.

DNS : a cluster add‑on such as KubeDNS can be deployed to provide DNS‑based service discovery.

Both methods operate at the transport layer (TCP for env‑vars, UDP for DNS) and rely on the underlying four‑layer protocols.

Five Types of Pod Shared Resources

A pod is the basic unit in Kubernetes, containing one or more tightly coupled containers. Containers in the same pod 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 the same hostname.

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

Pod lifecycle is managed by a Replication Controller, which creates pod templates and schedules them onto nodes. When all containers in a pod finish, the pod terminates.

Kubernetes gives each pod a unique IP address and uses the pod name as the hostname for intra‑pod communication.

Six Common CNI Plugins

CNI (Container Network Interface) defines a standard library for configuring container networking. It focuses on connecting containers and releasing resources when containers are destroyed, allowing many network models to be implemented easily.

The following diagram shows six widely used CNI plugins:

Seven‑Layer Load Balancing

Load balancing inevitably involves server‑to‑server communication.

An IDC (Internet Data Center) is a data‑center facility that houses servers; the IDC network is the bridge for server communication.

Typical network devices include:

Access switches (TOR) – connect servers; each switch typically serves 40‑48 servers within a /24 subnet.

Core switches – forward traffic between access switches and across IDC boundaries.

MGW/NAT – MGW (LVS) provides load balancing; NAT translates internal addresses for outbound traffic.

External core routers – connect to ISP or BGP networks for internet access.

Load balancing can be performed at different OSI layers:

Layer 2 – MAC‑address based balancing.

Layer 3 – IP‑address based balancing.

Layer 4 – IP + port balancing (NodePort in Kubernetes).

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

NodePort exposes a service by binding a port on each node, but it has drawbacks: many services require many open ports, and firewall rules become hard to manage. The ideal solution is an external load balancer (e.g., Nginx) that listens on a fixed port (such as 80) and forwards traffic to service IPs based on domain or service name. Kubernetes implements this via Ingress, a layer‑7 solution.

Eight Isolation Dimensions

Kubernetes scheduling must consider these isolation dimensions, ranging from coarse‑grained to fine‑grained, to apply appropriate placement strategies.

Nine Network Model Principles

Kubernetes network model follows four basic principles, three network‑requirement principles, one architecture principle, and one IP principle.

Each pod receives a unique IP address and is assumed to reside in a flat, directly reachable network space, regardless of the node it runs on.

The IP‑per‑Pod model treats the pod’s IP as the smallest addressable unit; containers inside a pod share the same network stack.

Pod IP is allocated by docker0.

The IP and port seen inside the pod are identical to those seen outside.

Containers in the same pod can communicate via localhost, similar to processes on a single VM.

Consequences of the IP‑per‑Pod model include:

All containers can communicate without NAT.

All nodes can interact with containers regardless of the NAT method used.

The container’s address is the same as the address seen by others.

The following diagram extends the architecture to illustrate IP concepts from outside the cluster to inside.