Kubernetes面试高频考点：从核心原理到故障排查全解析

Kubernetes 面试准备这件事，最怕的就是"背了十道题，面试官换一个问法就懵"。尤其是当面试从"Deployment 和 StatefulSet 有什么区别"这种入门题，突然跳到"Pod 一直 Pending，你怎么排查"这种实战题时，很多人的知识体系是断裂的。这篇分类汇总，我按自己面试和被面试的经验，把高频考点拆成八个大类，每一类都挑最硬核、最容易被追问的题来深挖。全文没有废话，全是可直接拿来用的思路、命令和避坑经验，适合那些已经看完基础概念、准备系统过一遍的开发者。

1. 分类体系总览：面试官到底在考什么

1.1 出题逻辑：从"会用"到"懂原理"的跃迁

Kubernetes 的面试题和别的技术栈不一样，它很少有"背下来就能过"的题目。两年前我面某厂的时候，初试问的还是"Service 有哪几种类型"，复试直接变成了"假如你有一条链路：Ingress —> Service —> Pod，流量走到 Pod 之前，kube-proxy 在底层做了什么操作"。这就是 K8s 面试的典型风格——先确认你会用，再确认你懂不懂它的设计哲学。

大多数求职者的误区在于把时间花在背命令、背 YAML 字段上，而忽略了"为什么这么设计"。比如"为什么 Deployment 滚动更新需要 maxSurge 和 maxUnavailable 两个参数"，这道题表面考参数，实际考的是可用性与资源消耗的权衡思路。面试官想听的答案绝对不是参数取值范围，而是你能否解释清楚"多启动一个 Pod 的代价是什么、少停一个 Pod 的风险是什么"。

另外，K8s 面试还有一个隐性筛选逻辑：排障能力。集群不可能永远不出问题，面试官会通过"Pendding 怎么查""CrashLoopBackOff 怎么查"这类题来判断你是操作工还是工程师。操作工能背出 kubectl 命令，工程师则有一整套从"现象 → 假设 → 验证 → 定位"的思维链条。这正好是分类汇总里要重点拆的部分。

1.2 分类框架：一份对照自查的清单

很多人复习 K8s 是一头扎进官方文档从头读到尾，这种方法效率极低。因为文档是按组件组织的，面试却是按场景组织的。我按面试场景，把高频考点分成了八类，每一类标了优先级和频率，你在复习的时候可以对照着查漏补缺。

划重点：故障排查和工作负载是必考，网络次之，存储和安全属于投简历岗位对口的加分项。如果你是面 SRE 或运维岗，存储和排障比重会明显上升；如果是开发岗，Controller 和 Operator 更容易被追问。

2. 核心组件工作原理：Controller 和 API Server 的高频题

2.1 Controller Manager 到底在干嘛？调谐循环怎么理解

这道题的经典问法是："Kubernetes 中 Deployment 创建了 ReplicaSet，ReplicaSet 创建了 Pod，这个链路是怎么串联起来的？"会背书的人直接说"Deployment controller 创建 ReplicaSet"，但面试官下一句就会问："那如果我把 ReplicaSet 的副本数直接改成 10，Deployment 会怎么反应？"

要答好这道题，必须理解调谐循环（Reconcile Loop）。每个 controller 内部都是一段无限循环的小程序，它不断做三件事：观察当前状态 → 对比期望状态 → 执行动作缩小差距。用伪代码表示：

go复制for {
    currentState := getCurrentState()   // 从 API Server 拉取实际对象
    desiredState := getDesiredState()   // 期望状态通常来自更上层的资源定义
    if currentState == desiredState {
        continue
    }
    // 执行 diff 操作，比如创建 Pod、更新副本数、删除垃圾资源
    applyChanges(currentState, desiredState)
    time.Sleep(reconcileInterval)
}

你手动把 ReplicaSet 副本数改成 10，ReplicaSet controller 发现当前状态是 10，期望状态（来自 Deployment 的 spec.replicas）是 3，它不会直接改回 3，而是先把 ReplicaSet 的副本书写回 3。紧接着 Deployment controller 观察到 ReplicaSet 的副本数和期望不一致，又会把它改回 3。最终所有状态都收敛到 Deployment 定义的值。

