深入理解Kubernetes调度、控制器与探针：从原理到面试实战

做了这么多年后端，我越来越发现一个现象：简历上写着“熟悉 Kubernetes”的人一抓一大把，但真能坐下来把这套系统讲明白的没几个。Kubernetes 从入门到进阶，中间隔着的不是你会写几个 YAML、背下几个 API，而是有没有真正理解它的设计逻辑和运行机制。这不是靠刷几道题就能补上的，但你如果能把问题背后的原理吃透，面试时讲出来的东西和背答案完全是两个质感。这篇文章就把我在实际交付环境中反复踩过、也反复被问到的高阶知识点拆开聊一聊，尽量用大白话把“为什么”讲清楚。

这篇文章适合两类人：一类是准备面试、想系统梳理 Kubernetes 知识框架的人，另一类是已经在用 K8s 但总觉得“能跑就行、出了问题抓瞎”的开发者。核心内容围绕调度原理、控制器模型、探针与生命周期、资源 QoS、集群高可用，以及十几道高频实战面试题展开，每一步都会有对应的原因分析和可落地的建议，不是把官方文档搬过来复述一遍。

1. 先建立全局观：Kubernetes 到底在解决什么问题

1.1 从“会部署”到“会编排”的思维转变

很多初学者最容易犯的错，是把 Kubernetes 当成一个“高级的 docker-compose”。这也没错，你确实可以用它来跑容器，但如果只停留在这一层，后面的高级特性、面试题、生产事故，你一个都招架不住。

Kubernetes 的本质是一套声明式的、自愈的分布式系统编排框架。声明式是什么意思？就是你告诉它“我要什么状态”而不是“你要做什么步骤”。比如你写好一个 Deployment，声明“我要 3 个副本”，K8s 的控制器就会一直往这个目标状态靠拢，哪怕中途节点挂了、Pod 被杀了，它也会自动重建补足。这种模式带来的好处是巨大的：你的运维逻辑从“命令行操作步骤”变成了“对最终状态的描述”，机器负责保证状态，人只负责定目标。

这个思路一旦建立，后面所有高级特性都有一个统一的解释角度——它们都是为了更好地表达“目标状态”和“约束边界”。比如 HPA 是“在负载变化时自动调整目标副本数”，PodDisruptionBudget 是“在主动驱逐时给目标状态加一个最低可用约束”，NetworkPolicy 是“给服务间通信加状态约束”。你在面试时如果能顺着这个主线去答，面试官会明显感觉到你不是在背题。

1.2 控制器的“协调循环”为什么是设计核心

Kubernetes 里几乎所有组件都在围绕同一个模式运转：控制循环（Control Loop）。它的运行逻辑可以用一句话概括——“观察当前状态，对比期望状态，执行差值动作，然后再观察”。这个循环永远在跑，只是不同控制器关注的资源不同。

打个比方，这就像一个餐厅后厨的精细化管理。你（用户）写下菜单：“晚上 8 点，20 桌客人，每桌要有 4 个菜”。后厨主管（控制器）每隔几分钟就去数一下现有的食材和正在做的菜，发现哪一桌还差一个菜，就立刻安排厨师去做。客人走了、食材变了，主管的机制不变——只看“目标”和“现状”的差距，补差。你不用每道菜都去催一遍。

理解了这一点，再去看 Deployment 的 rollout、StatefulSet 的 Pod 顺序启停、DaemonSet 的每个节点各来一个，你就会发现它们只是在“协调循环”的基础上加了不同策略。这也是面试中特别爱问的“Deployment、StatefulSet、DaemonSet 有什么区别”的真正考察点——表面上是资源对比，本质上是对状态管理策略的理解。明白了这个核心模型，你才不会在高级面试题面前被绕晕。

2. 高级特性拆解：调度、探针、QoS 与控制器

2.1 调度器到底是怎么选节点的

Pod 创建之后要落到哪个节点，不是随机碰运气，而是由 kube-scheduler 走完一整套“预选 + 优选”流程决定的。

