kubectl apply 是干什么的
kubectl apply 是声明式管理的核心命令：把配置文件里的期望状态提交给集群，由集群自己收敛过去，因此可以反复执行而不会报错。它和 create 的区别在于语义：create 遇到已存在的资源会直接失败，apply 则做增量更新，是配置管理、流水线与 GitOps 的基础动作。
基本信息
| 基本语法 | kubectl apply -f 文件名，也可指定目录或地址 |
|---|---|
| 模板渲染 | 加 -k 直接应用 kustomize 目录，无需手工渲染再管道 |
| 预检方式 | --dry-run=client 只本地渲染，--dry-run=server 走服务端校验 |
| 幂等性 | 可重复执行，依据上次应用记录计算变更 |
| 与 create 对比 | create 已存在即报错，apply 做收敛式更新 |
| 作用范围 | 只处理文件里出现的资源，不会删除文件中已移除的对象 |
典型使用场景
- 发布与更新：改完配置直接应用，滚动更新由控制器负责
- 多环境部署：同一份模板通过不同渲染层发布到开发、预发与生产
- 流水线集成：构建产物与配置一起应用，配合状态检查判断发布是否成功
- 变更预检：先用服务端试运行校验配置能否被接受，避免直接改到线上
- 批量导入：把一个目录下的多个配置文件一次应用
- 配置收敛：把手工改乱的资源用文件重新收敛回期望状态
常用参数速查
| 参数 | 作用 | 使用注意 |
|---|---|---|
| -f 路径 | 指定文件或目录 | 目录会递归处理里面所有配置文件 |
| -k 目录 | 应用 kustomize 渲染结果 | overlay 结构下比先渲染再应用更直接 |
| --dry-run=client | 本地渲染不提交 | 只能发现格式问题 |
| --dry-run=server | 服务端校验 | 能发现字段不被接受这类问题 |
| -n 命名空间 | 指定命名空间 | 文件里已写命名空间时不要覆盖 |
| --prune | 清理不在文件中的资源 | 需配合白名单，风险高，仅在明确场景使用 |
使用示例
使用示例
kubectl apply -f deploy.yaml # 应用单个文件
kubectl apply -k overlays/prod/ # 应用 kustomize 渲染结果
kubectl apply -f ./manifests/ --dry-run=server # 提交前先做服务端校验
kubectl apply -f web.yaml && kubectl rollout status deploy/web # 应用后跟发布状态
kubectl get deploy web -o yaml > web-live.yaml # 导出线上配置做比对apply 不会删除文件中已被移除的资源：删资源要在配置仓库里做删除同步，或显式删除。删除动作比更新危险，必须走变更评审。
不要对同一个资源混用创建与编辑类命令：上次应用记录错乱后，apply 的结果会与文件内容不符，排查时极易误判。
配置目录要干净：目录里混进过期文件后，过期资源会被反复写回，与正在做的删除操作互相打架。
应用完成不等于发布完成：随后要跟一次发布状态检查，确认新版本真的滚动完成并通过了就绪检查。
变更管理的配套动作
- 配置只在仓库里改，避免有人在集群里手工改动造成状态漂移
- 应用前先做服务端预检，把字段类错误挡在发布之前
- 应用后核对资源状态与就绪情况，确认变更真的落地生效
- 资源的删除走明确流程，不要指望应用命令自动清理
- 为每次发布记录变更原因，回滚与复盘时才对得上号
- 大批量应用时分批执行，出问题时影响范围仍然可控
把配置内容与镜像版本一起纳入发布记录，出现问题时能快速确定当时生效的到底是哪一份配置，回滚也有明确基准。