Mastering Kubernetes: Core Architecture, Networking, and Service Discovery Explained

Goal: Container Operations

Kubernetes (k8s) is an open‑source platform that automates 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.

Container grouping with built‑in load balancing.

Core Components

kubectl : client command‑line tool, the entry point for user operations.

kube‑apiserver : REST API server that exposes the control interface.

kube‑controller‑manager : runs background control loops (node status, pod counts, pod‑service bindings, etc.).

kube‑scheduler : assigns newly created pods to suitable nodes based on resource availability.

etcd : distributed key‑value store used for service discovery and configuration sharing.

kube‑proxy : runs on each node, proxies pod network traffic and enforces policies retrieved 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.

Multi‑Site High Availability (Two‑Site Three‑Center)

The design includes a local production center, a local disaster‑recovery center, and a remote disaster‑recovery center, addressing data‑consistency challenges with etcd as a highly available, strongly consistent store.

Four‑Layer Service Discovery

Kubernetes offers two native service‑discovery methods:

Environment variables : kubelet injects all Service information as env‑vars into a pod at creation time; this requires the Service to exist before the pod, limiting practical use.

DNS : a cluster‑add‑on (e.g., CoreDNS) creates DNS records for Services, enabling pods to resolve services via standard DNS queries.

Both methods operate over the transport layer (TCP/UDP) and rely on the underlying four‑layer network.

Five Pod‑Shared Resources

Containers within the same pod share five Linux namespaces and a volume:

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

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

IPC namespace – containers can use SystemV IPC or POSIX message queues.

UTS namespace – containers share the same hostname.

Volumes – storage defined at the pod level is accessible to all containers.

Pods are scheduled by a ReplicationController (or newer controllers) using a pod template, and each pod receives a unique IP address, enabling direct localhost communication between its containers.

Six Common CNI Plugins

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

Seven‑Layer Load Balancing

Load balancing progresses from layer‑2 (MAC‑based) to layer‑7 (application‑level) strategies. Kubernetes primarily exposes services via NodePort, which binds a port on each node and forwards traffic to pods. This approach has drawbacks such as port exhaustion and limited firewall rule applicability.

The preferred solution is an external load balancer (e.g., Nginx) that listens on a fixed port (typically 80) and forwards requests based on domain or service name. Kubernetes implements this pattern with Ingress , a layer‑7 routing resource.

Eight Isolation Dimensions

Kubernetes scheduling must respect isolation policies ranging from coarse‑grained node selection to fine‑grained pod‑level constraints (CPU, memory, network, security contexts, etc.).

Nine Network Model Principles

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

Each pod receives a unique IP address (IP‑per‑Pod model).

Pod IPs are routable across the cluster without NAT.

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

This model treats a pod like an independent VM or physical host from the perspective of port allocation, DNS, service discovery, and load balancing.

Ten IP Address Classes

Beyond the traditional A‑E classes, Kubernetes clusters use several special‑purpose address ranges.

A class: 1.0.0.0‑126.255.255.255, default mask /8 (255.0.0.0)
B class: 128.0.0.0‑191.255.255.255, default mask /16 (255.255.0.0)
C class: 192.0.0.0‑223.255.255.255, default mask /24 (255.255.255.0)
D class: 224.0.0.0‑239.255.255.255, used for multicast
E class: 240.0.0.0‑255.255.255.255, reserved for research

0.0.0.0 – default route (unspecified network)
127.0.0.1 – loopback address
224.0.0.1 – multicast address example
169.254.x.x – link‑local address (DHCP failure fallback)
10.x.x.x, 172.16‑31.x.x, 192.168.x.x – private address spaces used inside clusters

The article originally appeared on StackPush and was reposted from a CSDN blog. All promotional links, QR‑code invitations, and unrelated marketing content have been removed to focus on the technical material.