别再乱用kubectl了！-f 和 -k 的区别，这一篇给你讲透

同样是部署YAML，为什么项目推荐用 -k 而不是 -f？

---

一、引子：一个让你深夜崩溃的场景

        小张刚学Kubernetes，照着教程写好了所有YAML文件，执行：

bash

kubectl apply -f k8s/

        然后他看到了这个报错：

text

Error from server (NotFound): error when creating "k8s/backend-deployment.yaml": 
namespaces "camp" not found

        小张懵了：明明namespace.yaml和deployment.yaml在同一个目录里，为什么说找不到命名空间？

        答案就藏在-f和-k的区别里。

---

二、三秒钟记住核心区别

命令	一句话解释	记忆口诀
kubectl apply -f ./	按文件名排序，逐个发送	“谁排在前面谁先跑”
kubectl apply -k ./	先读配置文件，整理后再发送	“先看清单，再干活”

💡 记住：-f = file（文件），-k = kustomize（整理后再执行）。

---

三、一个例子让你彻底看懂

你的k8s/目录长这样：

text

k8s/
├── namespace.yaml      # 定义 namespace: camp
├── backend-deployment.yaml  # 依赖 namespace: camp
└── kustomization.yaml  # 声明了上面两个文件

方式一：kubectl apply -f k8s/

执行过程：

1. 读取目录下所有文件名，按字母顺序排序：backend-deployment.yaml（b）排在了namespace.yaml（n）前面

2. 先部署backend-deployment.yaml → 找不到camp命名空间 → ❌ 报错！

3. 再部署namespace.yaml → 但已经晚了

结论：文件名决定了部署顺序，不可控，容易出错。

方式二：kubectl apply -k k8s/

执行过程：

1. 先读取kustomization.yaml，看看里面写了哪些资源

2. Kustomize自动分析依赖关系 → 发现backend-deployment.yaml依赖namespace.yaml

3. 自动调整顺序：先创建namespace，再创建deployment

4. 一次性全部成功 → ✅ 搞定！

        结论：Kustomize帮你处理了资源依赖，顺序不再依赖文件名。

---

四、最形象的比喻

        想象你要搬家，有两种方式：

方式	比喻
-f	没请搬家公司：你自己一趟一趟跑，先搬什么后搬什么全凭心情，搬错了还得重新来。
-k	请了搬家公司：你只需要列个清单（kustomization.yaml），搬家公司会按最优顺序帮你搬好，不用你操心。

        你选哪种？

---

五、还有一个致命区别：白名单 vs 黑名单

方式	行为	风险
-f	目录下所有.yaml文件都会被部署	如果你在目录里放了一个test.yaml做测试，忘了删，它也会被部署到生产环境！
-k	只有kustomization.yaml里声明的文件才会被部署	未声明的文件一律无视，安全可控。

        这就是“白名单”思维：我明确告诉你用哪些文件，没列出来的你别动。

---

六、实战命令对比表

操作	-f 方式	-k 方式
部署	kubectl apply -f k8s/	kubectl apply -k k8s/
删除	kubectl delete -f k8s/	kubectl delete -k k8s/
预览（查看要部署什么）	kubectl apply -f k8s/ --dry-run=client -o yaml	kubectl kustomize k8s/
查看资源状态	kubectl get pods -n camp	kubectl get pods -n camp
更新镜像	手动改YAML文件 + kubectl apply -f	修改kustomization.yaml或补丁文件 + kubectl apply -k

---

七、什么时候用 -f，什么时候用 -k？

场景	推荐方式	理由
快速测试一个单文件的YAML	-f	就一个文件，没那么多事儿。
临时查看某个资源	-f	快速验证，用完就删。
部署正式项目（多文件）	-k	依赖关系自动处理，不容易翻车。
管理多个环境（dev/staging/prod）	-k	支持“基础配置+环境覆盖”模式，不用复制整个目录。
这个项目的生产部署	-k	项目里已经有kustomization.yaml，直接用它。

---

八、总结：一张图记住全部

text

┌─────────────────────────────────────────────────────────────┐
│                                                             │
│   kubectl apply -f k8s/    =    按文件名顺序，逐个发送      │
│                                                             │
│   kubectl apply -k k8s/    =    先看清单，整理后再发送      │
│                                                             │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│   核心区别：                                                │
│   ✅ -k 会处理资源依赖顺序（先建namespace，再建deployment）   │
│   ❌ -f 不会，谁文件名排前面谁先跑                           │
│                                                             │
│   ✅ -k 只部署清单里声明的文件（白名单）                    │
│   ❌ -f 部署目录下所有YAML（不小心就部署了测试文件）        │
│                                                             │
└─────────────────────────────────────────────────────────────┘

一句话记住：-f是“乱序逐个发”，-k是“整理后统一发”。有了-k，你就不用再跟文件名较劲了。

---

九、课后作业

在你的项目里分别执行这两个命令，看看输出有什么不同：

bash

# 看传统的文件拼接结果
kubectl apply -f k8s/ --dry-run=client -o yaml | head -50

# 看Kustomize整理后的结果
kubectl kustomize k8s/ | head -50

你会发现，同样的文件，-k输出的内容更有序、更合理。这就是Kustomize的价值所在。

  

相关阅读：

• 《从零理解Kubernetes核心概念：Pod、Service、Ingress》

• 《别再手动写K8s YAML了！Helm保姆级入门指南》

• 《一个真实项目的k8s/目录全解析》