直接用Update会报422错误，因API禁止spec全量覆盖；必须用StrategicMergePatchType Patch，仅指定name和新image即可安全更新容器镜像。
直接用 Update 会报错：spec 不允许全量覆盖
调用 clientset.AppsV1().Deployments(ns).Update() 修改 deployment.Spec.Template.Spec.Containers[0].Image 后提交，Kubernetes API 会返回 422 Unprocessable Entity 错误，提示 Invalid value: "spec": invalid spec。这是因为 Kubernetes 默认禁止对已存在对象的 spec 字段做全量替换（防止意外丢掉服务器端默认值、status 相关字段等）。这不是 client-go 的 bug，而是 API 层的强约束。
必须用 Patch，且优先选 StrategicMergePatchType
StrategicMergePatchType 是最稳妥的选择，它能理解 Kubernetes 资源结构语义（比如容器列表按 name 合并），不会清空未提及的字段。其他 patch 类型风险更高：
-
MergePatchType：要求 JSON key 完全匹配，容器数组里漏写某个字段会导致其被置空 -
JSONPatchType：语法复杂，易出错，且不支持原生的“按 name 替换容器”语义 -
ApplyPatchType：需带fieldManager，client-go v0.28+ 才稳定支持，生产环境慎用
示例 patch 数据（注意 name 必须与原容器名严格一致）：
patchData := []byte(`{
"spec": {
"template": {
"spec": {
"containers": [
{
"name": "my-app",
"image": "nginx:1.25"
}
]
}
}
}
}`)
执行：
_, err := appsV1.Patch(ctx, "my-deployment", types.StrategicMergePatchType, patchData, metav1.PatchOptions{})
多个容器时，只列要改的就行，但别漏掉 name
如果 Deployment 有 3 个容器，而你只想更新其中叫 api-server 的那个，patchData 里只需写这一个容器对象，其他两个不受影响。前提是：
-
"name"字段值和原 YAML 中完全一致（大小写、连字符都不能错） - 不要在 patch 里写
"containers": []这种空数组，那会清空全部容器 - 如果容器用了
imagePullPolicy或envFrom等非必需字段，且你没在 patch 里显式保留，它们不会被删除——StrategicMergePatchType天然支持“只覆盖提到的字段”
镜像拉不到？Patch 成功 ≠ Pod 能跑起来
Patch 操作本身不校验镜像是否存在或能否拉取。失败表现是新 Pod 卡在 ContainerCreating，kubectl describe pod 显示 Failed to pull image 或状态为 ImagePullBackOff。排查要点：
- 在任一 worker 节点上手动运行
docker pull your-registry.com/myapp:1.25，确认网络和权限正常 - 检查 Deployment 中该容器的
imagePullPolicy：若为IfNotPresent，节点已有旧镜像时不会重拉；生产建议设为Always（尤其 tag 是latest时） - 确认 ServiceAccount 有对应 secret（如私有仓库凭据），且已挂载到
imagePullSecrets
滚动更新是否卡住，90% 和镜像拉取有关，和 patch 写法无关——这点最容易被忽略。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