这里有个关键点：Controller 之间不打"电话"，只通过 API Server 读状态。这也是为什么 K8s 能容忍局部失败——某个 controller 挂了，其他 controller 依然会把这些对象改回去，形成一个自愈闭环。面试加分项：你可以提一句"Kubernetes 是声明式 API 的践行者，控制器模式把所有运维动作统一成观察 → 对比 → 执行三步"，这句话会让面试官觉得你不是在背题，而是真的理解了架构哲学。

2.2 API Server 和 etcd 怎么配合才能高可用？

面试官问 etcd 的时候，一般会从"为什么 etcd 要奇数节点"切入。很多人回答"为了防止脑裂"，这个方向对，但不够深。真正的背后逻辑是 Raft 协议——它是 K8s 控制面一致性的基石。

Raft 的核心原则是：集群中超过半数（quorum）的节点同意，才能提交一笔数据。3 节点集群允许挂 1 台，5 节点允许挂 2 台，这就是奇数节点存在的原因。如果你用 4 节点，最多也只能挂 1 台（否则达不到 2/4 的多数），那这 4 个节点的可用性和 3 个节点完全一样，纯属浪费资源。

更进一步的问题是"API Server 和 etcd 是同步写还是异步写"。实际上，K8s 的更新链路是：客户端发请求到 API Server → API Server 把对象序列化后写入 etcd → etcd 在多数节点落盘后返回成功 → API Server 再把结果返回给客户端。这是一个强一致的路径，保证了"写成功"这个结果在集群里是唯一可信的，不会出现两个节点各自持着不同的真相。这也是为什么生产环境推荐把 etcd 跑在独立节点上——它不只是慢一点的数据库，而是整个集群状态的唯一权威来源。

3. Service 网络和服务治理：背熟了也可能答错的题

3.1 Service 后端：iptables 还是 IPVS？

这道题是网络向的必考，而且非常容易答偏。经典的错误回答是："Service 是靠 kube-proxy 做负载均衡"。这句话没错，但它掩盖了底层真正的执行者——IPVS 或者 iptables，取决于你的 kube-proxy 模式。

如果是 iptables 模式，流量走到一个 Service IP 时会进入 PREROUTING 链，然后跳转到 KUBE-SVC-XXXX 链。这条链里每条规则对应一个后端 Pod，规则是按照随机概率写的，比如有 3 个后端 Pod，就会生成 3 条规则，权重各 1/3。核心问题是 iptables 匹配规则是从上到下顺序执行的，一旦匹配到就跳出，所以它天然是"近似随机"的负载均衡，转发效率在 Pod 数量多时并不理想。

如果是 IPVS 模式，它工作在 Linux 内核态，采用哈希表查找，时间复杂度是 O(1)，而且天然支持加权轮询、最少连接等负载均衡算法。一句话总结区别：iptables 是"线性扫描"，IPVS 是"哈希索引"。

那生产环境选哪个？我建议 IPVS。一方面性能更好，另一方面改动规则时不需要像 iptables 那样整个规则链重建，对存量连接更友好。但要提醒：IPVS 需要内核模块支持（ip_vs、ip_vs_rr 等），有些云主机默认没加载，需要加载完后重启 kube-proxy。

3.2 Ingress 和 IngressController 别再说混了

这题我面试过不少人，十有八九会把 Ingress 当成一个"流量入口组件"。严格来说，Ingress 只是一份定义路由规则的 API 对象，它本身是静态的 YAML，不执行任何转发动作。真正干活的是 IngressController，通常是一个实际的负载均衡器（比如部署成 Deployment 的 Nginx）。

我见过一个典型的坑：团队维护了一堆 Ingress，但没装 IngressController，域名怎么都解析不通。查了半天发现并没有任何 Pod 消费这些规则。

下面是一个最小可用的 Ingress 示例：

yaml复制apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: demo-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  ingressClassName: nginx
  rules:
  - host: demo.example.com
    http:
      paths:
      - path: /api
        pathType: Prefix
        backend:
          service:
            name: api-service
            port:
              number: 8080

