Kubernetes中web-nginx Pod添加initContainer执行kubectl apply遇更新报错

Kubernetes 对已创建的Pod 资源设置了固定的更新边界：spec.containers、spec.initContainers、spec.ephemeralContainers 三类容器列表字段，只要Pod完成初始创建，所有原地更新操作都不允许新增、删除列表条目，也不允许调整条目顺序。
你遇到的报错本质是：集群中已经存在名为web-nginx的存量Pod，这次apply提交的yaml配置，和现存Pod的initContainers配置存在差异（最常见的场景是原本的Pod没有配置initContainers，这次提交时新增了前置初始化容器逻辑），属于规则明确禁止的“给已存在Pod新增容器”操作，因此被API server直接拦截。

报错提示中提到的pod updates may not add or remove containers，规则的覆盖范围包含initContainers字段，并非仅针对常规应用容器的更新限制。

• 若web-nginx是独立创建、未被任何工作负载控制器（Deployment/StatefulSet/DaemonSet等）托管：
  先删除存量的旧Pod，再用新配置重新创建即可，对应执行命令：
  kubectl delete pod web-nginx
  再次执行kubectl apply -f pod.yaml就能正常完成Pod创建，不会触发更新校验。
• 若web-nginx是由工作负载控制器（最常见为Deployment）托管：
  不要直接删除Pod——控制器检测到Pod缺失后，会立刻按照旧配置拉起新Pod，操作完全无效。正确做法是修改对应控制器的Pod模板（即Deployment/StatefulSet配置中spec.template.spec段落），把initContainers配置写入模板定义，保存后K8s会自动触发滚动更新流程，逐步销毁旧配置的Pod，拉起带新initContainers配置的新Pod。
• 避坑提示：哪怕你只是调整initContainers内的镜像版本、启动命令参数，只要改动了容器列表的具体条目，都属于被禁止的原地更新范围，无法通过kubectl patch、kubectl edit等方式直接修改运行中的Pod，必须走Pod重建流程。这种机制设计的原因是，Pod的网络命名空间、存储卷挂载在启动阶段就已完成初始化，运行中动态新增/移除容器会破坏Pod的运行时一致性，因此从底层逻辑上完全禁止了这类操作。

内容的提问来源于stack exchange，提问作者Jayesh Desai