Kubectl apply/delete 命令：管理 K8s 资源的生命周期

各位观众老爷们，晚上好！我是你们的老朋友，人称“Bug终结者”的码农老王。今天咱们不聊代码，聊聊咱们Kubernetes集群里的“生死簿”——kubectl apply和kubectl delete命令。

这两个命令，绝对是K8s玩家的必备技能。你想想，咱们辛辛苦苦写好的YAML文件，要部署到集群里，或者觉得某个资源碍眼了，想把它踢出去，都得靠它们。就像孙悟空的金箍棒，指哪打哪，控制着咱们K8s资源的生杀大权。

但是，别看它们名字简单，用法可一点都不含糊。用好了，事半功倍；用不好，可能就把集群搞得鸡飞狗跳。所以，今天老王就跟大家掰开了揉碎了，好好讲讲这两个命令，保证让你们听完之后，也能像老王一样，玩转K8s资源！😎

第一幕：kubectl apply——资源的创造者与守护者

kubectl apply，顾名思义，就是“应用”的意思。它主要负责将咱们定义的YAML或JSON文件，应用到K8s集群中，创建或更新资源。

想象一下，你是一位建筑师，拿着设计图纸（YAML文件），想要在K8s这片土地上建造一座房子（资源）。kubectl apply就是你的施工队，按照图纸，一砖一瓦地把房子盖起来。

1. 创建资源：从无到有，化腐朽为神奇

当你第一次使用kubectl apply，并且指定的资源在集群中不存在时，它就会创建一个新的资源。这就像在一片空地上，拔地而起一座高楼大厦，充满了创造的喜悦！

举个例子，咱们创建一个简单的Deployment：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-nginx
  template:
    metadata:
      labels:
        app: my-nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80

保存为my-nginx.yaml，然后执行：

kubectl apply -f my-nginx.yaml

控制台会输出：

deployment.apps/my-nginx created

恭喜你！你的第一个Deployment就这样诞生了！🎉

2. 更新资源：精益求精，让资源更完美

kubectl apply的强大之处在于，它不仅仅能创建资源，还能更新资源。这就像装修房子一样，你想换个壁纸，改个灯，甚至把厨房的格局都变了，都可以通过kubectl apply来实现。

但是，这里有一个非常重要的概念，叫做“服务器端应用（Server-Side Apply）”。

• 客户端应用（Client-Side Apply）：这是早期的更新方式，kubectl会读取YAML文件，然后与集群中的资源进行对比，计算出差异，最后将差异发送到集群进行更新。这种方式容易出现冲突，尤其是当多个用户同时修改同一个资源时。
• 服务器端应用（Server-Side Apply）：kubectl apply默认使用的就是这种方式。kubectl会将整个YAML文件发送到集群，由集群来计算差异，并进行更新。这种方式可以避免客户端应用的冲突问题，更加可靠。

服务器端应用的优势：

特性	客户端应用	服务器端应用
冲突解决	容易出现冲突，尤其是多人同时修改时	更好地处理冲突，集群负责计算差异和合并
追踪更改	无法追踪更改的来源	可以追踪更改的来源，方便审计和回滚
性能	客户端需要计算差异，性能较低	集群负责计算差异，性能更高
适用场景	适用于单人操作，或者对一致性要求不高的场景	适用于多人协作，对一致性要求高的场景，推荐使用服务器端应用

举个例子：

假设你想把my-nginx Deployment的副本数从3改成5：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-nginx
spec:
  replicas: 5  # 修改这里
  selector:
    matchLabels:
      app: my-nginx
  template:
    metadata:
      labels:
        app: my-nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80

再次执行：

kubectl apply -f my-nginx.yaml

控制台会输出：

deployment.apps/my-nginx configured

kubectl apply会检测到replicas字段发生了变化，然后将Deployment的副本数更新为5。

3. 标志（Flags）：锦上添花，让kubectl apply更强大

kubectl apply有很多有用的标志，可以让你更灵活地控制资源的创建和更新：

• -f <file>：指定要应用的YAML或JSON文件。
• -k <directory>：指定包含多个YAML文件的目录。
• --prune：删除集群中不再存在于YAML文件中的资源。这个标志非常有用，可以清理集群中不再需要的资源。
• --force：强制更新资源，即使出现冲突。慎用！
• --dry-run=client|server：模拟运行，不实际修改集群。可以用来检查YAML文件是否正确。
• --field-manager=<manager-name>：指定字段管理器。服务器端应用使用字段管理器来追踪更改的来源。

4. 最佳实践：让kubectl apply更安全可靠

• 使用版本控制： 将你的YAML文件存储在Git等版本控制系统中，方便追踪更改和回滚。
• 使用--dry-run进行预览： 在实际应用之前，先使用--dry-run模拟运行，检查YAML文件是否正确。
• 谨慎使用--force： 除非你非常确定自己在做什么，否则不要使用--force标志。
• 使用Kustomize或Helm： 这些工具可以让你更方便地管理复杂的K8s资源。

