Master Kubernetes: Core Concepts, Architecture, and Real‑World Practices

Why Kubernetes Engineers Matter

Many people mistakenly view K8s engineers as merely "container administrators," underestimating the technical complexity and business value of their work. In today’s accelerated digital transformation, they are essential for ensuring efficient application operation, intelligent resource scheduling, and architectural upgrades, requiring deep knowledge of core K8s principles and troubleshooting skills.

Eight Classic K8s Interview Questions

Based on a systematic analysis of interview questions from numerous internet and traditional enterprises, we have compiled the eight most frequently asked core K8s topics, each accompanied by detailed explanations and reference answers to help you demonstrate solid technical competence and secure your desired offer.

A Goal: Container Operations

Kubernetes (K8s) is an open‑source platform for automated container operations, covering deployment, scheduling, and cluster‑wide scaling.

Key Functions :

Automated container deployment and replication.

Real‑time elastic scaling of container workloads.

Container grouping with built‑in load balancing.

Scheduling: determining on which node a container runs.

Core Components

kubectl : client command‑line tool, the entry point for operating the entire system.

kube‑apiserver : provides a REST API interface, the control entry point of the system.

kube‑controller‑manager : runs background tasks such as node status monitoring, pod count management, and service‑pod associations.

kube‑scheduler : manages node resources, receives pod‑creation tasks from the apiserver, and assigns them to appropriate nodes.

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

kube‑proxy : runs on each node, handling pod network proxying and periodically fetching service information from etcd.

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

DNS (optional) : provides DNS records for each Service, allowing pods to reach services via DNS names.

Two‑Site Three‑Center Model

The model includes a local production center, a local disaster‑recovery center, and a remote disaster‑recovery center, addressing data‑consistency challenges. K8s uses etcd as a highly available, strongly consistent service‑discovery store, inspired by Zookeeper and doozer, and offers four notable features:

Simple: HTTP + JSON API usable with curl.

Secure: optional SSL client authentication.

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

Trustworthy: Raft algorithm ensures robust distributed consensus.

Four‑Layer Service Discovery

K8s provides two service‑discovery mechanisms:

Environment Variables : kubelet injects environment variables for all Services into a pod at creation time. This method requires the Service to exist before the pod, limiting its practicality.

DNS : Deploying the KubeDNS add‑on creates DNS records for Services, enabling pods to resolve services via DNS names.

Both mechanisms operate over TCP/UDP at the transport layer.

Five Shared Resources in a Pod

A pod is the smallest deployable unit in K8s, containing one or more tightly coupled containers. Containers within the same pod share the following 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 the same hostname.

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

Pod lifecycle is managed by a Replication Controller, which defines a template and schedules pods onto nodes. When all containers in a pod finish, the pod terminates.

Pod Networking Model

K8s assigns each pod a unique IP address, assuming a flat, directly reachable network space where any pod can communicate with any other pod via its IP, regardless of node placement. This IP‑per‑Pod model treats a pod like an independent VM or physical host.

Six Common CNI Plugins

CNI (Container Network Interface) defines standards for container network configuration and teardown. It focuses solely on connectivity and resource cleanup, allowing many network modes to be implemented easily.

Seven‑Layer Load Balancing

Load balancing is built on server communication. In an IDC (data center), network devices such as access switches, core switches, MGW/NAT devices, and external routers play specific roles:

Access switch (TOR): connects servers, typically 40‑48 servers per switch, using a /24 subnet.

Core switch: forwards traffic between access switches and across data centers.

MGW/NAT: MGW (LVS) provides load balancing; NAT handles address translation for outbound traffic.

External core router: connects to ISP or BGP networks for internet access.

Load‑balancing can be classified by OSI layer:

L2 – MAC‑address based.

L3 – IP‑address based.

L4 – IP + port based.

L7 – Application‑layer (URL, host header) based, typically implemented with Ingress.

NodePort exposes services on a fixed node port, but it suffers from port exhaustion and firewall rule limitations. An external load balancer (e.g., Nginx) bound to a stable port (e.g., 80) can forward traffic based on domain or service name, and Kubernetes solves this with the Ingress resource, a layer‑7 solution.

Eight Isolation Dimensions

K8s scheduling must respect these dimensions, from coarse‑grained to fine‑grained isolation.

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 has a unique IP and can communicate directly with any other pod.

Pods use the IP‑per‑Pod model, where containers in the same pod share a network stack and can reach each other via localhost.

All containers see the same IP address externally and internally.

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 (255.255.255.255 is the broadcast address), reserved for research</code>
<code>0.0.0.0 – default route (unspecified address)</code>
<code>127.0.0.1 – loopback address</code>
<code>169.254.x.x – link‑local address (used when DHCP fails)</code>
<code>10.x.x.x, 172.16‑31.x.x, 192.168.x.x – private address ranges for internal networks