1. 从“能跑起来”到“跑得明白”：Pod下半场到底在聊什么
很多人学 Kubernetes 的路径都差不多：先把集群拉起来，跑个 Nginx Deployment，看到 Pod 变成 Running，心里就踏实了。但真正进到生产环境里，你会发现“Running”这三个字几乎什么都说明不了。Pod 是 Running，可流量进不来；Pod 是 Running，可重启次数一直在涨；Pod 是 Running，可日志里全是连接超时的报错。上半篇我们聊了 Pod 的基本结构、生命周期阶段、容器组织方式这些“骨架”层面的东西，下半篇要解决的恰恰是骨架之外的那些问题——Pod 到底怎么被调度、怎么被探活、怎么被分配资源、怎么被优雅地终止，以及出问题时你该从哪个方向去查。
这篇内容适合两类人看：一类是已经把 Pod 跑起来、但一遇到 CrashLoopBackOff 或者 Pending 就不知道从哪下手的朋友；另一类是想把 Pod 配置从“抄模板”升级到“知道每个字段为什么这么写”的从业者。我会围绕Pod 调度约束、健康探针、资源请求与限制、生命周期钩子、多容器协作这几条主线展开，每个点都尽量落到“为什么这么设计”和“实际踩过什么坑”上。关键词方面，调度亲和性、污点与容忍、liveness/readiness/startup 探针、requests 与 limits、preStop 钩子、Init 容器、边车容器这些概念会反复出现，因为它们构成了 Pod 从创建到退出的完整闭环。
先说一个我自己的观察：大部分 Pod 相关的线上事故，根因都不在镜像本身，而在“配置和实际负载不匹配”。资源给少了被 OOMKill，探针配错了被反复重启，调度约束写死了导致扩不出来，终止时间不够导致请求被硬切。这些问题单看文档都能看懂，但组合在一起就很容易互相掩盖。所以下面我不按 API 字段顺序讲，而是按“一个 Pod 从被创建到被销毁会经历哪些关键决策点”来组织，这样你排查问题时能顺着链路走。
2. 调度不是随机分配：Pod 落到哪台节点是有逻辑的
2.1 调度器眼中的 Pod：一次过滤加打分的决策
Pod 创建出来之后，第一件事是找到一台合适的节点。这个过程由 kube-scheduler 负责，它做的事情可以粗暴地分成两个阶段：过滤（Filtering）和打分（Scoring）。过滤阶段把所有不满足硬性条件的节点剔除，打分阶段在剩下的节点里按优先级排序，选最高分的那个。理解这个两段式结构非常关键，因为你在配置里写的不同字段，作用在这两个不同阶段。
硬性条件包括节点资源是否够、节点选择器是否匹配、污点是否容忍、亲和性硬规则是否满足等。这些条件只要有一条不满足，节点就直接出局，Pod 会一直 Pending。软性条件则是“尽量满足”，比如节点亲和性的 preferred 规则、Pod 间亲和性的软约束，它们只影响打分不影响过滤。很多人配了软亲和性发现 Pod 还是 Pending，就是因为把硬约束和软约束搞混了。
我见过一个很典型的场景：某团队给 Pod 配了nodeSelector指定某个机房标签，同时又配了节点亲和性要求另一个标签，两个条件在部分节点上不重叠，结果扩容时新 Pod 全部 Pending。排查时kubectl describe pod的事件里会明确写“0/6 nodes are available”，后面跟着几条原因，比如“3 node(s) didn't match Pod's node affinity/selector”。这条信息就是过滤阶段被剔除的统计，顺着它查基本不会跑偏。
2.2 nodeSelector、节点亲和性、污点容忍三者的分工
这三个东西经常被混用，但它们的定位其实很清楚。nodeSelector是最简单的硬匹配，只支持等值标签，写起来直观但表达能力有限。节点亲和性（nodeAffinity）支持更丰富的操作符，比如 In、NotIn、Exists、Gt、Lt，还能区分 requiredDuringSchedulingIgnoredDuringExecution（硬）和 preferredDuringSchedulingIgnoredDuringExecution（软）。污点与容忍（Taints/Tolerations）则是从节点侧反向排斥 Pod，节点打上污点，只有声明了对应容忍的 Pod 才能上去。
分工上我的经验是：节点池的“专属属性”用污点来表达，比如 GPU 节点打上nvidia.com/gpu=true:NoSchedule，只有真正需要 GPU 的 Pod 才配容忍；Pod 对节点的“偏好”用亲和性表达，比如尽量调度到同可用区的节点以减少跨区延迟；简单的固定绑定用 nodeSelector 就够了，没必要上亲和性。三者可以叠加，但叠加时一定要在测试环境验证过滤结果，因为多个硬条件取交集，很容易把可选节点集合压到零。
还有一个容易忽略的点：污点的 effect 有三种，NoSchedule 只是不打新 Pod 上去，已经在上面的 Pod 不受影响；NoExecute 会把不 tolerating 的 Pod 直接驱逐；PreferNoSchedule 是软性的尽量不调度。生产环境做节点维护时，经常用 NoExecute 配合容忍时间（tolerationSeconds）来实现“给 Pod 留出迁移窗口”，这个后面讲终止流程时还会提到。
2.3 Pod 间亲和与反亲和：把“住得近”和“住得远”变成规则
节点维度的调度解决的是“Pod 和机器”的关系，Pod 间亲和性（podAffinity）和反亲和性（podAntiAffinity）解决的是“Pod 和 Pod”的关系。典型用法有两个：一是把同一服务的多个副本打散到不同节点，避免单节点故障导致整体不可用，这用反亲和性配 topologyKey 为kubernetes.io/hostname；二是把有调用关系的服务尽量放在同一拓扑域，减少网络跳数，这用亲和性配 topologyKey 为可用区标签。
这里有个性能上的坑必须提：Pod 间亲和性在大规模集群里是有调度开销的，因为它需要检查拓扑域内已有 Pod 的标签，集群 Pod 数量上万时，调度延迟会明显上升。所以反亲和性的粒度要控制好，别动不动就配 required 级别的反亲和，软反亲和（preferred）在多数场景下已经够用。另外 topologyKey 的选择直接决定“打散”的粒度，选 hostname 是节点级打散，选 zone 是可用区级打散，选错了要么打散不够要么过度打散导致资源碎片。
我实际做过一个对比：同一个服务 6 个副本，配 required 反亲和加 hostname 拓扑，在 6 节点集群里刚好一节点一个，但只要有一个节点资源不足，第 6 个副本就 Pending；换成 preferred 之后，极端情况下允许两个副本同节点，可用性略降但扩容弹性好了很多。这个取舍没有标准答案，取决于你的服务对单点故障的容忍度。
3. 探针配错比不配更危险：三种探针的边界与实测
3.1 liveness、readiness、startup 各自管什么
探针是 Pod 健康管理里最容易配错的部分，因为三种探针名字相近但职责完全不同。livenessProbe回答的是“这个容器还活着吗”，失败达到阈值就重启容器；readinessProbe回答的是“这个容器能接流量吗”，失败只是把 Pod 从 Service 的 Endpoints 里摘掉，不重启；startupProbe回答的是“这个容器启动完成了吗”，在它成功之前，liveness 和 readiness 都不会执行。
这个执行顺序非常关键。很多 Java 或者大型 Node 服务启动要一两分钟，如果只配了 liveness 且 initialDelaySeconds 给得不够，容器还没启动完就被判定为死，然后被杀掉重启，陷入无限循环。正确做法是配 startupProbe，把 failureThreshold 乘以 periodSeconds 设成略大于最坏启动时间，启动成功后 liveness 才接管。我一般给 startupProbe 留的余量是实测启动时间的 1.5 到 2 倍，宁可多等一会儿也别误杀。
readiness 的价值在于“优雅上下线”。服务刚启动、依赖还没连上时，readiness 失败让流量先别进来；服务准备下线时，先把 readiness 置为失败，等 Endpoints 摘除完成再真正退出。这里有个细节：readiness 失败到 Endpoints 真正摘除之间是有延迟的，kube-proxy 的规则更新不是瞬时的，所以光靠 readiness 还不够，后面讲 preStop 时会补上这一环。
3.2 探针类型怎么选：exec、httpGet、tcpSocket 的适用场景
探针支持三种检查方式。httpGet最适合 HTTP 服务，发一个 GET 请求看返回码是否在 200 到 399 之间，配置简单且能反映应用层真实状态。tcpSocket只检查端口能不能连上，适合非 HTTP 的 TCP 服务，比如数据库、消息队列，但它只能证明“端口在监听”，证明不了“业务可用”。exec是在容器里执行命令看退出码，最灵活但也最重，每次检查都要 fork 一个进程，高频检查时对容器资源有额外消耗。
我的选型习惯是：能上 httpGet 就上 httpGet，专门暴露一个轻量的健康检查端点，里面只做必要的依赖检查，别把一堆重查询塞进去；tcpSocket 用于那些没有 HTTP 接口的基础组件；exec 只在确实没有其他办法时用，比如检查某个本地文件是否存在、某个内部状态文件是否更新。有个反例值得警惕：有人用 exec 执行cat /tmp/healthy做 liveness，结果容器里临时文件被清理逻辑删了，探针失败触发重启，重启后文件又生成，循环往复，日志里看不出任何应用错误，查了很久才发现是探针命令本身的问题。
3.3 阈值参数的调优：别让默认值坑了你
探针有几个关键参数：initialDelaySeconds、periodSeconds、timeoutSeconds、successThreshold、failureThreshold。默认值分别是 0、10、1、1、3。看起来挺合理，但放到具体场景里经常不够用。timeoutSeconds 默认 1 秒，对于响应偶尔抖动的服务来说太紧，一次 GC 停顿就可能超时；failureThreshold 默认 3 次，配合 10 秒周期就是 30 秒才判定失败，对于需要快速摘流量的场景又太慢。
我一般的调法是这样的：liveness 的 periodSeconds 给 10 到 20 秒，failureThreshold 给 3，timeoutSeconds 给 3 到 5 秒，这样最坏情况下 30 到 60 秒判定死亡，不会因为偶发抖动误杀；readiness 的 periodSeconds 给 5 到 10 秒，failureThreshold 给 2 到 3，让它能相对快地反映状态变化；startupProbe 的 failureThreshold 根据启动时间算，periodSeconds 给 5 到 10 秒。这些数字不是死的，核心原则是：liveness 要“迟钝”一点避免误杀，readiness 要“敏感”一点快速摘流。
还有一个隐藏坑：liveness 探针检查的逻辑如果依赖外部服务（比如数据库），外部服务一抖动，所有 Pod 的 liveness 同时失败，然后集体重启，重启期间服务完全不可用，反而放大了故障。所以 liveness 的检查逻辑应该尽量只反映“进程自身是否卡死”，外部依赖的健康交给 readiness 去表达。
4. 资源请求与限制：OOMKilled 和 Pending 的共同源头
4.1 requests 决定调度，limits 决定生死
Pod 的资源管理里，requests和limits是两个完全不同的东西，但新手经常只写一个或者写成一样。requests 是调度器用来判断节点有没有足够资源的依据，它代表“我至少需要这么多”；limits 是容器运行时用来做上限控制的，超过 CPU limit 会被限流（throttle），超过内存 limit 会被 OOMKill。节点上所有 Pod 的 requests 之和不能超过节点可分配资源，但实际使用可以超过 requests 直到 limits。
这个机制导致两个经典问题。第一，requests 设得太小，调度器觉得节点还有空间，拼命往上塞 Pod，实际运行时大家抢资源，互相拖慢；第二，limits 设得和 requests 一样，容器没有任何弹性空间，流量高峰时 CPU 被限流、内存稍微涨一点就被杀。我的经验是 CPU 的 requests 按日常负载的均值给，limits 给到峰值的 2 到 3 倍甚至不设上限（靠节点整体容量兜底）；内存的 requests 和 limits 可以设成一样，因为内存不像 CPU 可以压缩，超了就是 OOM，设成一样反而行为可预期。
内存这块要特别说一句：Java 服务的堆内存和容器 limit 之间要留出余量。JVM 除了堆还有元空间、线程栈、直接内存等开销，如果-Xmx设成等于容器 limit，容器很容易在堆还没满的时候就被 OOMKill。一般建议堆大小设为 limit 的 60% 到 75%，剩下的留给非堆内存和系统开销。这个比例不是拍脑袋，是多次看 OOM 现场之后总结出来的安全区间。
4.2 QoS 等级：你的 Pod 在资源紧张时排第几
Kubernetes 根据 requests 和 limits 的配置把 Pod 分成三个 QoS 等级：Guaranteed（所有容器都设了 requests 且等于 limits）、Burstable（至少一个容器设了 requests 但不满足 Guaranteed）、BestEffort（所有容器都没设 requests 和 limits）。节点资源紧张时，kubelet 按 BestEffort、Burstable、Guaranteed 的顺序驱逐，同等级内再按实际使用超出 requests 的程度排序。
这个等级直接影响你的服务在节点压力下的存活概率。核心服务我一般配成 Guaranteed，虽然牺牲了弹性但换来稳定性；普通业务配 Burstable，requests 给合理值，limits 留弹性；BestEffort 只用于那些完全可牺牲的批处理任务。有个细节：Guaranteed 要求 requests 和 limits 严格相等，包括 CPU 和内存都要设，少设一个就掉到 Burstable，很多人以为自己配了 Guaranteed 其实并没有。
4.3 从 Pending 和 OOMKilled 反推资源配置问题
排查资源问题有两个高频信号。Pod 一直 Pending，describe事件里出现 “Insufficient cpu” 或 “Insufficient memory”，说明集群里没有节点能满足 requests，要么加节点，要么降 requests，要么检查是不是有僵尸 Pod 占着资源没释放。Pod 反复重启且原因是 OOMKilled，describe里 Last State 显示 Reason: OOMKilled、Exit Code: 137，说明内存超了 limit，要么调大 limit，要么查内存泄漏。
这里有个容易误判的点：Exit Code 137 不一定是 OOM，也可能是收到了 SIGKILL，比如节点驱逐或者手动 kill。区分方法是看 describe 里的 Reason 字段，明确写 OOMKilled 才是内存超限。另外，容器内存使用接近 limit 时不一定立刻被杀，因为内核的 OOM 触发时机和 cgroup 统计口径有关，所以监控上要把内存使用率到 limit 的 80% 作为一个预警线，别等真被杀了才发现。
5. 生命周期钩子与优雅终止：请求不被硬切的关键几十秒
5.1 postStart 和 preStop 的执行时机与常见误用
Pod 的生命周期钩子有两个：postStart在容器创建后立即执行，preStop在容器被终止前执行。postStart 常被用来做初始化动作，比如预热缓存、注册到某个外部系统；preStop 常被用来做优雅关闭，比如通知上游摘流量、等待正在处理的请求完成。
但这两个钩子有几个反直觉的行为。postStart 是和容器主进程并行执行的，它不保证在主进程的 ENTRYPOINT 之前完成，所以如果你在 postStart 里做“必须完成后主进程才能启动”的事情，是不安全的，这类需求应该用 Init 容器。preStop 执行期间，容器主进程还在运行，钩子完成后才会发 SIGTERM，所以 preStop 里可以放心地做“通知 + 等待”的动作。还有一个硬限制：preStop 的执行时间受 terminationGracePeriodSeconds 约束，如果钩子执行超过这个时间，容器会被 SIGKILL 强杀，钩子里的等待逻辑就白做了。
我见过一个典型误用：有人在 preStop 里 sleep 30 秒，想等负载均衡摘流量，但 terminationGracePeriodSeconds 用的是默认 30 秒，结果 preStop 还没睡完就被杀了，等于没等。正确做法是把 grace period 设成 preStop 时间加上应用自身关闭时间，再留一点余量，比如 preStop 睡 10 秒、应用关闭最多 20 秒，grace period 给 40 秒。
5.2 一次完整的优雅终止链路拆解
Pod 被删除时，实际发生的事比大多数人想的复杂。第一步，API Server 把 Pod 标记为 Terminating，同时 kubelet 开始终止流程；第二步，如果配了 preStop，先执行钩子；第三步，钩子完成后给容器主进程发 SIGTERM；第四步，应用收到信号后开始优雅关闭，停止接受新请求、处理完存量请求、关闭连接池；第五步，如果超过 grace period 还没退出，SIGKILL 强杀。
与此同时，Endpoints 控制器会把 Pod 从 Service 的 Endpoints 里移除，但 kube-proxy 更新转发规则需要时间，这个时间窗口内新请求可能还会打到正在终止的 Pod 上。所以完整的优雅终止需要三方配合：preStop 里主动通知或者短暂等待，覆盖 Endpoints 传播的延迟；应用正确处理 SIGTERM；grace period 足够长。三者缺一，就会出现“发布时偶发 502”这种经典问题。
我的实践模板是这样的：preStop 里执行一个轻量脚本，先调用本地管理端口把健康状态置为不健康（让 readiness 失败加速摘除），然后 sleep 5 到 10 秒覆盖传播延迟；应用侧注册 SIGTERM 处理，收到信号后停止接受新连接、等待存量请求完成、关闭资源；grace period 设为 preStop 时间加应用最大关闭时间再加 10 秒余量。这套组合下来，滚动发布基本能做到零感知。
5.3 terminationGracePeriodSeconds 的取值逻辑
这个参数默认 30 秒，对很多服务来说不够。取值逻辑应该是：preStop 执行时间 + 应用优雅关闭最长时间 + 安全余量。应用优雅关闭最长时间怎么估？看你的服务处理单个请求的最长耗时，再乘以并发队列里可能积压的请求数，取一个合理的上界。比如一个接口 P99 是 2 秒，关闭时最多允许积压 10 个请求串行处理，那就是 20 秒，加上 preStop 10 秒和安全余量 10 秒，grace period 给 40 秒比较稳妥。
但也不能无限大。grace period 太长会导致节点维护、滚动发布变慢，而且如果应用卡死，要等很久才能被强杀。所以这个值要在“保证优雅”和“快速收敛”之间取平衡，一般 30 到 60 秒覆盖大多数 Web 服务，长连接或者批处理类服务另算。有个监控指标值得关注：如果发现 Pod 终止时经常接近 grace period 上限才退出，说明应用关闭逻辑有问题，得去查是不是有连接没关、线程没停。
6. 多容器 Pod 的协作模式：Init 容器与边车的正确打开方式
6.1 Init 容器：把“启动前置条件”从主容器里剥离
Init 容器是在主容器启动之前串行执行的容器，每个都必须成功退出才会执行下一个，全部完成后主容器才开始启动。它的价值在于把初始化逻辑和主业务解耦：等待依赖服务就绪、拉取配置、初始化数据目录、设置文件权限，这些动作放在 Init 容器里，主容器镜像就能保持干净，只关心业务本身。
Init 容器有几个特性需要记住：它们共享 Pod 的存储卷和网络命名空间，所以可以往共享卷里写文件给主容器用；它们不支持生命周期钩子和探针，因为本身就是一次性执行；如果 Init 容器失败，Pod 会按 restartPolicy 重试，日志可以用kubectl logs pod-name -c init-container-name查看。我经常用 Init 容器做“等待数据库可连接”的动作，用一个循环脚本加超时，比在主容器启动脚本里塞等待逻辑清晰得多。
有个坑要注意：Init 容器的资源 requests 会计入 Pod 的调度计算，取的是“所有 Init 容器中最大的 requests”和“所有主容器 requests 之和”的较大值。所以如果某个 Init 容器需要大内存做数据初始化，它会抬高整个 Pod 的调度门槛，即使它只运行几秒钟。这种情况要么把初始化拆到 Job 里做，要么接受这个调度成本。
6.2 边车模式：日志、代理、配置同步的常见形态
边车（sidecar）容器是和主容器并行运行、共享网络和存储的辅助容器。典型用途包括：日志收集（边车读共享卷里的日志文件转发出去）、网络代理（边车接管流量做治理）、配置同步（边车监听配置变化并写入共享卷）。边车的好处是职责分离、可以独立升级，坏处是增加了 Pod 的复杂度和资源开销。
边车的资源也要单独配 requests 和 limits，别让它和主容器抢资源。日志收集类边车一般 CPU 需求低但内存要留够缓冲，代理类边车 CPU 和内存都要按流量规模给。还有一个协作细节：边车和主容器的启动顺序没有保证，如果边车负责给主容器提供某种“就绪信号”，主容器不能假设边车一定先起来，得用重试或者就绪检查来处理。
现在有些场景会用原生边车容器（把 init 容器声明为 restartPolicy: Always），它相比传统边车的好处是启动顺序有保证、生命周期和主容器绑定更紧密。这个特性在较新版本里才稳定，用之前要确认集群版本支持，别在旧集群上配了不生效还找不到原因。
6.3 共享卷与网络命名空间带来的协作便利与陷阱
同一个 Pod 里的容器共享网络命名空间，意味着它们可以通过 localhost 互相访问，端口不能冲突。这个特性让边车代理模式变得很自然：主容器监听业务端口，边车监听管理端口，两者通过 localhost 通信。但端口冲突是常见错误，两个容器都想监听 8080 就会有一个起不来，报错信息是 “bind: address already in use”，排查时容易误以为是宿主机端口被占。
共享卷方面，emptyDir 是最常用的容器间数据交换方式，但要注意它的生命周期和 Pod 绑定，Pod 删除数据就没了。如果边车和主容器同时读写同一个文件，要考虑并发安全，比如日志轮转时主容器在写、边车在读，文件被 rename 的瞬间边车可能读到不完整的内容，这类问题在高吞吐场景下才会暴露，测试环境很难复现。我的建议是容器间数据交换尽量用“一个写一个读”的单向模式，避免双向并发写同一文件。
7. 排查 Pod 问题的固定动作：从 describe 和 events 顺藤摸瓜
7.1 Pending、CrashLoopBackOff、ImagePullBackOff 的排查顺序
Pod 出问题时，我有一套固定的动作顺序，基本能覆盖八成场景。第一步永远是kubectl describe pod，重点看 Events 段落和 Status 里的 Reason。Pending 看事件里的调度失败原因（资源不足、亲和性不匹配、污点不容忍）；CrashLoopBackOff 看 Last State 的退出码和 Reason（OOMKilled 还是应用自身报错）；ImagePullBackOff 看拉镜像失败的具体信息（镜像名错、仓库认证失败、网络不通）。
第二步是看日志，kubectl logs加--previous看上一个崩溃实例的日志，因为当前实例可能还没输出就挂了。第三步是看容器内状态，必要时kubectl exec进去手动执行探针命令，验证是不是探针本身的问题。这个顺序的逻辑是“先看调度层、再看容器层、最后看应用层”，从外往里剥，避免一上来就钻应用代码。
7.2 那些 describe 里看不出、只能靠监控发现的问题
describe 和 events 能覆盖创建和启动阶段的问题，但运行阶段的很多问题它们看不到。比如 CPU 被限流（throttling），describe 里一切正常，但应用延迟就是高，得看容器的 cpu throttled 指标；比如内存缓慢增长到接近 limit，describe 里没有异常，但随时可能 OOM，得看内存使用趋势；比如探针偶发超时导致 readiness 抖动，Endpoints 频繁增删，得看探针成功率的时序数据。
所以生产环境一定要配容器级别的监控，至少覆盖 CPU 使用率与限流比例、内存使用量与 limit 的比值、重启次数、探针成功率这几项。我踩过的坑是只配了节点级监控，节点整体资源看着很闲，但某个 Pod 因为 limit 设得低一直在被限流，从节点视角完全看不出来，最后是靠应用侧延迟报警才定位到。
7.3 一个真实排查链路的复盘
说一个我印象比较深的案例。某服务滚动发布时总有少量请求超时，比例不高但每次发布必现。排查链路是这样的：先看发布期间的 Pod 事件，发现旧 Pod 终止和新 Pod 就绪的时间有重叠但重叠窗口很短；再看旧 Pod 的日志，发现有请求在收到 SIGTERM 之后还在处理，但处理到一半连接被断；查配置发现 preStop 没配，grace period 是默认 30 秒，应用关闭逻辑里有个连接池关闭动作要等 15 秒，加上 Endpoints 传播延迟，30 秒不够覆盖。
修复方案就是前面说的组合：加 preStop 先置不健康再等 8 秒，应用侧确保 SIGTERM 后不再接新请求，grace period 调到 45 秒。改完之后再发布，超时消失。这个案例说明一个道理：Pod 的终止流程是个多方协作的时序问题，任何一环缺失都会在发布这种“批量终止”的场景下被放大，平时单实例重启反而不容易暴露。
8. 写在配置之外的一点个人体会
Pod 这一层的配置看起来都是声明式的 YAML，但每个字段背后都对应着运行时的一段真实行为。调度字段对应的是调度器的过滤打分逻辑，探针字段对应的是 kubelet 的周期性检查，资源字段对应的是 cgroup 的限额和内核的 OOM 判定，生命周期字段对应的是终止时序上的信号传递。把这些字段和运行时行为对上号之后，排查问题就不再是“试参数”，而是“顺着链路找断点”。
我自己维护配置的习惯是给每个非默认字段写一行注释，说明为什么这么设、依据是什么。比如 grace period 旁边写“preStop 10s + 应用关闭 20s + 余量 15s”，探针旁边写“启动实测 90s，startup 给 180s”。这些注释在半年后回头看的时候价值极大，因为那时候你已经忘了当初的取舍理由，而配置本身不会告诉你为什么。另外，任何涉及调度约束和资源配额的改动，我都会先在预发环境用接近生产的负载压一轮，重点看 Pending 率和 OOM 率，这两个指标最能反映配置和实际负载是否匹配。
最后分享一个小技巧：排查 Pod 问题时，养成先kubectl get pod -o wide看 Pod 落在哪个节点、再看该节点状态的顺序，很多“Pod 有问题”其实是“节点有问题”，比如节点磁盘压力触发驱逐、节点 NotReady 导致 Pod 被重建。把 Pod 和节点的关系先理清，能省掉不少在应用层瞎找的时间。
