3. Pod 原地升级机制
3.1 原地升级定义
Pod 原地升级（In-Place Update） 是指在不重建 Pod 的前提下，直接修改 Pod 的容器镜像、资源请求/限制、环境变量、启动命令等属性，并触发容器运行时重新拉取镜像、重启容器实例的过程。在 Kata Containers 场景下，原地升级意味着 不销毁/重建虚拟机沙箱，仅更新沙箱内的容器负载。
核心特征： Pod 的 UID、Node 绑定、网络 IP、Volume 挂载点、QoS 等级均保持不变；仅容器运行时层面发生重启。
3.2 原地升级 vs 滚动升级
| 对比维度 | 原地升级（In-Place Update） | 滚动升级（Rolling Update） |
|---|---|---|
| Pod 生命周期 | Pod 对象不删除，仅更新 spec 字段 | 创建新 Pod，删除旧 Pod |
| Node 绑定 | 保持不变 | 可能重新调度到不同 Node |
| 网络 IP | 不变 | 新 Pod 获取新 IP |
| Volume 持久性 | 挂载点不变，数据不丢失 | 需依赖 PV/PVC 重新挂载 |
| 调度决策 | 不触发调度器 | 触发调度器重新选择 Node |
| Kata 沙箱 | 虚拟机沙箱不重建 | 销毁旧沙箱，创建新沙箱 |
| 适用场景 | 紧急热修复、配置微调 | 版本迭代、大规模更新 |
关键区别： 原地升级不经过调度器，因此 亲和性规则不会重新评估。如果集群拓扑发生变化（如 Node 标签变更），原地升级后的 Pod 可能处于“亲和性违规”状态——这正是本课程排查的核心故障场景。
3.3 原地升级触发条件
Kubernetes 允许对 Pod 进行原地更新的字段有限，并非所有 spec 变更都能触发原地升级。以下变更会触发容器重启（原地升级）：
- image：容器镜像 tag 或 digest 变更
- resources.limits / requests：CPU/内存资源量调整
- env：环境变量增删改（包括 valueFrom 引用）
- command / args：容器启动命令或参数变更
- terminationGracePeriodSeconds：优雅终止等待时间调整
- readinessProbe / livenessProbe / startupProbe：探针参数变更
- lifecycle：postStart / preStop 钩子变更
注意： 以下变更 不会 触发原地升级，而是导致 Pod 重建：nodeSelector、affinity、tolerations、securityContext（Pod 级别）、serviceAccountName、hostNetwork、hostPort 等调度/安全相关字段。这些字段的修改会触发 Pod 删除重建。
3.4 原地升级流程概览
当用户通过 kubectl patch pod 或控制器（如 Deployment 的 updateStrategy.type: RollingUpdate 配合原地升级插件）发起原地升级时，Kubernetes API Server 与 kubelet 之间的交互流程如下：
- API Server 校验：检查变更字段是否属于可原地更新集合；若包含不可原地更新字段，则拒绝或降级为重建。
- 更新 Pod 对象：将新 spec 写入 etcd，Pod 的
resourceVersion递增。 - kubelet Watch 到变更：kubelet 通过 List-Watch 机制感知 Pod 更新事件。
- 计算 diff：kubelet 对比当前运行状态与期望 spec，识别需要重启的容器。
- 执行原地升级：对目标容器依次执行 preStop 钩子（如有）、发送 SIGTERM、等待优雅终止、拉取新镜像、创建新容器、执行 postStart 钩子（如有）。
- 更新状态：kubelet 将容器状态更新回 API Server，Pod 状态变为
Running。
3.5 原地升级与亲和性调度的关联
在标准 Kubernetes 调度模型中，Pod 的亲和性规则仅在 调度阶段 由 kube-scheduler 评估。原地升级 不经过调度器，因此亲和性规则不会重新计算。这意味着：
- 如果 Node 标签在 Pod 运行后被修改（例如移除某个拓扑键），Pod 可能处于亲和性规则不满足的状态。
- 如果集群新增了满足亲和性条件的 Node，原地升级的 Pod 也不会被重新调度过去。
- 在 Kata Containers 场景下，由于虚拟机沙箱与宿主机之间的亲和性绑定更为复杂（如 NUMA 拓扑、设备直通），原地升级后可能出现 隐式亲和性冲突。
故障根因预判： 当 Pod 原地升级后出现启动失败、调度异常或性能下降时，应优先检查 Node 标签是否发生变化、亲和性规则是否仍被满足、以及 Kata 沙箱的拓扑绑定是否失效。