[面试题] Kubernetes面试高频8题：运维岗必会的核心知识点解析

在不少人的认知里，Kubernetes工程师的工作有时会被简单理解为“容器管理员”，这其实大大低估了其工作的技术复杂度和业务价值。随着企业数字化转型的深入，K8s工程师已成为保障应用稳定高效运行、实现资源智能调度和推动架构现代化的关键角色。这不仅要求他们精通K8s的核心原理，还需要具备出色的故障排查与集群优化能力。

本文基于对大量企业面试题的梳理，总结出面试官最爱问的八个K8s核心知识点，并附上详细的解析，旨在帮助你巩固基础，在技术面试中展现出扎实的功底。如果你对云原生技术体系的深入探讨感兴趣，可以访问相关技术社区进行交流。

一个目标：容器操作

Kubernetes（K8s）是一个用于自动化容器操作的开源平台。这些容器操作主要包括：部署、调度和节点集群间的扩展。

具体功能包括：

• 自动化容器的部署和复制。
• 实时弹性伸缩容器规模。
• 将容器编排成组，并提供容器间的负载均衡。
• 调度：决定容器在哪个节点上运行。

核心组成：

1. kubectl：客户端命令行工具，是整个系统的操作入口。
2. kube-apiserver：以 REST API 服务形式提供接口，作为整个系统的控制入口。
3. kube-controller-manager：执行整个系统的后台任务，例如监控节点状态、管理Pod数量、维护Pods和Service的关联等。
4. kube-scheduler：负责节点资源管理，接收来自 kube-apiserver 的创建 Pods 任务，并将其分配到合适的节点。
5. etcd：负责节点间的服务发现和配置共享，是一个高可用的键值存储系统。
6. kube-proxy：运行在每个计算节点上，负责 Pod 的网络代理。它会定时从 etcd 获取 Service 信息并据此制定转发策略。
7. kubelet：运行在每个计算节点上，作为节点代理，接收分配给该节点的 Pods 任务并管理容器，周期性获取容器状态并反馈给 kube-apiserver。
8. DNS：一个可选的 DNS 服务，用于为每个 Service 对象创建 DNS 记录，从而使所有 Pod 可以通过 DNS 域名来访问服务。

下面是典型的Kubernetes集群架构拓扑图：

两地三中心

“两地三中心”是一种常见的容灾架构，包括本地生产中心、本地灾备中心和异地灾备中心。

这种架构要解决的核心问题之一就是数据一致性。K8s 使用 etcd 组件作为一个高可用、强一致性的服务发现与存储仓库。etcd 是一个受到 Zookeeper 和 doozer 启发而设计的项目，除了拥有类似功能外，还有以下特点：

• 简单：基于 HTTP+JSON 的 API，使用 curl 命令即可轻松操作。
• 安全：支持可选的 SSL 客户端认证机制。
• 快速：每个实例每秒可支持上千次写操作。
• 可信：使用 Raft 算法充分实现了分布式一致性。

四层服务发现

在深入之前，我们先回顾一下网络七层协议（OSI模型）：

Kubernetes 主要提供了两种方式进行服务发现：

1. 环境变量：当创建一个 Pod 时，kubelet 会在该 Pod 中注入集群内所有 Service 的相关环境变量。但需要注意的是，要想让一个 Pod 中注入某个 Service 的环境变量，该 Service 必须先于该 Pod 创建。这个限制使得这种服务发现方式在实际中不太灵活。
   例如，一个 ServiceName 为 redis-master 的 Service，其 ClusterIP:Port 为 10.0.0.11:6379，则对应的环境变量可能如下所示：
   

2. DNS：可以通过集群插件（cluster add-on）的方式轻松创建 KubeDNS 或 CoreDNS，来为集群内的 Service 提供域名解析服务。

以上两种方式，一个是基于 TCP，另一个是基于 UDP 的 DNS，它们都是建立在四层传输层协议之上的。

五种 Pod 共享资源

Pod 是 K8s 中最基本的操作单元，它包含一个或多个紧密相关的容器。你可以将一个 Pod 看作应用层的“逻辑宿主机”。一个 Pod 中的多个容器应用通常是紧密耦合的，它们在同一个 Node 上被创建、启动或销毁。

同一个 Pod 内的应用容器共享以下五种资源：

• PID 命名空间：Pod 中的不同应用程序可以看到其他应用程序的进程 ID。
• 网络命名空间：Pod 中的多个容器能够访问同一个 IP 地址和端口范围。
• IPC 命名空间：Pod 中的多个容器能够使用 SystemV IPC 或 POSIX 消息队列进行通信。
• UTS 命名空间：Pod 中的多个容器共享一个主机名。
• Volumes（共享存储卷）：Pod 中的各个容器可以访问在 Pod 级别定义的 Volumes。

Pod 的生命周期通常由控制器（如 ReplicationController, Deployment）管理。Pod 通过模板定义，被分配到 Node 上运行，并在其内部所有容器运行结束后终止。Kubernetes 为 Pod 设计了独特的网络模型，例如为每个 Pod 分配一个独立的 IP 地址。

六个 CNI 常用插件

CNI（Container Network Interface）容器网络接口，是 Linux 容器网络配置的一组标准和库。开发者需要基于这些标准来开发自己的容器网络插件。CNI 只专注于解决容器网络连接和容器销毁时的资源释放问题，提供了一套框架。因此，CNI 能够支持大量不同的网络模式，并且易于实现。