如果你去查这个 Ingress，会看到它只是躺在 etcd 里的一段 JSON。IngressController 通过 watch 机制发现规则变化，更新自己的 Nginx 配置并 reload，流量才能通。回答时有个加分技巧：主动提一句"IngressController 本身也是 Pod，它挂了流量就断了，所以生产环境通常同时部署两个副本并且通过 Pod 反亲和性分散在不同节点"，这能展示你对"控制面和数据面"分离的敏感度。

4. 调度器和资源管理：理论与实践的结合

4.1 Pod 是怎么被调度到某节点的？

调度题考察的核心是"你知不知道 scheduler 不是一个玄学，而是一套可计算的流程"。整个调度过程分两阶段：过滤（Predicates）和打分（Priorities）。

过滤阶段是硬性的，不满足条件的节点直接淘汰。比如：节点资源不足以满足 Pod 的 requests，节点上有污点而 Pod 没有对应容忍，或者 Pod 声明了 nodeSelector 而节点没有对应标签。这阶段的目的就是快速收敛候选集。

打分阶段是软性的，对剩余候选节点按策略打分，最后选分最高的。常见策略包括：

• 资源最少请求优先：尽量把 Pod 分散到资源使用率低的节点，避免热点。
• 镜像本地优先：如果 Pod 的镜像已经在节点上存在，会加分，省去拉取时间。
• Pod 亲和/反亲和：让同类应用聚集或散开，比如让同一个工作负载的两个副本分布在不同的可用区机房。

如果这些默认策略不够用，K8s 允许你实现自定义调度器。原理也不复杂：你写一个程序监听 Pod 的调度请求，自己决定调度到哪个节点，写下 nodeName，然后把整个 Pod 对象 POST 回 API Server。自定义调度器适合处理 GPU 显存分配、多租户配额这类默认调度器算不了的需求。

4.2 Requests/Limits 与 QoS 的索命连环问

很多开发写资源声明时，长期只用 requests 不写 limits，或者干脆两个都不写。在开发环境没问题，生产环境这是大忌。面试官考这道题时，喜欢从一个实际现象切入："为什么我设置了 limits，Pod 还是被 OOM Killed 了？"

要答清这个问题，必须先理解 QoS 等级。K8s 把 Pod 分成三类：

OOM Kill 的逻辑和驱逐不同。当节点物理内存耗尽时，内核会根据 oom_score 选进程杀掉。而 oom_score 的计算里，Pod 的 QoS 等级和内存 usage 是决定性因素。所以如果一个 Burstable Pod 的容器内存使用超过了它自己的 limits，即使节点内存还多，也可能被内核杀掉。这在日志里的表现是容器退出码为 137。

另外建议补充一个监控维度：设置 limits 时，高于 requests 的部分会被视为不可压缩资源，超限会直接被杀；而 requests 是调度依据，高于 requests 时调度器会认为节点资源不足。换句话说，requests 管能不能调度上，limits 管容器会不会被杀，两者是两套独立机制。这个区分能让你在生产容量规划时游刃有余。

5. 存储与持久化：PVC 被绑定的前后

5.1 PV/PVC 动态供给到底怎么一步步完成的？

存储题的出镜率不如网络题，但在偏运维的岗位里是必考。高频题是："创建一个 PVC 之后，存储是怎么被准备的？"答案分四条路径：

• 静态供给：管理员手动创建一个 PV 对象，PV 关联底层的存储卷，等 PVC 来绑定。
• 动态供给：没有现成 PV，StorageClass 接单干活。
• 本地存储：hostPath、local 卷，PV 直接指向某个节点的目录，适合单机测试，不跨节点。
• CSI 驱动：接入云厂商或开源存储的标准接口，比如某云的云硬盘插件。

动态供给的完整流程是：用户创建 PVC → PVC 声明了 storageClassName → 对应的 StorageClass 里的 provisioner 组件（通常是一个 StatefulSet 部署的 Pod）收到通知，通过存储原生的 API 创建出实际磁盘 → provisioner 把磁盘信息封装成一个 PV 对象写入集群 → PV 和 PVC 状态变为 Bound → 之后 Pod 才能在 spec.volumes 里引用这个 PVC。

注意有个易混点：PV 和 PVC 的绑定是一对一的，一个 PV 只能被一个 PVC 使用。同一个 PVC 可以被多个 Pod 共享，但 PV 不行。这个设计保证了数据卷的独占性，避免数据写坏。

