last-applied 注解是什么
apply 会把上一次提交的清单以注解形式记在对象上（kubectl.kubernetes.io/last-applied-configuration）。它不是备份，而是三方合并的基线：apply 时把新清单、这条基线与现网对象三者对比，未被人改动的字段按新清单更新，被别人改过的字段保留现网值，只有在基线里存在、新清单中删掉的字段才会被清空。理解这一点，很多「apply 了却没生效」的疑问就有了解释。
基本信息
| 注解名 | kubectl.kubernetes.io/last-applied-configuration |
|---|---|
| 相关子命令 | view-last-applied、edit-last-applied、set-last-applied |
| 用途 | 查看与调整 apply 的合并基线 |
| 影响 | 手工改动基线的对象，后续 apply 行为随之改变 |
| 查看方式 | kubectl apply view-last-applied <资源>/<名称> |
典型使用场景
- 排查「apply 后字段没变」：对照基线确认字段是否被别人改过
- 确认某次发布提交了什么：基线内容就是上次 apply 的清单
- 清理遗留字段：找到基线里存在而现网不再需要的配置项
- 审计变更：比对基线与现网的差异定位手工改动
- 接管历史对象：了解哪些对象从未经过 apply 管理
查看与核对
查看与核对
kubectl apply view-last-applied deploy/web # 查看基线
kubectl apply view-last-applied -f deploy.yaml # 按文件对应对象查看
kubectl get deploy web -o jsonpath='{.metadata.annotations.kubectl\.kubernetes\.io/last-applied-configuration}' > base.json
kubectl diff -f deploy.yaml # 基线与现网差异的直观入口三方合并的三个输入
| 输入 | 来源 | 作用 |
|---|---|---|
| 新清单 | 本地文件或目录 | 期望状态，决定要改成什么 |
| 合并基线 | 对象上的 last-applied 注解 | 上次提交内容，用于识别字段是被清单删除还是被人改动 |
| 现网对象 | 集群当前存储值 | 作为保留依据，被别人改过的字段默认不动 |
如果对象上原本没有这条注解（例如由 kubectl create 手工创建），apply 缺少基线，就无法区分字段是被删除还是被人改动，行为更接近整体覆盖，处理这类历史对象时要格外留意。
基线的内容是完整清单，直接打印会非常长：重定向到文件或用 jsonpath 取出来再看，避免刷屏影响排查节奏。