8 Must‑Know Kubernetes Core Concepts Every Engineer Should Master

Kubernetes (K8s) engineers are often underestimated as mere "container administrators," yet they play a pivotal role in digital transformation by mastering core K8s principles, troubleshooting, and optimization.

A Goal: Container Operations

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

Automated container deployment and replication.

Real‑time elastic scaling of container workloads.

Group orchestration with built‑in load balancing.

Scheduling containers onto specific machines.

Core Components

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

kube‑apiserver : REST API server that acts as the control plane interface.

kube‑controller‑manager : runs background tasks such as node status, pod counts, and service‑pod bindings.

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 traffic and syncs 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, enabling pod‑to‑service name resolution.

Two Sites Three Centers

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

K8s relies on etcd for high‑availability, strong consistency service discovery and configuration sharing. Etcd inherits ideas from Zookeeper and Doozer and adds four key traits:

Simple: HTTP + JSON API usable via curl.

Secure: optional SSL client authentication.

Fast: supports ~1,000 writes per second per instance.

Trustworthy: implements the Raft consensus algorithm.

Four‑Layer Service Discovery

K8s offers two native service‑discovery mechanisms:

Environment variables : kubelet injects all Service variables into a pod at creation time. This requires the Service to exist before the pod, limiting practical use.

DNS : Deploying the kube-dns add‑on creates DNS entries for each Service, enabling name‑based lookup.

Example: a Service named redis‑master with ClusterIP:Port 10.0.0.11:6379 results in environment variables such as REDIS_MASTER_SERVICE_HOST=10.0.0.11 and REDIS_MASTER_SERVICE_PORT=6379.

Five Pod Shared Resources

A pod is the smallest deployable unit in K8s, hosting one or more tightly coupled containers that share five resources:

PID namespace – containers can see each other’s processes.

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 common hostname.

Volumes – shared storage defined at the pod level.

Six Common CNI Plugins

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

Seven‑Layer Load Balancing

Load balancing in data centers (IDC) involves multiple network devices:

Access switches (TOR) connect servers to the network.

Core switches forward traffic between access layers.

MGW/NAT devices provide load‑balancing (LVS) and address translation.

External routers connect the IDC to the Internet via static or BGP links.

Load‑balancing can be classified by OSI layer:

Layer 2 – MAC‑based balancing.

Layer 3 – IP‑based balancing.

Layer 4 – IP + port balancing.

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

Eight Isolation Dimensions

K8s scheduling must respect isolation dimensions ranging from coarse‑grained to fine‑grained policies. The diagram below summarizes the eight dimensions.

Nine Network Model Principles

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

Every pod gets a unique IP and can communicate directly with any other pod (IP‑per‑Pod model).

Pod IPs are allocated from the host’s docker0 bridge.

Containers within the same pod share the network stack and can reach each other via localhost.

Ten IP Address Classes

A class: 1.0.0.0‑126.255.255.255, default mask /8 (255.0.0.0)</code>
<code>B class: 128.0.0.0‑191.255.255.255, default mask /16 (255.255.0.0)</code>
<code>C class: 192.0.0.0‑223.255.255.255, default mask /24 (255.255.255.0)</code>
<code>D class: 224.0.0.0‑239.255.255.255, used for multicast</code>
<code>E class: 240.0.0.0‑255.255.255.255, reserved for research</code>
<code>0.0.0.0 – default route (unspecified address)</code>
<code>127.0.0.1 – loopback address</code>
<code>224.0.0.1 – multicast address</code>
<code>169.254.x.x – link‑local address when DHCP fails</code>
<code>10.x.x.x, 172.16‑31.x.x, 192.168.x.x – private address space