5.2 accessModes 配置错误导致挂载失败

AccessMode 是存储面试里一个隐蔽的失分点。常见的三种：

• ReadWriteOnce（RWO）：只能挂载到一个节点，磁盘卷原生限制。
• ReadOnlyMany（ROX）：可以被多个节点同时只读挂载，适合配置文件分发。
• ReadWriteMany（RWX）：可以被多个节点同时读写，NFS 就是典型。

这题的实际坑在于：你的 PV 创建时写了 RWO，然后你用 Deployment 在两个节点上都想挂它，结果 Pod 一直 ContainerCreating，事件里写着"volume is still attached to another node"。这在自家机房的内存盘、云硬盘场景排障时特别常见。排查思路很简单：看 PV 的 spec.accessModes 和 PVC 是否一致，再看底层卷是由单个节点独占还是支持多挂。牢记"RWX 是稀缺资源，RWO 是读多写少场景的默认选择"接不住这句话，后面就被追问"为什么云盘不支持 RWX"（单块盘只能绑定到一台虚拟机，这是物理限制）。

6. 安全与隔离：面试中拉开差距的点

6.1 RBAC 的鉴权流程：ServiceAccount Token 怎么带你进集群

安全向的题我不建议死记硬背，而是理解一个核心链路：认证（你是谁）→ 鉴权（你能干什么）→ 准入（要不要改一下）。面试官惯用的考题是"一个外部应用想访问集群内的 Pod 列表，怎么做到最小权限"。

回答时给出四步链路：

• 创建 ServiceAccount，例如在命名空间 app-team 里创建 app-monitor。
• 创建 Role 或 ClusterRole，定义对 pods 资源的 get/list 权限。
• 用 RoleBinding 把 ServiceAccount 绑到 Role 上，限定在哪个命名空间内生效。
• 应用侧带着 ServiceAccount 对应的 Token（通常以 Secret 或注入方式下发到 Pod 内），通过 K8s REST API 发起带 Bearer Token 的请求。

一个容易被忽略的细节是：ServiceAccount 本身就挂在 Pod 里，通过 /var/run/secrets/kubernetes.io/serviceaccount/token 路径挂载。如果应用部署的 Pod 没指定 serviceAccountName，它使用的是默认的 default SA，这个 SA 一般没有任何权限，请求 API Server 会被拒。面试时主动提一句"我给监控组件单独建了一个 SA，并绑定最小权限 Role，而不是直接给集群管理员"，会让面试官看到你的安全意识。

6.2 NetworkPolicy：怎么实现真正的微服务防火墙

大部分团队的安全策略停留在"私有网络内大家能互访"，这没有把 NetworkPolicy 用起来。面试题方向是"如果我想让只允许 A 服务访问 B 服务的 8080 端口，怎么做"，这是纯 YAML 场景。

需要声明：NetworkPolicy 是由 CNI 插件实现的，不是 K8s 内核直接管。如果集群的 CNI 不支持（比如比较老的 Flannel 模式不支持），那么这些策略实际无效。生产环境我推荐 Calico，它对 NetworkPolicy 的支持最成熟。

一个最小示例：

yaml复制apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-only-frontend
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - port: 8080

这里有几个易错点：第一，如果不写 policyTypes 里的 Egress，则 Egress 默认放行，只有 Ingress 被限制；第二，一旦创建了这个 NetworkPolicy，该命名空间下所有没被选中的 Pod 默认也变成拒绝其它入口流量，因为 NetworkPolicy 是"非白即黑"的模式。这和很多人的理解相反——不是"没被选中就放行"，而是"没被选中就全禁"。

7. 故障排查实战题：把你的排障能力变成答案

7.1 Pod 一直 Pending，从哪几个维度看？

排障题是所有面试环节里最能区分能力的部分。处理"Pod 一直 Pending"这类题，切记不要零散地报命令，要报一整套排查思路。

第一步，看事件：

bash复制kubectl describe pod <pod-name> -n <namespace>

这里能看到调度失败的具体原因，比如"0/3 nodes are available: 2 Insufficient cpu, 1 node(s) had taint"。最常见的三类原因：

