直接改Deployment的image字段可触发滚动更新，但必须用StrategicMergePatchType仅patch镜像（含digest）、校验就绪、更新status并处理Conflict，否则易致中断或死循环。
直接改 Deployment 的 spec.template.spec.containers[0].image 字段就能触发滚动更新，但“能触发”不等于“安全可用”——Operator 必须自己校验镜像 digest、等待就绪、处理冲突、记录事件，否则一次自动升级可能造成服务中断或状态漂移。
用 controller-runtime Patch 镜像字段，别用 Replace
替换整个 Deployment 对象（client.Update()）会覆盖你没显式设置的字段（比如 resourceVersion、annotations），极易引发 Conflict 错误或丢失配置。正确做法是只 patch 镜像字段：
- 用
types.MergePatchType或types.StrategicMergePatchType构造 patch payload，只包含spec.template.spec.containers[0].image - 必须带上当前对象的
ResourceVersion，否则并发更新时可能被静默覆盖 - 捕获
errors.IsConflict(err)并重试：先Get()最新版本，再重新 patch - 示例 patch 内容：
{"spec":{"template":{"spec":{"containers":[{"name":"app","image":"nginx@sha256:abc123"}]}}}}
镜像必须带 digest，不能用 :latest 或 :v1.2.3
用 tag 拉取镜像无法保证一致性——同一 tag 可能被覆盖、重推，导致 Operator 认为“已更新”，实际运行的是旧二进制。Kubernetes 官方也明确建议使用 digest 引用：
- 在 Go 中用
github.com/google/go-containerregistry/pkg/v1/remote获取镜像 manifest，调用image.Digest()得到确定性哈希值 - 生成的 image 字符串应为
registry.example.com/app@sha256:deadbeef...，而非registry.example.com/app:v1.2.3 - 私有 registry 需提前注入
imagePullSecrets，并在 remote.Fetch 时传入authn.DefaultKeychain或自定义authn.Keychain
更新前检查 Pod 就绪状态，避免滚动卡住
Kubernetes 默认的 maxUnavailable: 1 和 minReadySeconds: 0 不足以保障零中断。Operator 要主动干预：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 更新前用
corev1client.Pods(clientset).List()查询旧版本 Pod，确认所有 Pod 处于Running且至少一个 container 的Ready == true - 更新后轮询目标 Service 的
/healthz端点（带超时和重试），连续 3 次返回 200 才认为新版本就绪 - 若健康检查失败，立即用相同 patch 方式回滚到旧 digest，并写入
eventRecorder.Eventf(..., "UpgradeFailed", ...) - 务必设置 Deployment 的
spec.minReadySeconds: 10和spec.strategy.rollingUpdate.maxUnavailable: 0，这是控制器逻辑生效的前提
status 字段必须更新，否则 Reconcile 会无限重试
很多新手只改 spec，忘了更新 CR 的 status 字段。Reconcile 函数每次执行都对比 spec 和 status，如果 status 没同步反映“当前运行的是哪个镜像”，下一次 reconcile 会再次触发更新，形成死循环：
- 在 patch 成功且健康检查通过后，调用
updateStatus()方法，把当前生效的image和digest写入 CR 的status.currentImage和status.lastUpdated - status 更新也要用
Patch（不是 Update），并处理 Conflict；controller-runtime 的subresource.Status()client 就是干这个的 - 如果 CR 定义里没加
// +kubebuilder:subresource:status注释，make manifests不会生成 status subresource，patch status 会直接 404
最易被忽略的一点：Operator 不是“一键升级工具”，它本质是状态对齐器。你写的每行 patch、每次 health check、每个 status 更新，都在定义“什么算升级成功”。漏掉其中任一环，自动化就会退化成半自动，甚至制造故障。
