Kubernetes 面试这件事我聊过不下几十场也当过面试官那一侧。有个现象特别有意思很多人能把 Deployment 和 StatefulSet 的区别背得滚瓜烂熟但一问到“你线上集群的 etcd 备份策略是怎么设计的”“Pod 一直 Pending 你会按什么顺序排查”立刻就卡壳了。这说明一个问题——Kubernetes 面试题的核心从来不是考记忆而是考你对这套系统的运行逻辑有没有真正的体感。我写这篇东西是想把 Kubernetes 面试里那些高频但容易被答偏的题目拆开揉碎从面试官到底想听什么、你应该怎么组织答案、哪些细节能体现你的实战经验这几个角度来讲。不管你是准备跳槽的工程师还是刚开始接触容器编排的新手或者带团队需要把关招聘的技术负责人下面这些内容应该都能帮你把 Kubernetes 的知识体系从“背过”变成“懂了”。1. 面试官问架构题时真正在考察什么1.1 控制平面与数据平面的职责边界几乎每场 Kubernetes 面试都会从架构问起但很多人一上来就开始背组件列表apiserver、etcd、scheduler、controller-manager、kubelet、kube-proxy。背完就没了。面试官听完只会觉得你看了文档但没理解这套东西为什么这么设计。我通常会这样组织回答先把整个系统分成两个平面——控制平面负责“决定应该是什么状态”数据平面负责“让实际状态向期望状态靠拢”。这个“期望状态”和“实际状态”的分离是整个 Kubernetes 的设计哲学根基。apiserver 是所有操作的唯一入口它本身不存状态状态存在 etcd 里scheduler 只负责决定 Pod 该放到哪个节点它不负责启动容器controller-manager 里跑着一堆控制器每个控制器盯着某类资源发现实际状态和期望状态不一致就采取行动kubelet 是节点上的“工头”负责把调度过来的 Pod 真正跑起来并且持续向 apiserver 汇报节点和 Pod 的状态。这样回答的好处是你展示的不是记忆而是对系统运作方式的理解。面试官接着问“那 apiserver 挂了会怎样”你就能自然地推导出已有的 Pod 不会挂kubelet 继续跑着但新的调度、扩缩容、配置变更全部停摆因为所有写操作都要经过 apiserver。这种推导能力比背组件列表值钱得多。1.2 etcd 在面试中的高频追问点etcd 是 Kubernetes 面试里最容易拉开差距的知识点。初级岗位可能只问“etcd 是干什么的”中高级岗位一定会追问备份、恢复、性能、配额这些实操层面的东西。先说一个很多人忽略的点etcd 的数据一致性模型是基于 Raft 协议的集群里必须有过半节点存活才能正常读写。这意味着如果你部署了三个 etcd 节点挂掉一个还能正常工作挂掉两个就彻底不可用了。面试官问“etcd 集群能不能部署两个节点”答案是能部署但没意义因为两个节点挂一个就失去多数派可用性和单节点一样还多了一份维护成本。备份策略是另一个高频考点。我见过太多人回答“用 etcdctl snapshot save 定期备份”就结束了。但面试官想听的是备份频率怎么定备份文件存哪里恢复流程验证过吗恢复的时候要注意什么我的经验是备份频率取决于集群变更的频繁程度变更频繁的集群至少每小时一次变更少的每天一次也够但关键是恢复流程必须定期演练。恢复时有一个坑etcd 恢复后 apiserver 里的资源版本号会回退如果有控制器在这期间做了变更可能出现状态不一致所以恢复后要观察各控制器的行为。还有一个容易被问到的细节是 etcd 的空间配额。默认配额是 2GB超过之后 etcd 会进入只读模式整个集群的写操作全部失败。这个配额可以通过启动参数调整但更根本的解决办法是开启历史版本压缩定期清理旧版本数据。面试时能主动提到这一点说明你真正运维过 etcd。1.3 从组件故障推导系统行为面试官很喜欢用“如果某个组件挂了会怎样”来测试你对架构的理解深度。这类问题没有标准答案但有一个好的回答框架先判断这个组件在哪个平面、承担什么职责再推导它的缺失会影响哪些操作最后说明系统有没有自愈机制。举个例子scheduler 挂了会怎样已有的 Pod 不受影响因为它们已经调度完成了。但新创建的 Pod 会一直处于 Pending 状态因为没有组件给它们分配节点。这时候如果你手动指定 nodeName 创建 Pod它反而能跑起来因为绕过了调度器。这个细节能体现你对调度流程的理解。再比如 kubelet 挂了会怎样该节点上的 Pod 不会被自动迁移因为 kubelet 是节点上的代理它挂了之后节点状态会变成 NotReady但 Pod 本身还在跑容器运行时是独立的。默认情况下节点 NotReady 超过五分钟控制器才会把上面的 Pod 标记为需要重新调度而且这个行为还取决于 Pod 的容忍时间配置。这些细节在面试中说出来比泛泛而谈“高可用架构”有说服力得多。2. 工作负载与调度从“会用”到“会选”2.1 Deployment、StatefulSet、DaemonSet 的选型逻辑这道题几乎必问但很多人答成了功能对比表。面试官真正想听的是你的选型思路什么场景下你会选哪个为什么。我的回答习惯是先讲“有状态和无状态”这个分界线。Deployment 管的是无状态副本它假设所有副本完全等价可以随意替换、随意扩缩。StatefulSet 管的是有状态副本它给每个副本一个稳定的网络标识和独立的存储卷副本之间有顺序依赖。DaemonSet 则是另一条线它保证每个节点上跑一个副本典型场景是日志采集、监控代理、网络插件这些“节点级”的工作负载。选型的时候我会问自己三个问题这个服务需不需要稳定的网络标识需不需要每个副本独立的持久化存储副本之间有没有启动顺序依赖三个问题里只要有一个答案是“需要”就不能用 Deployment。反过来如果一个服务完全无状态用 StatefulSet 就是给自己找麻烦因为它的滚动更新和扩缩容都比 Deployment 慢而且管理复杂度高。DaemonSet 的选型更直接这个组件是不是每个节点都必须有一个如果是就用 DaemonSet。但要注意 DaemonSet 的 Pod 默认会容忍节点的各种污点这意味着它可能被调度到不健康的节点上所以如果你的 DaemonSet 对节点状态敏感需要额外配置容忍策略。2.2 调度器的工作流程与常见干预手段调度器的工作流程可以拆成两个阶段过滤和打分。过滤阶段把所有不满足 Pod 硬性要求的节点排除掉比如资源不够、端口冲突、节点选择器不匹配、污点不容忍。打分阶段对剩下的节点按优先级排序比如资源均衡度、亲和性权重、镜像本地性。最后选得分最高的节点。面试官常问的是“Pod 一直 Pending 怎么排查”。我的排查顺序是这样的先看事件描述kubectl describe pod 里的事件会直接告诉你调度失败的原因是资源不足、还是节点选择器没匹配上、还是污点问题。如果事件里写的是“Insufficient cpu”那就是集群资源真的不够需要扩容或者调整资源请求。如果写的是“node(s) didnt match node selector”那就是标签或者选择器配错了。如果写的是“node(s) had taint that the pod didnt tolerate”那就是污点容忍没配好。干预调度的手段主要有几种nodeSelector 是最简单的直接指定节点标签nodeAffinity 更灵活支持硬性要求和软性偏好podAffinity 和 podAntiAffinity 控制 Pod 之间的位置关系比如把同一服务的副本打散到不同节点taint 和 toleration 则是从节点侧控制哪些 Pod 能上来。这些手段的优先级和组合效果是面试中容易追问的点比如 nodeSelector 和 nodeAffinity 同时配置时两者是“与”的关系必须同时满足。2.3 资源请求与限制的实战配置resources.requests 和 resources.limits 的区别是基础题但真正能讲清楚的人不多。requests 是调度器用来判断节点资源够不够的依据limits 是容器运行时用来限制容器实际用量的上限。关键点在于requests 影响调度limits 影响运行。CPU 和内存的行为还不一样。CPU 是可压缩资源超过 limit 之后容器会被限流但不会被杀掉。内存是不可压缩资源超过 limit 之后容器会被 OOM Killer 干掉。这个差异在面试中经常被追问因为它直接关系到线上稳定性。我在实际配置时的经验是requests 要按服务的实际基线用量来设不要拍脑袋。设太高会导致节点利用率低、调度不上去设太低会导致节点超卖、Pod 之间抢资源。limits 的设置要看服务对延迟的敏感程度延迟敏感的服务 CPU limit 可以设得宽一些甚至不设但内存 limit 一定要设否则一个内存泄漏就能把节点拖垮。还有一个容易被忽略的点是 QoS 等级。requests 和 limits 都设了且相等的是 Guaranteed只设了 requests 的是 Burstable什么都没设的是 BestEffort。节点资源紧张时BestEffort 的 Pod 最先被驱逐Guaranteed 的最后被驱逐。面试时能主动提到 QoS 和驱逐顺序的关系说明你考虑过线上稳定性。3. 网络与服务发现面试中最容易露怯的环节3.1 Service 的四种类型与底层实现Service 这道题初级回答是“ClusterIP、NodePort、LoadBalancer、ExternalName 四种类型”中级回答要讲清楚每种类型的底层实现和适用场景。ClusterIP 是最基础的它给一组 Pod 提供一个虚拟 IPkube-proxy 在每个节点上维护转发规则把发往这个虚拟 IP 的流量转发到后端 Pod。NodePort 是在 ClusterIP 的基础上在每个节点上开一个端口外部通过“节点 IP 加端口”访问。LoadBalancer 是在 NodePort 的基础上向云平台申请一个负载均衡器把外部流量导进来。ExternalName 比较特殊它不做任何转发只是把 Service 名称解析成一个外部域名相当于一个 DNS 别名。面试官常追问的是 kube-proxy 的工作模式。iptables 模式是传统方案它为每个 Service 生成一堆 iptables 规则流量大了之后规则数量膨胀性能会下降。ipvs 模式用内核的 IPVS 模块做负载均衡支持更多调度算法规则管理也更高效大规模集群下表现更好。现在很多发行版默认用 ipvs 模式但 iptables 模式仍然常见因为它的兼容性更好。还有一个高频追问点是“Service 的 ClusterIP 能不能 ping 通”。答案是通常不能因为 ClusterIP 是虚拟 IP只存在于 iptables 或 ipvs 的转发规则里没有实际的网络接口响应 ICMP。这个细节能区分出你是真用过还是只背过概念。3.2 Ingress 与 Service 的关系辨析很多人把 Ingress 和 Service 混为一谈面试时说不清楚两者的分工。我的解释是Service 解决的是“集群内部怎么找到一组 Pod”的问题Ingress 解决的是“集群外部怎么把 HTTP 流量路由到不同的 Service”的问题。Ingress 本身只是一个路由规则的声明它需要配合 Ingress Controller 才能真正工作。Ingress Controller 是一个跑在集群里的反向代理它监听 Ingress 资源的变化把规则翻译成自己的配置。常见的 Ingress Controller 有基于 Nginx 的、基于 Envoy 的、基于 Traefik 的选型时主要看你对哪种代理更熟悉、需要哪些高级功能。面试中经常被问的是“Ingress 能不能做 TCP 或 UDP 的转发”。标准 Ingress 资源只支持 HTTP 和 HTTPS但很多 Ingress Controller 通过注解或者自定义资源支持 TCP 和 UDP。这个点要答得准确不是 Ingress 不支持是标准资源定义里没有具体要看 Controller 的实现。3.3 NetworkPolicy 的实际生效条件NetworkPolicy 是 Kubernetes 网络部分的高频考点但很多人只知道“它能控制 Pod 之间的流量”不知道它的生效前提。关键前提是NetworkPolicy 需要网络插件支持才能生效。Calico、Cilium、Weave 这些插件都支持但有些简单的网络插件不支持。如果你的集群用的插件不支持 NetworkPolicy那你写了规则也不会生效而且不会有任何报错这个坑很隐蔽。另一个容易答错的点是默认行为。Kubernetes 的默认行为是“全部允许”也就是说如果一个 Pod 没有任何 NetworkPolicy 选中它它的所有进出流量都是放行的。只有当你创建了一个选中它的 NetworkPolicy并且策略类型里包含了 Ingress 或 Egress对应的方向才会变成“默认拒绝只放行规则里允许的流量”。这个“默认允许”到“默认拒绝”的切换逻辑是面试中经常挖坑的地方。我在实际配置时的经验是先写一条“默认拒绝所有入站”的策略作为基线再逐条添加允许规则。这样比反过来写更安全因为漏写一条允许规则最多是服务不通漏写一条拒绝规则可能是安全漏洞。4. 存储与配置管理区分“用过”和“用对”4.1 PV、PVC、StorageClass 的协作链路存储这块的面试题核心是搞清楚 PV、PVC、StorageClass 三者的关系和绑定流程。PVC 是用户提出的存储需求比如“我要 10GB 的读写一次存储”。PV 是管理员提供的存储资源比如“这里有一块 100GB 的云盘”。StorageClass 是动态供应的模板它定义了“当用户提出 PVC 时用哪个存储插件、按什么参数创建 PV”。绑定流程是这样的用户创建 PVC系统先找有没有匹配的现成 PV有就绑定没有就看 PVC 指定的 StorageClass如果有就调用对应的供应器动态创建一个 PV 再绑定如果既没有现成 PV 也没有 StorageClassPVC 就一直处于 Pending 状态。面试官常追问的是访问模式。ReadWriteOnce 表示只能被一个节点以读写方式挂载ReadOnlyMany 表示可以被多个节点以只读方式挂载ReadWriteMany 表示可以被多个节点以读写方式挂载。这里有个容易混淆的点ReadWriteOnce 限制的是节点数量不是 Pod 数量。同一个节点上的多个 Pod 可以同时挂载同一个 ReadWriteOnce 的卷。这个细节在面试中说出来很加分。4.2 ConfigMap 与 Secret 的使用边界ConfigMap 和 Secret 都是用来把配置从镜像里解耦出来的但两者的定位不同。ConfigMap 存的是非敏感配置Secret 存的是敏感信息比如密码、令牌、证书。Secret 的“加密”是一个常见的误解。默认情况下Secret 在 etcd 里是 base64 编码存储的不是加密。base64 只是编码任何人都能解码。要真正保护 Secret需要开启 etcd 的静态加密或者用外部的密钥管理服务。面试时如果被问到“Secret 安全吗”要能说清楚这个区别。另一个实战中的坑是ConfigMap 和 Secret 更新之后已经挂载到 Pod 里的文件会不会自动更新答案是以卷方式挂载的会自动更新有延迟以环境变量方式注入的不会更新必须重启 Pod。这个差异在配置热更新场景下非常关键面试中经常被用来测试你有没有踩过这个坑。4.3 有状态服务的存储编排要点StatefulSet 配合 PVC 的存储编排是面试中的进阶题。核心机制是 volumeClaimTemplates每个 StatefulSet 的副本会自动创建一个独立的 PVC命名规则是“模板名加 Pod 名”。这意味着副本缩容再扩容时新的 Pod 会复用之前同名的 PVC数据不会丢。这个机制的好处是数据持久性有保障但坏处是 PVC 不会随着 StatefulSet 的删除而自动清理需要手动管理。面试时能提到这个“残留 PVC”的问题说明你真正运维过有状态服务。还有一个细节是 Pod 管理策略。默认的 OrderedReady 策略要求 Pod 按顺序逐个创建、按逆序逐个删除这在主从架构的服务里很重要因为从节点需要等主节点就绪。但如果你的服务副本之间没有顺序依赖可以改成 Parallel 策略加快扩缩容速度。5. 排错与运维面试中最能体现经验的部分5.1 Pod 异常状态的排查链路面试官问排错题考的不是你知不知道某个命令而是你有没有一套系统的排查思路。我通常按“从外到内、从粗到细”的顺序来组织答案。第一步看 Pod 的状态和事件。kubectl get pod 看状态是 Pending、Running、CrashLoopBackOff 还是 ImagePullBackOffkubectl describe pod 看事件里的具体报错。这一步能定位大部分问题。第二步看日志。kubectl logs 看当前容器的日志如果容器重启过加 --previous 看上一次的日志。很多启动失败的原因在日志里写得很清楚比如配置文件找不到、端口被占用、依赖服务连不上。第三步进容器看。kubectl exec 进去检查文件系统、网络连通性、进程状态。这一步适合排查“容器起来了但行为不对”的问题。第四步看节点。如果 Pod 被驱逐或者节点 NotReady要看节点的资源使用、kubelet 状态、容器运行时状态。这个链路的关键是每一步都有明确的判断依据而不是盲目地挨个试。面试时能把每一步“看到什么现象就往下走哪一步”讲清楚比罗列命令列表有说服力。5.2 集群层面的故障定位思路集群层面的故障比 Pod 层面的更难排查因为涉及多个组件的交互。我遇到过几次 apiserver 响应变慢的情况排查过程很有代表性。先看 apiserver 的指标请求延迟、请求量、错误率。如果延迟高但错误率不高通常是 etcd 的问题因为 apiserver 的读操作大量依赖 etcd。接着看 etcd 的指标磁盘写入延迟、leader 切换次数、db 大小。如果 etcd 的磁盘延迟高可能是磁盘 IO 瓶颈也可能是历史版本太多导致 db 膨胀。还有一个常见问题是节点 NotReady。排查顺序是先看节点状态和条件kubectl describe node 里会显示 MemoryPressure、DiskPressure、PIDPressure 这些条件再看 kubelet 日志通常是证书过期、容器运行时无响应、或者节点资源耗尽最后看网络连通性节点到 apiserver 的网络是否正常。面试时讲这类故障重点不是讲你用了什么命令而是讲你怎么从现象推导到根因。比如“apiserver 延迟高我先排除 etcd 的问题因为 apiserver 本身是无状态的它的性能瓶颈大概率在下游”这种推理过程才是面试官想听的。5.3 滚动更新与回滚的实战细节滚动更新是 Deployment 的默认更新策略但很多人只知道“它会逐个替换 Pod”不知道背后的参数控制。maxSurge 控制更新过程中最多可以超出期望副本数多少个 PodmaxUnavailable 控制最多可以有多少个 Pod 不可用。这两个参数的组合决定了更新的速度和可用性。比如副本数是 10maxSurge 是 25%maxUnavailable 是 25%那更新过程中最多有 13 个 Pod10 加 3 个 surge最少有 8 个可用10 减 2 个 unavailable。面试官常问的是“滚动更新卡住了怎么办”。kubectl rollout status 看进度kubectl rollout history 看历史版本kubectl rollout undo 回滚到上一个版本。但卡住的常见原因是新版本的 Pod 起不来比如镜像拉取失败、健康检查不通过、资源不够。这时候要先看新 Pod 的事件和日志定位原因而不是直接回滚。回滚只是止血根因不解决下次还会出问题。还有一个细节是 revisionHistoryLimit它控制保留多少个历史版本用于回滚默认是 10。如果设成 0就没法回滚了。这个参数在面试中偶尔会被问到答得出来说明你关注过细节。6. 安全与权限中高级岗位的分水岭6.1 RBAC 的核心概念与常见配置RBAC 是 Kubernetes 权限控制的基础核心概念有四个Role、ClusterRole、RoleBinding、ClusterRoleBinding。Role 定义一组权限作用范围是某个命名空间ClusterRole 定义的权限作用范围是整个集群RoleBinding 把 Role 或 ClusterRole 绑定到用户、组或 ServiceAccount 上作用范围是某个命名空间ClusterRoleBinding 把 ClusterRole 绑定到主体上作用范围是整个集群。面试中容易混淆的点是ClusterRole 能不能被 RoleBinding 引用答案是能。这样做的效果是把集群级别的权限限制在某个命名空间内生效。这个用法在实际中很常见比如让某个命名空间的管理员能查看节点信息但只能在这个命名空间里操作。另一个高频追问是 ServiceAccount 的权限管理。默认情况下Pod 里的进程使用 default ServiceAccount这个账号通常权限很小。如果 Pod 需要访问 apiserver要给它绑定合适的 Role。这里有个安全实践不要给 default ServiceAccount 绑太大权限而是为每个需要权限的工作负载创建独立的 ServiceAccount按最小权限原则绑定。6.2 Pod 安全上下文的关键字段Pod 和容器的安全上下文SecurityContext是面试中区分度很高的知识点。常用的字段有 runAsUser、runAsGroup、runAsNonRoot、readOnlyRootFilesystem、allowPrivilegeEscalation、capabilities。runAsNonRoot 设为 true 时如果镜像里指定的用户是 rootPod 会启动失败。这个字段是防止容器以 root 运行的第一道防线。readOnlyRootFilesystem 设为 true 时容器的根文件系统是只读的能有效防止攻击者在容器里写入恶意文件。allowPrivilegeEscalation 设为 false 时容器里的进程不能通过 setuid 等方式提升权限。capabilities 用来精细控制容器的 Linux 能力。默认情况下容器有一组能力可以通过 drop 全部删掉再按需 add。比如一个只需要绑定低端口的服务可以 drop 掉所有能力再 add NET_BIND_SERVICE。面试时能把这些字段和实际安全场景对应起来讲比如“我会给所有生产环境的 Pod 设置 runAsNonRoot 和 readOnlyRootFilesystem除非它有明确的写文件需求”这种回答体现的是安全意识不是死记硬背。6.3 镜像与供应链安全的面试视角镜像安全在面试中的比重越来越高。核心话题包括镜像来源可信、镜像扫描、最小化基础镜像、不在镜像里硬编码密钥。镜像来源可信是指只从受控的镜像仓库拉取镜像并且开启镜像签名验证。镜像扫描是指定期扫描镜像里的已知漏洞常见的工具有 Trivy、Grype 这类。最小化基础镜像是指用 distroless 或者 alpine 这类精简基础镜像减少攻击面。不在镜像里硬编码密钥是指把敏感配置通过 Secret 注入而不是打进镜像层。面试官可能会问“你怎么保证线上跑的镜像就是经过审核的镜像”。回答的思路是在 CI 流水线里做镜像扫描和签名在集群的准入控制里做验证只允许签名匹配的镜像被调度。这个链条能讲清楚说明你对供应链安全有体系化的理解。7. 高频场景题的答题框架7.1 设计类问题的拆解方法面试中经常出现“设计一个高可用服务”或者“设计一个日志采集方案”这类开放题。很多人一上来就开始堆技术名词结果逻辑混乱。我的框架是先明确需求和约束再拆解成几个子问题最后给出方案并说明取舍。以“设计一个高可用 Web 服务”为例。先明确需求QPS 大概多少、可用性要求几个 9、有没有状态、部署在几个可用区。然后拆解接入层用什么、应用层怎么部署、数据层怎么保证一致性、监控和告警怎么做。最后给方案接入层用负载均衡加 Ingress应用层用 Deployment 多副本加反亲和打散数据层用有状态服务加主从复制监控用 Prometheus 加告警规则。关键是每一步都要说明“为什么这么选”。比如为什么用反亲和而不是直接多副本因为多副本可能被调度到同一个节点节点挂了副本全没反亲和能保证副本分散在不同节点甚至不同可用区。7.2 故障排查类问题的回答结构故障排查题的答题结构我总结为四步现象描述、影响范围、排查过程、根因与修复。现象描述要具体比如“某个服务的 Pod 频繁重启重启间隔大约五分钟”。影响范围要明确比如“只有这个服务的读接口受影响写接口正常”。排查过程要体现逻辑比如“先看 Pod 事件发现是存活探针失败再看探针配置发现超时时间设得太短最后看应用日志发现启动时加载缓存需要较长时间”。根因与修复要对应比如“根因是探针超时时间小于应用启动时间修复方案是调大探针的 initialDelaySeconds”。这个结构的好处是即使你没有真正遇到过这个故障也能展示出系统的排查思维。面试官看重的是思维过程不是你背了多少故障案例。7.3 版本升级与集群维护的注意事项集群版本升级是运维中的高风险操作面试中经常被问到。核心注意事项有几点先升级控制平面再升级工作节点、升级前备份 etcd、升级前检查 API 废弃情况、升级后验证核心工作负载。API 废弃是一个容易被忽略的点。Kubernetes 每个大版本都会废弃一些 API比如某些资源从 beta 变成正式版时旧的 API 版本会被移除。升级前要用工具扫描集群里有没有使用即将废弃的 API提前迁移。这个点能答出来说明你关注过版本演进。工作节点升级的策略通常是先驱逐再升级再恢复。驱逐的时候要注意 PodDisruptionBudget它定义了自愿中断时最少要保持多少个副本可用。如果没有配置 PDB驱逐可能导致服务短暂不可用。这个细节在面试中说出来很加分。8. 我在面试和带人过程中积累的几个判断聊了这么多题目和答法最后说几个我自己的体会。面试 Kubernetes 相关岗位时最能拉开差距的不是你知道多少命令而是你能不能把“为什么”讲清楚。同样是回答“Pod 一直 Pending 怎么办”有人只能说出 kubectl describe有人能按资源、选择器、污点、亲和性逐层排查后者显然更让人放心。还有一个观察是很多人对“默认行为”不够敏感。Kubernetes 里大量的行为是有默认值的比如 NetworkPolicy 的默认允许、Secret 的默认不加密、滚动更新的默认参数。面试中能主动说出这些默认值以及什么时候需要改比背一堆高级特性更能体现功底。带新人的时候我经常让他们做一件事把一个 Pod 从创建到运行的全链路讲一遍中间每个组件做了什么、可能在哪里失败。能讲通这条链路的人排查问题时就不会慌因为他知道每一步的输入输出是什么。这个练习对准备面试同样有效比刷题有用得多。如果你正在准备 Kubernetes 面试我的建议是别急着背答案先把你用过的东西按“是什么、为什么、出问题怎么查”三个维度过一遍。真正理解的东西面试时自然能讲出来而且讲得比背的更有细节。