预选阶段（Predicates）先做硬性过滤：节点资源够不够、端口有没有冲突、节点是否有 taint、Pod 是否满足 nodeSelector 和节点亲和性。这一阶段的结果是“这个节点能不能跑这个 Pod”。优选阶段（Priorities）再对通过预选的节点打分：资源余量是否充足、Pod 分散度好不好、节点上已有 Pod 的镜像大小是否影响拉取速度等等，最后选分数最高的那个节点调度。

这里有一个我实际生产环境里踩过的大坑：很多人遇到 Pod 一直 Pending，第一反应是“资源不够”。但资源不够只是其中一种可能，还有可能是节点亲和性不满足、PVC 无法挂到该节点所在可用区、节点有 tolerations 没配对的污点，甚至可能是调度器因为 nodeSelector 找不到任何节点而直接放弃。

排障的正确姿势不是瞎猜，而是 kubectl describe pod <name> 去看 Events 列表里的调度失败原因。常见提示分为三类：0/N nodes available（所有节点都被过滤）、Insufficient memory/cpu（资源不足）、node(s) had taint that the pod didn't tolerate（污点不匹配）。这三类原因的处理思路完全不同——资源不足就扩容或调小 request；taint 不匹配就加 toleration；如果是节点亲和性问题，你就得回头检查 Pod 的 nodeSelector 是不是写错了。

2.2 探针的细节：readiness、liveness、startup 怎么配才不翻车

探针（Probe）是面试题里的常客，也是生产事故的多发地。三个探针搞清楚之后，部署策略才算真正入门。

livenessProbe 决定“这个容器要不要重启”，readinessProbe 决定“这个 Pod 要不要进 Service 的 Endpoints 列表接收流量”，startupProbe 是给启动特别慢的应用准备的“缓冲期”。很多人只配了 liveness 没配 readiness，结果应用还在加载配置就被杀了；还有人启动要 40 秒，liveness 的 failureThreshold×periodSeconds 才 30 秒，直接启动失败。

为什么三者的配合这么重要？核心是“滚动更新时的流量切换”问题。如果只有 liveness 没有 readiness，新副本起来后，kube-proxy 会立刻把流量打过去，但此时应用可能还没完成初始化，就出现一段灰度窗口的 502/504。所以常用策略是：启动慢的服务配一个宽松的 startupProbe（比如 initialDelaySeconds 30，periodSeconds 5，failureThreshold 10），让 K8s 等它完成启动；启动完成后由 readinessProbe 接管“是否对外提供服务”的判断，livenessProbe 则只在极端情况下兜底重启。

注意一个容易忽略的细节：探针的探测是 kubelet 直接对 Pod IP 发 HTTP/gRPC/Exec 请求的，不走 Service，所以你在容器里必须保证探测端口是真正监听且可访问的。我见过有人把 probe 配在 8080，但应用只监听了 8443，结果 pod 一直 Ready 不起来，排查半天才发现是端口写错了。

2.3 QoS 等级：Guaranteed、Burstable、BestEffort 的驱逐顺序

资源请求和限制的写法直接决定 Pod 的 QoS 等级，而 QoS 等级又决定了节点资源紧张时谁先被驱逐。这个链条是面试里最容易被挖细节的考点。

简单说，Pod 里每个容器都设置了完全相同的 requests 和 limits（cpu 和 memory 都相等），这个 Pod 就是 Guaranteed，表示“我承诺用这么多，谁也不许抢”；只要有一个容器 requests 和 limits 不一致，整个 Pod 就是 Burstable，表示“我能接受被压缩或争夺”；如果任何容器都没写 requests/limits，那就是 BestEffort，表示“我无所谓，随便挤”。

当节点内存不足时，kubelet 的驱逐顺序是：先杀 BestEffort，再杀 Burstable（且 usage 超过 requests 的），最后才动 Guaranteed。这个顺序背后的逻辑是“谁的承诺少，谁的牺牲大”——你没对系统做资源承诺，就别怪系统先拿你开刀。

所以你在生产里配资源，别把 requests 和 limits 都省掉，图一时省事后面会吃大亏。我建议核心业务至少做到 Guaranteed，最稳妥的方案是给每个容器都写上等值的 requests/limits。话虽如此，limits 也不建议拍脑袋给，特别是 CPU limit 设置过小会直接 throttle，应用表现为超时、卡顿但没有 OOMKilled，这种问题排查起来非常隐蔽。

