服务端应用是什么
普通的 apply 在客户端算出补丁再发给集群，冲突时容易后写覆盖先写；服务端应用把合并交给 API Server：每个字段记录由哪个管理者（kubectl、控制器、运维脚本）负责，谁改了自己负责的字段还能改回去，改别人的字段则明确报冲突。它还顺带解决了客户端 apply 把上一份配置存进注解、大对象撑爆注解上限的问题。多控制器共同管理同一对象、或使用 GitOps 工具链时，服务端应用是更稳的选择。
基本信息
| 启用方式 | kubectl apply --server-side -f 文件.yaml |
|---|---|
| 字段管理 | 每个字段由 managedFields 记录所属管理者，可用 --field-manager 指定名字 |
| 冲突处理 | --force-conflicts 可强制接管他人字段，属于危险操作 |
| 适用版本 | 客户端 1.16 起支持，集群侧能力在 1.22 起正式可用 |
| 优势 | 不再依赖上一份配置注解，大对象不受注解大小限制 |
| 查看 | kubectl get 对象 -o yaml 里的 managedFields 段 |
典型使用场景
- GitOps 工具与人工 kubectl 同时管理同一对象，需要明确字段归属
- 大对象 apply 报注解过大错误，需要绕开注解存储机制
- 排查字段漂移：确认某个字段当前由哪个管理者持有
- 多控制器共同维护同一自定义资源的不同字段
- 从客户端应用迁移到服务端应用的过渡期，逐步统一管理策略
使用示例
使用示例
kubectl apply --server-side -f deploy.yaml # 由 API Server 合并字段
kubectl apply --server-side --field-manager=ci-bot -f deploy.yaml # 指定管理者名，便于定位冲突
kubectl get deploy web -o yaml | grep -A15 managedFields # 看字段由谁管理
kubectl apply --server-side --force-conflicts -f deploy.yaml # 强制接管冲突字段（谨慎）
kubectl apply --server-side --dry-run=server -f deploy.yaml # 先试运行确认不会冲突冲突处理对照
| 现象 | 原因 | 处理方式 |
|---|---|---|
| 提示字段冲突 | 字段已被其他管理者持有 | 先确权，再决定是否强制接管 |
| 字段被改回原值 | 另一控制器持续收敛该字段 | 明确责任边界，不要两边同时管 |
| 注解过大报错 | 客户端应用把上一份配置写进注解 | 改用服务端应用 |
| 字段归属混乱 | 新旧客户端混用写入 | 统一客户端版本与策略 |
从客户端应用迁移到服务端应用时，首次执行很可能报冲突：确认没有控制器正在管理相关字段后，再使用强制接管完成过渡。
--force-conflicts 会把字段从其他管理者手里夺走：未确权就使用，控制器可能反复把配置改回，形成来回抖动。