Master Kubernetes: 8 Core Interview Questions and Essential Architecture Explained

In many people's perception, a K8s engineer is simply a "container administrator", which underestimates the technical complexity and business value of Kubernetes work. In the era of accelerated digital transformation, K8s engineers are a key force for efficient application operation, intelligent resource scheduling, and architectural upgrades, requiring mastery of core principles and troubleshooting skills.

Based on systematic analysis of interview questions from many internet and traditional enterprises, we have compiled the eight classic core K8s interview questions most loved by interviewers, along with detailed professional explanations and sample answers to help candidates demonstrate solid technical foundations and secure their desired offers.

Goal: Container Operations

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

Key functions:

Automated container deployment and replication.

Real‑time elastic scaling of container size.

Container orchestration with load balancing.

Scheduling: determining which machine a container runs on.

Components:

kubectl – command‑line client, the entry point for operating the system.

kube‑apiserver – REST API service providing the control interface.

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

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

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

kube‑proxy – runs on each node, handling pod network proxying and retrieving service information from etcd.

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

DNS – optional DNS service that creates DNS records for each Service, enabling pods to access services via DNS.

Architecture diagram:

Two Sites Three Centers

The "two sites three centers" model includes a local production center, a local disaster‑recovery center, and an off‑site disaster‑recovery center, addressing data consistency challenges.

K8s uses the etcd component as a highly available, strongly consistent service‑discovery store for configuration sharing.

etcd, inspired by Zookeeper and doozer, offers four notable 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 – Raft algorithm ensures distributed consistency.

Four‑Layer Service Discovery

K8s provides two service‑discovery methods:

Environment Variables : kubelet injects environment variables for all Services into a Pod at creation; this method requires Services to be created before the Pod, limiting its practicality.

DNS : Deploying KubeDNS as a cluster add‑on enables DNS‑based service discovery.

Both methods operate at the transport layer (TCP/UDP) and rely on lower‑layer protocols.

Five Shared Resources of a Pod

A Pod is the basic unit in K8s, containing one or more tightly coupled containers. Containers in the same Pod share:

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

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

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

UTS namespace – share the same hostname.

Volumes – shared storage defined at the Pod level.

Pod lifecycle is managed by a Replication Controller, defined by a template and scheduled onto a node. Kubernetes assigns each Pod a unique IP address and configures networking so that the Pod name can be used as a hostname.

Six Common CNI Plugins

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

Seven‑Layer Load Balancing

Load balancing involves communication between servers in an IDC (Internet Data Center). Key network devices include access switches (TOR), core switches, MGW/NAT devices, and external core routers.

Load‑balancing layers:

Layer 2 – MAC‑based.

Layer 3 – IP‑based.

Layer 4 – IP + port based.

Layer 7 – Application‑level (URL, etc.).

Four‑layer load balancing in K8s is typically implemented via kube‑proxy and NodePort services, which have limitations such as port exhaustion and firewall rule constraints. An external load balancer (e.g., Nginx) or Ingress controller provides a more flexible solution.

Eight Isolation Dimensions

K8s scheduling must consider isolation from coarse‑grained to fine‑grained levels, as shown in the diagram below.

Nine Network Model Principles

K8s networking follows four basic principles, three network‑requirement principles, one architecture principle, and one IP principle. Each Pod receives a unique IP address, forming an IP‑per‑Pod model where containers share the same network stack.

Key properties of the IP‑per‑Pod model:

All containers can communicate without NAT.

Node and container IPs are consistent.

Pods behave like independent VMs or physical machines from the perspective of port allocation, DNS, service discovery, and load balancing.

Ten IP Address Types

Traditional IP classes (A‑E) and special‑purpose addresses are summarized below.

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 assigned when DHCP fails.</code>

<code>10.x.x.x, 172.16.x.x‑172.31.x.x, 192.168.x.x – private address spaces.

Source: blog.csdn.net/huakai_sun/article/details/82378856