2.4 控制器模型的实际差异：别什么都用 Deployment

Deployment、StatefulSet、DaemonSet 这三个控制器，选错是很多业务事故的根源。

Deployment 适合无状态应用，所有副本等价，可以随意重建、横向扩容。StatefulSet 适合有状态应用，它保证每个 Pod 有稳定的网络标识（DNS名）、稳定的持久化存储，以及严格的启停顺序。DaemonSet 则保证集群中每个节点运行一个 Pod，常用于日志采集、监控 agent、网络插件这类节点级组件。

注意，这里说的是“稳定标识”和“顺序”，不是“数据不丢”。很多人误以为用了 StatefulSet 数据就安全了，其实不然——StatefulSet 只是把存储和 Pod 的生命周期绑定了，真正保证数据持久化的是 PV/PVC 底层对应的存储类型（比如云盘、Ceph RBD 等）。面试时如果被问到“StatefulSet 为什么不能随便删”，你要能答出“因为它的 DNS 和存储结构都假设 Pod 有身份”，而不是一句“因为做了持久化”。

还有一个实用建议：能不用 StatefulSet 就不用。有状态服务能用中间件方案（比如数据库走云厂商托管、消息队列走独立集群）就尽量托管，K8s 里跑自己运维的 StatefulSet 是运维成本最高的玩法，没有之一。

3. 实战现场：初始化集群、预检失败与升级策略

3.1 一次 kubeadm init 预检失败的真实排查

用 kubeadm 初始化集群时，官方工具会在正式部署之前跑一遍 preflight checks，确保当前节点满足集群启动条件。热词里那次 [init] using kubernetes version: v1.26.0 [preflight] running pre-flight checks 的输出，很多人在这一步就卡住了。预检到底在检查什么？总结下来主要看这四类：容器运行时是否可用、端口是否被占用、内核模块与系统参数是否满足、kubelet 是否处于 healthy 状态。

我遇到过最常见的预检失败原因是 [ERROR FileContent--proc-sys-net-bridge-bridge-nf-call-iptables]: /proc/sys/net/bridge/bridge-nf-call-iptables contents are not set to 1。这个报错的意思是系统没有开启桥接流量经 iptables 处理，K8s 的 Service 转发依赖这个内核参数。修复方法很固定：

bash复制modprobe br_netfilter
sysctl -w net.bridge.bridge-nf-call-iptables=1
sysctl -w net.ipv4.ip_forward=1

然后写入 /etc/sysctl.d/k8s.conf 保证重启后依然生效。这里要注意，不只是要写入文件，还要 sysctl --system 立刻生效一次，否则你会遇到“文件改好了但当前进程还是老参数”的问题。

另一种高频预检失败是容器运行时版本不对或者没有启用。如果用的是 containerd，需要确认 crictl version 能正常输出，同时 systemctl status containerd 是 running 状态。kubeadm 会直接检查 /var/run/containerd/containerd.sock 这个 socket 是否存在，如果你的 containerd 没有用 systemd cgroup driver 或者 socket 路径不对，预检也会卡住。

3.2 kubeadm 版本升级的路径与坑

集群上线之后不可能永远不升级，K8s 官方支持的是次版本号逐级升级，比如 1.25 升 1.26、再升 1.27，不能从 1.24 直接跳 1.26。这个限制不是 kubeadm 故意为难你，而是因为每个版本的 API 都可能发生废弃和变更，一次跨太多版本会连兼容性都找不着北。

升级流程按控制面、节点网依次执行：先升级 kubeadm、kubelet、kubectl 二进制，再 kubeadm upgrade plan 查看版本和升级路径，然后 kubeadm upgrade apply v1.26.0 更新控制面组件，最后逐台节点 kubeadm upgrade node 完成节点升级。有一个容易忽略的点：kubeadm upgrade apply 之前一定要 kubectl drain 控制面节点的负载，等升级完成再 uncordon，否则升级期间调度任务可能被分配到正在重启的节点上。

