kubectl create/apply/replace/edit tips

0、导

今天开发同事更新了镜像的代码包，然后因为是测试环境所以他并没有修改镜像的tag，然后他提供了一个服务名qld2managerpkg让我帮他部到k8s里边，因为我刚入职，不是特别清楚服务器上的目录结构，也就不是很清楚他想使用服务的资源清单是哪个。

先用kubectl get deploy -A | grep qld2managerpkg，也describe了啥的，然后我想第一时间想到的是使用kubectl edit编辑修改Deployment，因为仓库的镜像名称什么都没改，edit的时候什么也没改，退出编辑之后就发现也并没有发生变化。

然后我就使用find /home/k8s/ -name '*qld2managerpkg*'模糊查询找到了对应yaml资源清单，最终使用replace重新发布了一遍，同时领导也告知该开发同学测试环境也要维护版本。

# find /home/k8s/ -name  "*qld2managerpkg*"
# kubectl replace --force -f /home/k8s/XXXXX/qld2managerpkg.yml

然后就引发了我一个小疑问？kubectl edit的原理是什么呢？为什么没有变化呢？暂时还不会go，就放弃了edit源码剖析。思考了一下我觉得是这样：

1、kubectl edit/replace 区别：

replace是主动替换资源并进行发布(默认会检查资源是否发生了变化，如果加上--force就会将原先资源删除后重新创建)，edit则是会检测资源清单的字段有没有发生变化（spec下字段发生变化就会更改，metadata下字段变化就不会更改），例如我没有更改镜像名称（什么也没改），所以edit就不会重新发布。

在replace集群svc资源时必须要加上--force，否则会报错 The Service "XXXXX" is invalid: spec.clusterIP: Invalid value: "": field is immutable

然后我又想到了create、apply，就去回顾了一下区别

2、kubectl create/apply 区别

kubectl create -f nginx.yaml
kubectl replace -f nginx.yaml

# 对于上面这种先 kubectl create，再 replace 的操作，称为命令式配置文件操作

kubectl apply -f nginx.yaml
# 如果修改镜像，只需修改nginx.yaml文件，然后执行
kubectl apply -f nginx.yaml

kubectl create / replace 与kubectl apply 的区别:

kubectl replace 的执行过程，是使用新的 YAML 文件中的 API 对象，替换原有的 API 对象

kubectl apply，则是执行了一个对原有 API 对象的 PATCH 操作

kubectl create命令，是先删除所有现有的东西，重新根据yaml文件生成新的。所以要求yaml文件中的配置必须是完整的

kubectl apply命令，根据配置文件里面列出来的内容，升级现有的。所以yaml文件的内容可以只写需要升级的属性