.create 是"第一次建"，apply 是"按声明式配置创建/更新（可重复执行）"。当我们写 YAML 发布用 apply；临时建一个对象（比如 create configmap/secret）可以用 create。（测试）
很多人刚学 Kubernetes 的时候，会把 kubectl create 和 kubectl apply 当成"差不多的创建命令"。但真用起来你会发现，它俩的思路完全不一样：一个更像你在命令行里"下指令"，另一个更像你把一份"标准答案"交给集群，让它一直照着执行。
那它们到底差在哪？
差在"你想让集群做一次动作"，还是"你想让集群长期保持某个状态"。
先看 kubectl create。它的性格很直接：我现在就要创建一个资源。它只负责"第一次出生"，不管"后续怎么长大"。
如果资源已经存在呢？
那它就会直接报错，最常见就是 AlreadyExists。这也决定了它更偏"命令式"------你告诉系统立刻做一件事，做过了就算完，不会帮你处理"已经有了怎么办"。
再看 kubectl apply。它更像"声明式管理"：你给它一份 YAML，相当于告诉 Kubernetes------我希望资源长期保持成这个样子。
如果资源不存在会怎样？
apply 会创建。
如果资源已经存在呢？
apply 不会急着报错，而是会按 YAML 的期望状态去更新（本质是 patch）。所以它特别适合日常迭代：配置改了就更新，配置没变就保持原样，重复跑也不会出问题。
那什么时候用 create，什么时候用 apply？
如果你只是第一次快速把资源建出来，create -f xxx.yaml 很顺手。
如果你是要反复发布、反复调整配置（尤其是 CI/CD、上线迭代这种），apply -f xxx.yaml 更稳，因为它能"创建或更新"，不会被"已经存在"卡住。
更新能力上，两者有什么明显差距？
create 本身不负责更新。你想改东西通常得换用 kubectl replace / kubectl patch / kubectl edit。
apply 则天生就是为"配置反复调整"准备的，很多时候我们把它当成"发布按钮"，因为它可以反复执行，结果依然可控（幂等）。
例子：
比如你发一个 Deployment：
第一次你用 create 或 apply 都能成功。
第二次你再拿同一个文件跑：
-
create：资源已存在 → 直接报错 -
apply：对比配置 → 有变化就更新，没变化基本不动