我自己的习惯是升级前做三件事：备份 etcd 快照、导出当前集群全部资源清单、记录当前组件镜像版本。etcd 快照尤其关键——它备份的是整个集群状态，包括所有资源对象。升级失败想回滚，没有快照你只能从每个应用的镜像版本重新推。用 etcdctl snapshot save 做快照很简单，但真正麻烦的是“定期做”，我见过太多团队只在出事之后才想起来备份，那已经晚了。

3.3 网络插件选型：从 Flannel 到 Calico 的切换经验

网络插件是最容易被“能跑就行”带过的组件，但它决定了 Pod 间通信、NetworkPolicy、甚至跨节点流量的表现。Flannel 配置简单、上手快，适合开发环境；Calico 支持 BGP 路由和 NetworkPolicy，适合生产环境需要网络策略控制的场景；Cilium 则基于 eBPF，性能更好，但引入的技术栈更重，团队要有相应能力。

我在生产里换过一次网络插件，那次经历让我深刻意识到一件事：换网络插件不是 kubectl delete -f flannel.yaml 再加 kubectl apply -f calico.yaml 这么简单。Flannel 会在节点上创建 cni0 网桥、设置路由表规则，删掉插件后这些残留规则不会自动清理，新的插件装上去会冲突。正确步骤是：先清理 flannel 的 CNI 配置文件和节点上的路由，再删 flannel DaemonSet，最后安装 Calico，装完还要重启 kubelet 让它重新生成 CNI 配置。整个过程建议在维护窗口内做，因为切换期间集群内的 Pod 网络会中断。

3.4 资源请求与限额的落地配置参考

给一个真实可参考的资源配置模板，如果你不想踩“资源争抢导致线上抖动”的坑，可以按这个思路起步：

yaml复制resources:
  requests:
    cpu: 500m
    memory: 512Mi
  limits:
    cpu: "1"
    memory: 1Gi

cpu 的 500m 表示“预留 0.5 核”，limit 的 1 表示“最多用 1 核”。这个配置对大多数 Web 服务是够用的。但要提醒一下：Requests 是调度时的依据，决定了节点能放多少个 Pod；Limits 是运行时的上限，CPU 超限会被 throttle，内存超限会被 OOMKill。两者的语义不同，千万别搞混。

另外，单个节点的 Pod 数量不是越多越好，kubelet 默认限制每节点 110 个 Pod，但这只是一个软上限。实际部署时要结合节点规格、Pod 平均资源占用、容器运行时并发能力来评估。在节点上跑满 100 个 Pod 的场景，我这里还没有遇到过不抖的。

4. 高频面试题还原：从答法到背后的原理

4.1 面试官问“Pod 一直 Pending 怎么排查”，你想答什么

这是实战性最强的送分题，但很多人答得太浅。合理作答思路应该是这样的：

先确认事件，kubectl describe pod <name> 看调度相关信息。然后根据 Events 分层排查：调度器有没有找到可用节点？节点资源是否满足 requests？是否被 taint 挡住？是否被 affinity 规则排除？PVC 是否能正常挂载？最后再检查 kube-scheduler 和 kube-controller-manager 是否正常运行。

能按这个顺序答的人，面试官就会认为你真正调度过 Pod。如果你上来就说“节点资源不足”，我只能说这道题你只拿到了 30% 分。实际生产中有一种特别容易漏的场景：PVC 指定的 storageClass 并不存在于集群中，导致 PVC 一直是 Pending，Pod 自然也无法调度。这种问题看 Events 只会看到“0/N nodes available: pod has unbound immediate PersistentVolumeClaims”，很容易被误判成节点问题，其实是存储类配置错误。

4.2 “为什么 Pod 重建后 IP 会变”如何优雅回答

这个问题看似基础，实际上是把 Service、EndpointSlice、DNS、控制器串起来的好题。作答的思路可以这样展开：Pod 是无状态资源，它被删除重建后，新 Pod 会由控制器重新创建，所以 IP 是新的。但是因为 Service 通过 label selector 关联 Pod，当 Pod IP 变化时，EndpointSlice 控制器会马上感知并更新后端列表。所以虽然 Pod IP 变化了，但 Service 的 ClusterIP 和 DNS 名不变，对客户端来说“服务入口”始终是稳定的。

