SSA 是什么
服务端应用（Server-Side Apply，SSA）把原本由 kubectl 在本地做的合并计算交给 API Server：客户端只提交自己负责的字段，apiserver 依据 metadata.managedFields 中记录的字段所有者（field manager）逐字段合并，并在多个管理者争抢同一字段时报冲突。它要解决的是流水线、控制器与运维手工修改同一个对象时互相覆盖的老问题，Kubernetes 1.16 引入、1.22 起正式可用。
基本信息
| 适用平台 | Kubernetes 1.16+ 引入，1.22 起 GA |
|---|---|
| 核心命令 | kubectl apply --server-side -f <文件|目录> |
| 字段账本 | metadata.managedFields（记录每个字段归谁） |
| 管理者名称 | --field-manager=<名称>，默认 kubectl |
| 冲突处理 | --force-conflicts 强行接管字段所有权 |
典型使用场景
- 流水线发布：CI 以独立的管理者名只接管自己声明的字段，不再整份覆盖运维手工加的注解与副本数
- 多控制器共管一个对象：HPA 管 replicas、发布流水线管 image，两边各自记账，互不覆盖
- GitOps 工具（Argo CD、Flux）启用 SSA 后能准确报告字段漂移，而不是每次都判定整份清单不一致
- 排查「这个字段是谁改的」：读 managedFields 就能看到每个字段的管理者与最后写入时间
- 从客户端 apply 迁移过来时，先用 --force-conflicts 一次性接管既有字段所有权，之后回归正常发布流程
常用命令
常用命令
kubectl apply --server-side -f deploy.yaml # 以 SSA 方式应用单个清单
kubectl apply --server-side -f ./manifests/ -n prod # 应用整个目录
kubectl apply --server-side --field-manager=ci-pipeline -f deploy.yaml # 指定管理者名，便于追责
kubectl apply --server-side --force-conflicts -f deploy.yaml # 确认归属后强行接管冲突字段
kubectl get deploy web -o yaml | sed -n '/managedFields:/,/status:/p' # 查看字段所有权账本managedFields 读法
| 条目 | 含义 | 关注点 |
|---|---|---|
| manager | 写入者名称，如 kubectl、ci-pipeline、kube-controller-manager | 出现陌生 manager 说明还有别的工具在改同一对象 |
| operation | Apply 表示 SSA 提交，Update 表示整对象覆盖 | 两种方式混用是所有权争夺的主要来源 |
| fieldsV1 | 该管理者当前拥有的字段清单 | 决定冲突时报出哪个字段 |
| time | 最后一次写入时间 | 时间很久远说明该管理者已经不再参与维护 |
冲突报错怎么读
冲突报错怎么读
# Apply failed with 1 conflict: conflict with "kubectl": .spec.replicas
# 含义：另一个管理者也声明了 replicas，SSA 不会隐式覆盖它的字段
# 处理一：确认后者已废弃，用 --force-conflicts 接管
# 处理二：把该字段从本方清单里删掉，让另一方继续持有客户端 apply 依靠 last-applied-configuration 注解做三方合并，与 SSA 的 managedFields 机制是两套账。同一对象混用两种方式，会出现字段删除语义不一致、所有权互相顶掉的现象，团队内部应统一一种。
--force-conflicts 会把控制器正在管理的字段划到自己名下，例如抢走 HPA 拥有的 replicas 后，HPA 可能不再能写该字段，副本数长期停在清单里的静态值。使用前先看 managedFields 判断归属。