清浅池塘我是面试官，也被人面试过。面过的候选人里，能把Kubernetes常见问题背得滚瓜烂熟的大有人在，但真正能把"为什么这样设计"讲清楚的人，一年遇不到几个。Kubernetes的知识点就像一棵树，如果你只摘叶子，背再多面试题也经不住深挖一层。这篇文章我梳理了这些年积累的Kubernetes核心知识点，全部按面试问答的方式来写，但重点放在答案背后的逻辑和关联上，适合正在准备Kubernetes相关岗位面试的读者，也适合那些用Kubernetes做部署但总觉得哪里没吃透的开发者。
1. 面试官想从Kubernetes问题里看出什么
先把话放在前面：面试官问你Kubernetes知识点，很少是为了考你API怎么拼写，而是想通过你的回答判断三件事——你对分布式系统的理解深度、你排障时的思维路径、以及你有没有真正在生产环境里摸爬滚打过。这篇文章覆盖的内容基本都是围绕"理解深度"和"实战经验"两个维度展开的。
1.1 不要只背"是什么"，要讲清"为什么"
举个最常见的例子。面试官问"什么是Pod"，十个候选人里八个会回答"Pod是Kubernetes里最小的调度单元"。这个答案对不对？对，但毫无信息量。换个说法：Pod是Kubernetes中一组共享网络命名空间和存储卷的容器的集合，它是调度的原子单位，容器只是Pod内的普通成员。这样回答，面试官立刻就能判断你是背过概念还是真的理解Pod存在的意义——为什么要引入Pod这个层？因为多个进程共享同一个网络栈和存储上下文的需求太常见了，比如日志采集sidecar需要和业务容器共享网络才能访问localhost，这种场景必须有Pod这个抽象层。
类似地，当面试官问"Deployment和StatefulSet的区别"时，"一切都好"，SDN插件通过CNI给Pod分配IP，kubelet调用CRI运行时启动容器，kube-proxy根据Service配置写入转发规则。这套链路里，每一条消息的流向都有明确的协议和端口定义，生产环境排障时你能快速判断问题出在哪个环节。
1.2 面试里最常见的"追问节奏"
我面试别人时特别喜欢用连环追问的方式来验证候选人是不是真的懂。比如：
第一次问："Kubernetes的调度器是怎么工作的？"——大多数人都能答上"过滤加打分"。
第二次问："如果一个Pod一直Pending，你怎么排查？"——有人开始卡壳了。
第三次问："节点资源充足，但Pod还是Pending，是什么原因？"——到这个层面，能答上来的人基本就是有真实排障经验的。
这种追问节奏，比直接问"kubectl describe pod看到什么字段"要有效得多。所以这篇文章里，我在每个知识点下面都加了类似的追问视角，你能接住两三轮，面试基本就稳了。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. Pod、容器与探针的底层配合逻辑
Kubernetes里最核心也最容易被低估的概念就是Pod。很多初学者把它理解成"装容器的盒子"，实际上Pod有着非常具体的设计意图，面试中围绕Pod展开的问题通常能拉开候选人的档次。
2.1 Pod为什么需要pause容器
这是我在面试时特别喜欢问的一个细节。很多人知道Kubernetes创建Pod的时候会先启动一个pause容器（或叫infra容器），但不知道为什么。
pause容器的核心作用是作为Pod内所有容器的"基础设施"——它在Pod创建时第一个启动，负责创建并持有Pod的网络命名空间、PID命名空间（1.0版本之后）、IPC命名空间和UTS命名空间。后面启动的业务容器通过JoinNetworkNamespace的方式"加入"pause容器的网络栈，这样Pod内所有容器才能通过localhost互相通信，才能共享同一个IP地址。
这个设计不是Kubernetes团队拍脑袋想出来的，而是源于对实际问题的思考。不是每个进程都适合用"一个容器一个进程"的方式直接跑，比如一个应用既需要Nginx提供HTTP服务，又需要一个独立的sidecar进程负责日志采集，这两个进程确实有共享网络栈的需求，如果没有Pod这层抽象，你就得把所有功能塞进同一个容器里。也正是因为pause容器持有全部基础设施命名空间，当一个容器崩溃退出后，Pod内的网络栈不会受影响，其他容器可以继续工作。
追问一句：既然PID命名空间共享，那Pod里的进程能看到彼此吗？答案是pause容器本身和容器内PID1的进程关系需要开启shareProcessNamespace选项才能互相可见，默认是关闭的。这个细节知道的人不多，但在面试中如果主动讲出来，会非常加分。
2.2 容器探针的三种类型和使用场景
探针问题几乎是Kubernetes面试必考的内容，我认为核心不在于记住三个探针的名字，而在于讲清楚它们的配合逻辑和典型坑。
LivenessProbe决定容器要不要被重启，ReadinessProbe决定容器要不要从Service的Endpoints里摘除，StartupProbe决定——这句话我说得直白一点——给前两个探针争取多长时间。为什么要分三种？如果你有一个Java应用，启动就需要两分钟甚至更长，而容器本身启动很快，LivenessProbe可能在启动阶段就探测失败，直接触发重启，陷入重启循环。StartupProbe就是为这种场景设计的，它成功之前，Liveness和Readiness探针都会暂停工作，给慢启动应用留出一条活路。
三种探针的对比我用一个表格来总结，这个表格在面试复习时可以直接背：
| 探针类型 | 失败后果 | 典型场景 | 需要注意的坑 |
|---|---|---|---|
| LivenessProbe | 重启容器 | 进程死锁、内存泄漏导致无法响应 | 不要依赖外部依赖做Liveness判断，否则一次数据库抖动会让整个集群反复重启所有Pod |
| ReadinessProbe | 从Service Endpoints中摘除 | 应用初始化未完成、依赖服务不可用 | 探针超时时间太短会导致正常流量频繁中断 |
| StartupProbe | 重启容器（但给了缓冲时间） | 慢启动应用 | 失败阈值配太小，无法覆盖真实的启动时间 |
这里分享一个我踩过的真实坑：刚开始做容器化改造的时候，我把数据库连接检查放进了LivenessProbe，结果是数据库一主从切换，所有Pod的Liveness全部失败，集群进入连锁重启，故障时间从预期的5分钟延长到了40分钟。后来才想明白，Liveness探针应该只检查"当前进程是否还能正常提供内循环服务"，比如HTTP服务检查一个本地健康端点，外部依赖的健康状态应该交给ReadinessProbe去判断。
2.3 Pod生命周期、重启策略与优雅终止
面试中还经常考Pod的phase流转：Pending→Running→Succeeded/Failed，以及Unknown状态的含义。这里我重点讲一个细节——Pod的重启策略（restartPolicy）和Job场景的关系。
restartPolicy有Always、OnFailure、Never三种。很多人以为重启策略是"容器崩没崩"这个维度，但实际上它是"Pod里的容器退出后，kubelet要不要把它拉起来"这个维度。默认情况下，Deployment管理的Pod用Always，保证服务不中断。但在Job和CronJob场景里，如果任务跑完了，容器正常退出（exit code 0），Pod应该进入Completed状态，而不是被反复重启。所以Job场景通常配Never或OnFailure，否则任务永远结束不了。
另一个面试必考点是Pod优雅终止（Graceful Shutdown）的过程。当你执行kubectl delete pod时，Kubernetes会先向Pod发送SIGTERM信号，然后等待一个宽限期（默认30秒，可以在Pod的spec.terminationGracePerio