关键是你能说出“为什么这不影响业务”。因为客户端访问的是 Service，而不是直接访问 Pod IP；Pod IP 变化由 EndpointSlice 自动同步，只要保证 Pod 的 labels 不变，Service 就能持续找到新副本。这个机制配合前面说的 readinessProbe，就形成了 K8s 里一套完整的流量接入体系。

4.3 谈谈“etcd 为什么需要奇数节点”

etcd 是 K8s 的存储底座，面试问 etcd 高可用是高频操作。等奇数节点是为了选主时能形成多数派，防止脑裂。3 节点容忍 1 台故障，5 节点容忍 2 台故障。这里要答出递进逻辑：为什么不是偶数？因为偶数节点在网络分区时可能出现平票，无法选出唯一 leader，集群就不可用了。

实际生产中 etcd 还有几个隐藏的重点：Raft 日志同步性能取决于磁盘 fsync 延迟，所以 etcd 要用 SSD；etcd 节点之间网络延迟要低，最好是同机房部署；etcd 的 --quota-backend-bytes 默认 2GB，如果你的集群资源对象特别多（比如一个大集群几千个 namespace），一定要提前调大并定期做 defrag，否则 etcd 会报 mvcc: database space exceeded，整个集群进入只读模式。这个报错我见过不止一次，每一回都是血泪教训。

4.4 资源、亲和性、污点：三件套组合题

面试官常常把 nodeSelector、nodeAffinity、taint/toleration 放在一起问，考察你对“调度约束”的理解。它们的区别可以用一句话概括：nodeSelector 和 nodeAffinity 是 Pod 对节点的“偏好”，是主动选择；taint/toleration 是节点对 Pod 的“排斥”，是反向隔离。

再往深一层说，nodeAffinity 又分 requiredDuringSchedulingIgnoredDuringExecution 和 preferredDuringSchedulingIgnoredDuringExecution，前面的词代表硬性条件，后面的词代表软性偏好。注意那个 IgnoredDuringExecution——意思是“即使节点后续标签变了，已经运行在节点上的 Pod 不会被驱逐”，只有新调度时才会重新校验。所以你在面试里可以通过指出“in/notIn/exists/doesNotExist 五种操作符”来加分，说明你不只是背过这个资源名字，是真的用它编排过。

合理的使用方式是：nodeSelector 负责简单的环境隔离（比如区分 GPU 节点和通用节点），nodeAffinity 负责复杂的组合偏好（比如优先调度到同一可用区减少跨区流量费用），taint/toleration 负责限制哪些工作负载能跑到专用节点上（比如给 GPU 节点打 taint，只有声明了对应 toleration 的 AI 训练任务才能上去）。

4.5 控制器循环、Pod 生命周期和优雅退出

面试官问 kubectl delete pod 之后发生了什么，其实想听你完整讲一遍 Pod 优雅终止流程。标准流程是：API Server 将 Pod 标记为 Terminating，EndpointSlice 立刻移除该 Pod 的后端，kubelet 执行 preStop 钩子（如果有），然后发送 SIGTERM 给容器的主进程，等待 grace period（默认 30 秒），超时后发 SIGKILL 强制杀死。

这个流程里有两个常见翻车点：一是 postStart/preStop 钩子写死 30 秒 sleep，导致每次 Pod 删除都很慢；二是应用不处理 SIGTERM，直接终止连接，导致流量还没切走就断连。在滚动更新时，如果旧 Pod 不等现有连接处理完就退出，用户就可能在更新窗口内遇到大量 5xx。

我的经验是在 preStop 里加一个短暂 sleep（比如 5 秒），同时保证应用正确监听 SIGTERM 并做优雅退出，比如 Spring Boot 的 server.shutdown=graceful。这里有个细节要知道：如果应用自己会在 SIGTERM 后快速退出，preStop 里再 sleep 纯属浪费时间；如果应用不处理 SIGTERM，preStop 里的 sleep 反而能帮你留出流量摘除的时间。这两种场景怎么取舍，得结合应用本身的行为来判断。

4.6 面试题速查表