常见的 CNI 插件如下图所示：

七层负载均衡

谈到负载均衡，就不得不先提服务器间的通信。IDC（Internet Data Center，互联网数据中心）是放置服务器的场所，其网络是服务器间通信的桥梁。

图中的网络设备各司其职：

• 内网接入交换机（TOR）：服务器接入网络的设备，通常下联 40-48 台服务器，使用一个 /24 的网段。
• 内网核心交换机：负责 IDC 内各接入交换机之间及跨 IDC 的流量转发。
• MGW/NAT：MGW（如 LVS）用于负载均衡；NAT 用于内网设备访问外网时的地址转换。
• 外网核心路由器：通过 BGP 等协议与运营商或上层网络平台互联。

负载均衡可以在不同网络层次实现：

• 二层负载均衡：基于 MAC 地址。
• 三层负载均衡：基于 IP 地址。
• 四层负载均衡：基于 IP + 端口。
• 七层负载均衡：基于 URL、HTTP头部等应用层信息。

四层与七层负载均衡的工作模式区别如下图所示：

前面“四层服务发现”中讲的主要是 K8s 原生的 kube-proxy 方式。K8s 默认通过 NodePort 方式暴露服务，即将 Service 绑定到 Node 的某个端口上。但这种方式存在缺陷：

• 如果 Service 很多，每个都需要占用主机端口，管理混乱且不安全。
• 难以满足一些严格的防火墙规则。

更理想的方案是使用一个外部的负载均衡器，绑定 80/443 等固定端口，然后根据域名或路径将请求转发到后端的 Service。Nginx 能很好地扮演这个角色，但问题在于：每当有新的服务加入，如何动态更新 Nginx 的配置？Kubernetes 给出的答案就是 Ingress，它是一个基于七层（HTTP/HTTPS）的解决方案。

八种隔离维度

现代大规模应用通常需要从多个维度进行资源与故障隔离，其粒度从粗到细如下图所示：

K8s 集群调度器需要针对这些从粗到细的隔离维度，制定相应的调度策略，例如利用节点亲和性、Pod 亲和性/反亲和性等来实现。

九个网络模型原则

Kubernetes 网络模型遵循一系列设计原则，可以概括为：4个基础原则、3个网络要求原则、1个架构原则和1个IP原则。

1. 每个 Pod 都拥有一个独立的 IP 地址。
2. 假定所有 Pod 都在一个可以直接连通的、扁平的网络空间中，无论是否运行在同一 Node 上，都可以直接通过 Pod IP 进行访问。
3. Pod 的 IP 是网络寻址的最小粒度。同一个 Pod 内所有容器共享一个网络堆栈（Network Namespace），此模型称为 IP-per-Pod 模型。
   • Pod 内容器看到的 IP 地址就是该 Pod 由网络插件（如docker0）实际分配的 IP。
   • Pod 内部看到的 IP 地址和端口与外部看到的一致。
   • 同一 Pod 内容器可通过 localhost 访问彼此的端口。
4. IP-per-Pod 模型使得 Pod 在端口分配、域名解析、服务发现、负载均衡等方面，可以被视为一台独立的虚拟机或物理机。

三个网络要求原则：

5. 所有容器无需 NAT 即可与所有其他容器通信。
6. 所有节点无需 NAT 即可与所有容器通信，反之亦然。
7. 容器的内部 IP 地址与外部看到的 IP 地址是同一个。

一个架构原则：网络模型需要支持类似下图的架构：

一个IP原则：由上述架构引申出从集群外部到内部的各种 IP 概念：

十类IP地址

众所周知，IP地址分为A、B、C、D、E五类，另外还有若干类具有特殊用途的IP地址。

第一类：主要地址分类

A 类：1.0.0.0-126.255.255.255，默认子网掩码/8，即255.0.0.0。
B 类：128.0.0.0-191.255.255.255，默认子网掩码/16，即255.255.0.0。
C 类：192.0.0.0-223.255.255.255，默认子网掩码/24，即255.255.255.0。
D 类：224.0.0.0-239.255.255.255，一般用于组播。
E 类：240.0.0.0-255.255.255.255(其中255.255.255.255为全网广播地址)。E 类地址一般用于研究用途。

第二类：特殊地址

0.0.0.0

0.0.0.0 表示所有不清楚的主机和目的网络，在本机路由表中没有特定路由条目时使用，通常作为默认路由。127.0.0.1 表示本机环回地址。

第三类：组播地址

224.0.0.1 组播地址。

如果你的主机开启了IRDP（Internet路由发现协议，使用组播功能），那么路由表中可能会有相关路由。

第四类：链路本地地址

169.254.x.x

当使用DHCP功能自动获取IP的主机，因DHCP服务器故障或响应超时，系统会分配此类地址，表示网络未能正常运行（APIPA机制）。

第五类：私有地址

10.xxx、172.16.x.x~172.31.x.x、192.168.x.x 私有地址。

这些地址被大量用于企业内部网络，保留它们是为了避免在接入公网时引起地址冲突。

掌握这些从基础概念到网络模型的系统化知识，能极大地帮助运维工程师理解Kubernetes的运作全貌，无论是在日常工作中还是技术面试里，都能做到心中有数，应对自如。