第二幕：kubectl delete——资源的终结者与清洁工

kubectl delete，顾名思义，就是“删除”的意思。它负责从K8s集群中删除资源。

想象一下，你是一位拆迁队队长，拿着拆迁令（kubectl delete命令），要把K8s这片土地上的一些旧房子（资源）拆掉，为新的建设腾出空间。

1. 删除资源：毫不留情，让资源消失得无影无踪

kubectl delete可以删除各种类型的K8s资源，例如Pod、Deployment、Service、Namespace等等。

删除单个资源：

kubectl delete deployment my-nginx

这会删除名为my-nginx的Deployment。

删除多个资源：

kubectl delete pod my-pod-1 my-pod-2 my-pod-3

这会删除名为my-pod-1、my-pod-2和my-pod-3的Pod。

从YAML文件删除资源：

kubectl delete -f my-nginx.yaml

这会删除my-nginx.yaml文件中定义的资源。

按标签删除资源：

kubectl delete pod -l app=my-nginx

这会删除所有带有app=my-nginx标签的Pod。

删除所有资源：

kubectl delete all --all

注意： 这个命令非常危险，会删除集群中的所有资源，请谨慎使用！

2. 级联删除：斩草除根，不留后患

有些资源之间存在依赖关系，例如Deployment会创建ReplicaSet，ReplicaSet会创建Pod。当你删除Deployment时，默认情况下，ReplicaSet和Pod也会被自动删除。

这种行为叫做级联删除（Cascading Deletion）。

但是，你可以通过--cascade标志来控制级联删除的行为：

• --cascade=true：启用级联删除（默认行为）。
• --cascade=false：禁用级联删除。

举个例子：

如果你想删除Deployment，但不删除它创建的ReplicaSet和Pod，可以使用以下命令：

kubectl delete deployment my-nginx --cascade=false

3. 优雅删除：给资源一个体面的告别

默认情况下，kubectl delete会立即删除资源。但是，有些资源可能需要一些时间才能完成清理工作，例如Pod可能需要等待容器停止运行。

为了保证资源的优雅删除，你可以使用--grace-period标志来指定一个宽限期（grace period）。在这个宽限期内，资源不会被立即删除，而是会进入一个“终止中（Terminating）”的状态。

举个例子：

kubectl delete pod my-pod --grace-period=30

这会给my-pod一个30秒的宽限期，让它可以优雅地停止运行。

4. 标志（Flags）：化腐朽为神奇，让kubectl delete更灵活

kubectl delete也有很多有用的标志，可以让你更灵活地控制资源的删除：

• -f <file>：指定要删除的YAML或JSON文件。
• -k <directory>：指定包含多个YAML文件的目录。
• -l <label selector>：指定标签选择器，删除符合条件的资源。
• --grace-period=<seconds>：指定宽限期。
• --cascade=<true|false>：控制级联删除的行为。
• --force：强制删除资源，即使出现错误。慎用！
• --dry-run=client|server：模拟运行，不实际删除资源。可以用来检查命令是否正确。

5. 最佳实践：让kubectl delete更安全可靠

• 使用--dry-run进行预览： 在实际删除之前，先使用--dry-run模拟运行，检查命令是否正确。
• 谨慎使用--force： 除非你非常确定自己在做什么，否则不要使用--force标志。
• 了解级联删除： 在删除资源之前，了解它是否会影响其他资源。
• 使用宽限期： 尽可能使用宽限期，保证资源的优雅删除。
• 备份重要数据： 在删除资源之前，备份重要数据，以防万一。

第三幕：kubectl apply vs kubectl delete——相爱相杀，完美搭档

kubectl apply和kubectl delete就像一对欢喜冤家，一个负责创建和更新资源，一个负责删除资源。它们相互配合，共同管理着K8s资源的生命周期。

功能	kubectl apply	kubectl delete
作用	创建或更新K8s资源	删除K8s资源
使用场景	部署新的应用，更新已有的应用	移除不再需要的应用，清理集群资源
核心概念	服务器端应用（Server-Side Apply），字段管理器，冲突解决	级联删除，优雅删除，宽限期
常用标志	-f, -k, --prune, --force, --dry-run, --field-manager	-f, -k, -l, --grace-period, --cascade, --force, --dry-run
最佳实践	使用版本控制，使用--dry-run进行预览，谨慎使用--force，使用Kustomize或Helm	使用--dry-run进行预览，谨慎使用--force，了解级联删除，使用宽限期，备份重要数据

总结：

kubectl apply和kubectl delete是K8s集群管理的两大利器。掌握它们，你就可以像一位经验丰富的园丁一样，在K8s这片土地上，播种希望（创建资源），修剪枝叶（更新资源），清除杂草（删除资源），让你的应用茁壮成长！

希望今天的讲解能帮助大家更好地理解和使用kubectl apply和kubectl delete命令。如果大家还有什么疑问，欢迎在评论区留言，老王会尽力解答。

最后，祝大家玩转K8s，Bug forever away! 🙏