这张表适合考前快速过一遍，但每道题都要能展开讲原理，别只记住关键词。尤其是“滚动更新策略”里 maxSurge 和 maxUnavailable 的默认值，很多人知道是 25% 和 25%，但被追问“为什么 maxUnavailable 设为 0 会造成滚动更新卡住”就答不上来了。原因很简单：如果设为 0，K8s 不会先杀旧 Pod，它必须先等新 Pod 起来并且 Ready，才能替换旧 Pod；如果集群资源本身不足，新 Pod 一直 Pending，更新就一直卡着不动，整个发布看起来像死了一样。

4.7 水平扩缩容和自愈：面试里的“场景加分项”

高级一点的面试题会扔给你一个场景：“线上服务突然流量翻倍，你怎么处理？”这时候别说“手动加副本”，要顺着这条思路走：

先看 HPA 配置有没有覆盖目标业务，如果没配，就是用 kubectl scale deployment xxx --replicas=N 快速扩容；配了的话，要看 HPA 的 metrics 是否采集正常、阈值是否合理。然后检查 limit 是否会造成容器 CPU throttle，必要时临时调高 limits 并滚动更新。最后观察扩容后的 Pod 分布是否均匀，如果都挤到同一个节点，要考虑加 PodTopologySpreadConstraints。

这里面有一个容易踩的坑：HPA 的默认指标是 CPU 使用率，但很多长连接类服务 CPU 负载并不高，流量却已经打满。对于这种场景，需要配自定义指标（比如 QPS、连接数）或者外部指标，让 HPA 能“感知到”真正的业务压力。所以面试时能主动提到“根据业务类型选指标”，已经超过了绝大多数背题选手。

再补一句自愈机制的理解：kubectl delete pod 后，控制器发现期望状态（比如 3 副本）和当前状态（2 副本）不一致，会新建一个 Pod 来补足。这不是“复活”原来的 Pod，而是“重建一个满足同样描述的新Pod”。所以你在 K8s 里想通过删除 Pod 来重启应用，是完全可行的——但你要是想通过删除 Pod 来让某个特定容器保留原 IP 或原数据，那就会失望了，有状态的东西全在 StatefulSet/持久卷体系里，不在“删除重建”这个逻辑里。

5. 资源请求与排查：从实际事故中总结的通用经验

5.1 一次 CPU Throttle 引发的“假死”事故复盘

我之前负责过一个 Java 服务，流量增长后用户反馈接口全面变慢，但 kubectl top pod 看 CPU 使用率并不高。看监控发现了一个诡异现象：容器 CPU 使用率在 400% 上下波动，但 limit 才 2 核。一番排查后发现，问题出在 CPU limit=2，但是容器有好几个内部线程，4 核 host 上跑，limit 把容器限制到只允许使用 2 核时间片，多余的计算全被 throttle 了。而且 Java 的线程池并不会因为 CPU 被 throttle 就自动调整行为，应用表现就是大量请求排队超时。

这个事故教会我两件事：第一，CPU limit 不是越大越好，也不是随便拍脑袋设的，你要结合应用的线程模型、JVM 配置和压测结果来定；第二，生产容器最好把 CPU limit 和 request 设为相等，这样 QoS 是 Guaranteed，同时被 throttle 时不会让调度器误以为节点资源还有余量。如果你实在需要 CPU 弹性，就只降低 request，但 limit 保持一个经过测试的上限。

5.2 OOMKilled 的排查：JVM 与容器的内存博弈

Java 应用在容器里最容易发生一种“薛定谔的 OOM”：容器内存显示占满被 OOMKilled，但 JVM 堆还有一半空间。原因在于 JVM 默认堆大小是宿主机内存的 1/4，而容器里看到的 /proc/meminfo 在某些配置下还是宿主机的值，JVM 就可能给自己划了一个超大堆，然后被 cgroup 限制“杀掉”。

现行做法是显式设置 JVM 的 -Xmx 和 -XX:MaxRAMPercentage，让 JVM 的堆和容器 memory limit 对齐。比如 memory limit 是 2Gi，就设 -Xmx1g -XX:MaxRAMPercentage=50。记住：容器启动参数的“默认优化”在早期 JVM 版本里并不存在，很多老应用吃过大亏，升级 JDK 或者显式加参数是必须做的。另外不要忽略堆外内存、线程栈、JIT 编译缓存这些 Non-Heap 部分，至少留出 limit 的 25% 作为余量，否则依然会出现容器 OOM 但监控里堆用量并不高的怪象。

