首先关注 pod 上原地升级状态的流转

Lifecycle circulation

其次关注单个 pod 原地升级过程中的详细步骤：

图片中详细介绍了 kruise 组件进行原地升级的全过程，主要关注：

  1. kruise controller 记录上次 pod 的信息打进 pod annotation
  2. 更改 pod 字段
  3. 由 kueblet 和 kruise daemon 负责对应的容器更新过程
  4. daemon 上报一些container 相关的信息到 pod annotation 中
  5. kruise controller 利用 daemon 上报的容器元信息和 pod 当时的状态进行对比，确定该 pod 是否更新完成
  6. (H) kruise controller 将更新完成的 pod 状态 readiness gate 和 label 中的状态置为 Normal (webhook逻辑)

一般确定原地升级字段已经更改为期望的值后，我们主要关注为什么 pod 的 readiness gate 还不置为 True，主要是第六步的判断逻辑。

案例：

当 daemon 一直没起来，或者之前没有部署 daemon 的情况下， pod 会因为缺少 daemon 上报的容器元信息而无法推进原地升级判断（开启 env from metadat 时）

此时即使把 daemon 拉起之后，pod 依然没有该 annotation。

阅读源码后可知，daemon 在启动时只会对存在 “apps.kruise.io/runtime-containers-meta” annotation 的 pod 进行处理，其余不触发后续操作

判断逻辑

此时有几种思路但都是为了触发容器状态上报流程

  1. 手动添加改  “apps.kruise.io/runtime-containers-meta” annotation，可行
  2. 任意修改该 pod 描述，以 annotation 为例，可行

提供一个简单的命令触发该流程

1
kubectl annotate po -n {{ns}} {{pod}} trigger=aa