• 资源不足：节点 CPU 或内存余量不够满足 requests，重点看 available 和 request 差值。
• 节点污点：节点有污点（比如 NoSchedule），Pod 没有容忍。常见于主动隔离节点做维护时，把节点打上污点。
• 存储不满足：PVC 未绑定，或者节点上所需的 GPU 资源不存在。

第二步，看节点状态和资源余量：

bash复制kubectl get nodes
kubectl describe node <node-name>

看是否 Ready，以及 Allocated resources 的占比。这里我要强调一个隐蔽坑：kubectl get nodes 显示 Ready 不代表能调度，如果节点被打了control-plane.kubernetes.io/exclude-from-external-load-balancers这类污点，普通工作负载是调度不上去的。

第三步，如果是多副本且只挂一部分，看看是否触发了 Pod 反亲和。有时候你设置了反亲和，但节点数量不够，调度器一样会把 Pod 卡在 Pending。这个问题 YAML 里看不出来，只有事件里会写"pod has anti-affinity conflict"。

7.2 CrashLoopBackOff 的排查路径

这道题的高频追问是"退出码 137 和 143 有什么区别"。我先给出速查表：

排查路径建议按序执行：

• 看完整日志：kubectl logs <pod-name> --previous，注意加 --previous 能拿到崩溃前的日志，不加的话可能只有当前容器的空日志。
• 如果是 137，去查节点内存：kubectl top nodes，大概率是 limits 设置过低或节点内存被打满。
• 如果是 1，重点查启动命令依赖，资源文件、数据库连接等。
• 再看存活探针：如果 livenessProbe 设的太苛刻（比如超时时间小于应用启动时间），K8s 会不断杀容器重启，同样会显示 CrashLoopBackOff。

我想强调一个很容易被忽略的机制：重启策略。Pod 的 restartPolicy 默认是 Always，意味着不管容器以什么方式退出，kubelet 都会尝试重启。如果业务进程设计成要"显式退出"（比如 leader 选举输了就自杀），在 K8s 里这种 Pod 会陷入无限重启循环。解决办法是给这类进程加环境变量，让它在失败时不返回非零码，或者直接把 restartPolicy 改成 OnFailure。

8. 进阶与生态：加分项储备

8.1 Operator 模式与 CRD，理解 K8s 的扩展性

如果在基础题答得都很顺的情况下，面试官会试探性地问一句"你有没有了解过 Operator"。这道题答好了就是明显的加分项。

用一段话来解释：CRD 允许你定义自己的资源类型，比如定义一个"RedisCluster"，里面包含 master 数量、副本数、版本号。Operator 就是一个"为你的自定义资源服务的 Controller"，它监听 RedisCluster 资源的变化，负责创建 StatefulSet、配置 Service、处理备份和升级。相当于你把自己的领域业务知识写成了控制逻辑，而 K8s 只是它的执行底座。

我踩过的一个实际坑是：很多人以为写了 CRD 就能自动管理资源，其实 CRD 只是定义"数据格式"，没有 controller 在跑，它完全不触发任何行为。CRD 要搭配一个能持续 listen 的 controller（也就是 Operator 里的核心），才能形成闭环。

8.2 多集群管理与 CNI 选型备查

到了高阶岗位，面试官可能会提"如果你有 5 个集群，分布在不同的机房，你会怎么管理"。

这个问题方向上没有标准答案，但你可以展示你有过全局视角。常见的方案有几种：联邦控制面（数据一致性）、集中式 GitOps 声明多个集群的配置、或者用较新的 Cluster API 来自动化集群生命周期。

对于 CNI 选型，我用一张表总结不同插件的侧重：

提醒一句：插件的选择直接影响集群网络的隔离能力和排查难度，别轻易在生产集群上来回切换。

个人的一点体会是：Kubernetes 面试本质上不是考记忆，而是考你用最小成本还原问题本质的能力。你不需要把官方文档所有的字段背下来，但需要理解"为什么"——为什么 controller 要不断 sleep、为什么 Raft 要多数派投票、为什么 NetworkPolicy 默认 deny。这套"原因链"整理得越清晰，面对面试官任意角度的追问，你就越不容易被打乱阵脚。准备阶段建议至少做一次模拟面试：找一个同伴随机从这份分类清单里抽题，问到你答不出为止，然后针对缺口专项补。这个方法比我当时闷头刷几百道题有效得多。