5.3 节点磁盘压力与镜像堆积

K8s 集群跑久了，节点磁盘会悄悄逼近阈值，kubelet 有一个 evictionHard 机制，默认 imagefs.available<15% 时就会触发驱逐镜像和 Pod。这是个“隐性生产事故高发点”，因为节点一般不会真的等到磁盘爆掉才出问题，而是先开始驱逐，慌慌张张的 Pod 重建让整个集群看起来像发疯了一样。

解决方法分两类：一是 imagePullPolicy: IfNotPresent 减少重复镜像拉取，并定期清理 docker image prune / crictl rmi --prune；二是监控节点磁盘使用率，告警阈值设在 70%。分区间写日志时，把宿主机 /var/log 和容器日志目录做持久化挂载或者定时任务清理，别让日志文件撑爆系统盘。说句实在话，K8s 生产事故十有七八不是 K8s 自身的问题，而是基础资源（磁盘、内存、网络）到了临界点又被忽视，K8s 只是最后“背锅”的那个。

5.4 NetworkPolicy 误配置导致的服务断连排查

NetworkPolicy 是很多团队容易“配了就忘”的组件，但它一旦配错，影响面是全体 Pod 通信。有一回我们在测试环境加了“只允许同 namespace 内通信”的策略，紧接着监控就发现跨 namespace 的调用全部超时。排障时第一反应不是怀疑网络策略，而是先看了半天 DNS、Service，最后才去翻 NetworkPolicy。

这次之后我总结了教训：NetworkPolicy 的坑主要在“默认拒绝”和“只控制 Ingress/Egress 方向”。如果一条策略写了 podSelector: {}，它其实只在当前 namespace 生效，不会影响其他 namespace——除非你再用 namespaceSelector 组合。排查时先 kubectl get networkpolicy -A 列出所有策略，再逐条对照 podSelector 和 namespaceSelector 的范围，测试时先用临时 Pod 手动 curl 一下服务 IP，能快速区分是 DNS、网络还是策略的问题。这种“先怀疑策略”的顺序，能省掉大量排查时间。

6. 面试之外的工程化建议

聊完面试题，最后分享一点我在工程实践中的体会。Kubernetes 的学习曲线陡峭，但真正让它显得“难”的不是命令和 YAML，而是你要同时建立分布式系统的全局观：调度、自愈、网络、存储、安全、可观测性，每一条线都有一套完整逻辑。

如果你正在面试准备期，我的建议不是去背 300 道题，而是找一套测试环境，手动完成这些实验：用 kubeadm 装一个高可用集群、给某个部署配好三种探针并观察滚动更新、模拟一个节点 NotReady、把 etcd 备份和恢复跑一遍、在一个 namespace 里配 NetworkPolicy 并且验证跨 namespace 断连。这些操作做一遍顶十遍书。面试官问到你的时候，你能随口说出“这个我测过，会遇到 XXX 问题”，这种经验感是背题背不出来的。

如果你已经上线了生产集群，我建议你优先补上这四件事：etcd 的定期备份和恢复演练、核心应用的资源 requests/limits 审计（该给 Guaranteed 的都给到）、滚动更新时的 PDB 配置（防止节点维护时批量驱逐导致服务不可用）、以及全链路监控（容器 CPU/MEM、节点磁盘、etcd fsync、API Server 延迟）。这四件事不复杂，但它们决定了你的集群是“能跑”还是“稳定可维护”。

最后再分享一个藏得比较深的小技巧：K8s 排障时，先看事件（Events），再看监控（Metrics），最后看日志（Logs）。很多人一上来就翻应用日志，绕了一大圈才发现是调度或网络层的问题。事件里藏着大部分问题的线索，kubectl get events --sort-by=.lastTimestamp 这个命令在关键时候比什么都好用。就冲这一点，也不枉你把这篇文章看到最后。