Kubernetes 官方文档把对象管理方式划分为三类：命令式命令、命令式对象配置和声明式对象配置。命令式对象配置的典型特征是以 YAML 或 JSON 配置文件作为操作入口，通过 kubectl create -f、kubectl replace -f、kubectl delete -f 等指令直接作用于对象。相比逐个参数拼命令的方式，它更适合把环境配置沉淀到版本库中；相比 kubectl apply 的自动合并逻辑，它的行为又更加直白、可预测。不过直白也意味着责任上移：配置文件必须尽量完整，否则 replace 可能把对象改坏。本文重点拆解命令式对象配置的执行细节和适用边界。

一、为什么需要区分三种管理方式

Kubernetes 的三种管理方式并不是简单的新旧替代关系，它们分别对应不同场景。命令式命令（imperative commands）把参数直接传给 kubectl，例如 kubectl run nginx --image=nginx:1.21，优点是上手快、一条命令就能创建资源，但缺点是参数不落盘，操作记录分散在 shell 历史里，难以审计和复用。

命令式对象配置（imperative object configuration）则要求先写好配置文件，再用 -f 参数指定文件。这里的“命令式”体现在每个指令都表达一个明确动作：create 是创建，replace 是替换，delete 是删除。它解决了参数不落盘的问题，配置文件本身成为可版本化的基础设施代码，但也引入了一个新要求：执行 replace 时必须提供完整对象定义。

声明式对象配置（declarative object configuration）以 kubectl apply -f 为代表，用户只需要描述期望状态，控制平面会计算差异并执行补丁。它比 replace 更宽容，适合频繁迭代，但底层依赖 kubectl.kubernetes.io/last-applied-configuration 注解，行为稍复杂。理解这三者边界，才能避免把 replace 当成 apply 用的常见事故。

二、配置文件命令式管理的核心命令：create、replace、delete

先看一个基础的 Deployment 配置。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deploy
  labels:
    app: nginx
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.21
        ports:
        - containerPort: 80

执行 kubectl create -f deployment.yaml 后，API 服务器会创建该 Deployment。如果同名资源已经存在，命令会直接报错，提示 AlreadyExists。这不是 bug，而是一种保护机制，防止误创建覆盖已有资源。团队中如果出现这个错误，通常说明配置文件与线上状态不一致，需要先确认是应该删除线上资源，还是修改配置文件中的 name。

kubectl replace -f deployment.yaml 则要求资源必须已存在。它会用文件中的内容整体替换现有对象，而不是只更新文件中写明的那几个字段。比如原 Deployment 带有 strategy 或 revisionHistoryLimit 等字段，而配置文件中没有写，replace 后这些字段可能被 API 默认值填充甚至清除。因此 replace 前最好用 kubectl get deployment nginx-deploy -o yaml 获取线上完整清单，再修改后执行。

kubectl delete -f deployment.yaml 会删除文件中声明的所有对象。如果一个文件里通过 --- 分隔了多个对象，delete 会逐个删除。注意 delete 只认文件中的 kind 和 metadata.name，不校验 spec 内容是否与线上完全一致，因此即使文件里的镜像版本已经过期，delete 仍然会删除同名资源。删除前可以使用 --dry-run=client 先观察目标对象。

三、命令式配置与声明式 apply 的关键差异

第一次接触 kubectl apply 时，很多人会以为它只是 create 和 replace 的合体，实际上两者的工作机制完全不同。kubectl apply -f 在首次创建后，会把配置文件内容存到对象注解 kubectl.kubernetes.io/last-applied-configuration 中；后续再次 apply 时，kubectl 会对比本地文件、线上对象和该注解三份数据，生成一个最小化补丁，只更新有变化的部分。

举一个典型差异：Service 资源在创建后会自动生成 clusterIP，如果不用 apply 而直接执行 replace，且配置文件中没有 clusterIP 字段，replace 可能尝试清空该字段，导致服务中断。而 apply 会识别出本地文件没有改动 clusterIP 意图，只更新端口、selector 等差异。类似的还有 Deployment 的 status 子资源，虽然这些字段本身由控制器维护，但整体替换仍可能误伤。

命令式对象配置的价值在于行为确定性。因为 create、replace、delete 不依赖注解，也不做三方合并，所以在 CI/CD 流程中更容易判断每一步会产生什么结果。比如发布脚本可以明确执行 kubectl replace -f app.yaml，如果失败就终止，不会出现 apply 那种“部分补丁已应用但整体状态难判断”的中间态。但代价是必须由人来保证配置文件与线上对象一致。

总结一句：如果只是初始化一次性资源或删除整套环境，命令式配置足够；如果是需要长期维护、频繁更新的业务服务，apply 通常更安全。

四、实际工作中的配置组织与排错建议

配置文件命令式管理最容易出现的问题不是命令本身，而是文件组织混乱和对象不完整。建议按环境或应用拆分文件，而不是把所有资源堆在一个巨大的 all.yaml 里。比如一个微服务目录可以包含 deployment.yaml、service.yaml、configmap.yaml，发布时使用 kubectl replace -f ./k8s/ 批量替换整个目录。kubectl 会递归读取目录中的 yaml 和 yml 文件。

多资源批量操作时，create 和 delete 对子资源的处理顺序可能不是用户期望的。例如先创建 Deployment 再创建 Service 通常没问题，但反过来可能短暂出现 Service 没有可用后端的情况。虽然 Kubernetes 最终会收敛，但在命令式管理下，失败不会自动回滚，因此建议重要发布流程使用 kubectl diff -f 或 --dry-run=server 预检。

另一个实操建议是善用 kubectl create --dry-run=client -o yaml 生成初始配置。比如需要快速得到一个 Deployment 的 YAML 骨架，可以执行：

kubectl create deployment web \
  --image=nginx:1.21 \
  --replicas=3 \
  --dry-run=client \
  -o yaml > web-deployment.yaml

注意上面命令中的 > 是重定向符号，在代码块中已转义。生成后再手动补充 labels、资源限制等字段，会比从空白文件写更准确。最后，无论用 create、replace 还是 delete，都建议把配置文件纳入 Git 版本管理，并在提交信息中记录变更原因，这样当线上对象与仓库不一致时，可以直接通过 diff 定位是谁在什么时间做了什么修改。