K8s 硬核踩坑:修改 YAML 改 Pod 名称后 apply、delete 到底发生了什么?
前言
最近在学习 K8s Pod 基础操作时,我遇到了一个90% 新手都会混淆的致命误区:
修改本地 YAML 文件中 Pod 的 name 字段,再次执行 kubectl apply,到底是更新原 Pod 还是新建 Pod?为什么最后 kubectl delete -f 只能删掉新 Pod,旧 Pod 还残留?
今天通过亲手实验,彻底搞懂 create / apply / delete 的底层逻辑,记录学习心得。
一、完整实验操作流程
1、第一次创建 Pod
编写 pod.yml,Pod 名称为 mypod
apiVersion: v1
kind: Pod
metadata:
name: mypod
spec:
containers:
- name: hello
image: busybox
imagePullPolicy: IfNotPresent
command: ['sh', '-c', 'echo "Hello, Pod!" && sleep 3600']
restartPolicy: OnFailure
执行创建命令:
kubectl apply -f pod.yml
此时集群创建出第一个 Pod:mypod
2、修改本地 YAML,更改 Pod 名称
我没有删除原有 Pod,直接修改本地 pod.yml,将名称改为 mypod1
metadata:
name: mypod1
再次执行:
kubectl apply -f pod.yml
二、实验结果(重点!颠覆新手认知)
执行完后查看 Pod:
kubectl get pods
发现两个 Pod 同时存在:
- mypod(旧 Pod,依然运行)
- mypod1(新 Pod,刚刚创建)
新手最大误区
我原本以为:
修改 YAML 重新 apply,会替换、更新、覆盖原来的 Pod
真实结论
修改 YAML 里的 name,apply 不会更新旧资源,只会新建资源!
三、核心原理(彻底吃透)
K8s 判断资源的唯一标识:metadata.name
name: mypod→ K8s 识别为「资源 A」name: mypod1→ K8s 识别为「资源 B」
只要 name 不一样,在 K8s 眼里就是两个毫无关系的独立资源!
本地 YAML 只是一个配置模板:
- 改本地文件,不会影响集群已存在的资源
- apply 只能「同名更新、异名新建」
四、终极踩坑:为什么 delete -f 删不掉旧 Pod?
现在本地 YAML 保存的是 name: mypod1
我执行:
kubectl delete -f pod.yml
输出:pod "mypod1" deleted
旧的 mypod 依旧存在!
原因
kubectl delete -f yaml文件 规则:只删除「当前 YAML 文件中定义的资源」
旧的 mypod 已经不在当前 YAML 配置中,文件和旧资源彻底解绑,自然不会被删除。
删除残留旧 Pod 方法
只能根据资源名称手动删除:
kubectl delete pod mypod
五、kubectl create 和 kubectl apply 生产使用场景区别
通过本次实验,彻底明白为什么生产环境只推荐 apply
1、kubectl create
- 逻辑:纯新建资源
- 特点:同名资源存在直接报错,不支持更新、不可重复执行
- 场景:仅用于本地学习、临时测试
- 生产环境几乎不用
2、kubectl apply(生产标配)
- 逻辑:声明式管理
- 无资源 → 创建
- 有同名资源 → 智能更新
- 特点:幂等性,可反复执行、适配自动化 CI/CD
- 优势:适配迭代更新、配置修改、版本升级
- 生产 99% 场景全部使用 apply
关键总结
- 改配置不改 name → apply 更新资源
- 改配置同时改 name → apply 新建资源
六、最终知识点总结
- K8s 资源唯一标识是
metadata.name,名字不同就是两个独立资源 - 本地 YAML 只是模板,修改本地文件不影响集群存量资源
apply是「同名更新、异名新建」delete -f只删除当前 YAML 对应的资源,旧资源会残留- 测试可用 create,生产环境一律使用 apply
七、学习感悟
之前一直混淆「本地 YAML 文件修改」和「集群资源更新」的关系,这次亲手踩坑、观察现象、分析原理,彻底通透:
K8s 资源拥有独立生命周期,和本地 YAML 文件不绑定!
看似简单的 Pod 创建命令,背后是 K8s 声明式管理的核心思想,基础扎实,后续学习部署、更新、回滚才不会乱!
更多推荐



所有评论(0)