8 工作负载控制器

在6、7文章中，介绍了Pod的基本概念、常用命令、健康检查、变量、资源限制、调度等概念与实践，尤其是实践环节，基本都是通过修改yaml文件然后创建Pod来操作的。然而在实际工作中，我们直接去创建Pod的情况很少，更多的是通过工作负载控制器来完成。

之所以前面介绍Pod的操作，是因为在介绍工作负载控制器前之前，有必要单独介绍Pod的相关配置（健康检查、调度等等）从而熟悉yaml文件中对应字段的写法并验证对应的效果，而这些配置完全可以放到工作负载控制器的yaml文件中完成。

目录

1 工作负载控制器的概念

1.1 常用的工作负载控制器

1.2 控制器的作用

2 项目生命周期介绍

3 Deployment

3.1 介绍

3.2 部署应用

3.3 滚动升级

3.4 回滚

3.5 水平扩缩容

3.6 删除下线

4 DaemonSet

5 Job 和 CronJob

5.1 Job

5.2 CronJob

---

1 工作负载控制器的概念

工作负载控制器（Workload Controllers）是K8s的一个抽象概念，用于更高级层次对象，部署和管理Pod。

1.1 常用的工作负载控制器

• Deployment ：无状态应用部署
• StatefulSet ：有状态应用部署
• DaemonSet ：确保所有Node运行同一个Pod
• Job ：一次性任务
• Cronjob ：定时任务

1.2 控制器的作用

• 管理Pod对象
• 使用标签与Pod关联
• 控制器实现了Pod的运维，例如滚动更新、伸缩、副本管理、维护Pod状态等

2 项目生命周期介绍

实际的项目部署流程如下，接下来的内容，会按照应用程序部署、滚动升级、回滚、项目下线的顺序依次介绍一个项目在K8S集群中的整个生命周期。而本次文章主要是针对无状态应用进行部署和生命周期管理，因此实际上介绍的是Deployment控制器在项目生命周期管理中的具体使用方式。

3 Deployment

3.1 介绍

• Deployment对象，顾名思义，是用于部署应用的对象。它是Kubernetes中最常用的一个对象，为ReplicaSet和Pod的创建提供了一种声明式的定义方法，从而手动创建。
• 而之所以使用Deployment而不直接创建ReplicaSet和Pod是因为Deployment对象拥有许多ReplicaSet、Pod所没有的特性，例如滚动升级和回滚等。

功能

• 管理Pod和ReplicaSet
• 具有上线部署、副本设定、滚动升级、回滚等功能
• 提供声明式更新，例如只更新一个新的Image

应用场景

• 网站
• API
• 微服务

3.2 部署应用

编写应用程序并将其封装成Docker镜像之后，为了方便，假设应用程序就是Nginx，现在要通过Deployment控制器将它部署到K8S集群中，步骤如下：

#1、创建deployment的yaml文件
vi deployment.yaml

#2、编辑yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
  namespace: default
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: web
        image: nginx:1.15

#3、部署
kubectl apply -f deployment.yaml

#4、查看pod
kubectl get pod -o wide

#5、暴露服务
kubectl expose deployment web --port=80 --target-port=80 --type=NodePort

#6、查看所暴露的服务
kubectl get svc

#7、访问：任意节点ip:port
192.168.200.211:30853

  

3.3 滚动升级

（1）滚动升级操作

滚动升级的操作其实非常简单，只要镜像仓库中存在新版本的Docker镜像，那么直接执行如下三种方式的任意一种即可完成滚动升级（我习惯用方式1）：

• 方式1：修改deployment发yaml文件，将里面的镜像名称换成最新的即可，然后执行指令：kubectl apply -f deployment.yaml
• 方式2：直接显示的设置新的版本，指令：kubectl set image deployment web web=nginx:1.18 --record

上述指令的意思是：给名字为web的deployment资源的容器设置镜像，容器名字也为web，镜像为nginx:1.18 并且把这条指令记录下来，可以通过kubectl rollout history deployment web指令查看该资源的发布历史。

• 方式3：kubectl edit deployment/web

滚动升级完毕，直接访问：

（2）滚动升级过程介绍

K8s对Pod升级的默认策略，通过使用新版本Pod逐步更新旧版本Pod，实现零停机发布，用户无感知。

通过如下指令，进行验证滚动升级是不是这样做的：

#查看所有deployment资源
kubectl get deploy 

#查看deployment资源的详细信息
kubectl describe deploy <name>

 （3）滚动更新中的ReplicaSet

ReplicaSet控制器用途：

• Pod副本数量管理，不断对比当前Pod数量与期望Pod数量，如果你手动删除一个Pod，replicaset检测到之后会马上重新拉起一个新的pod，总之要保证副本数和deployment的yaml文件中所定义的一致。
• Deployment每次发布都会创建一个RS作为记录，用于实现回滚

ReplicaSet相关指令如下：

#查看RS记录
kubectl get rs

#查看版本对应的RS记录
kubectl rollout history deployment web 

 此外deployment资源的yaml文件中其他的一些参数定义如下（一般情况下默认策略是够用的）：

#查看已经创建好的deployment（这个yaml文件中信息要比当初创建deployment用的yaml文件全很多，毕竟当初很多默认参数没有指定）
kubectl get deploy web -o yaml

#其中：
#revisionHistoryLimit参数用来指定replicset的版本数量（回滚会用到）
#maxSurge：滚动更新过程中最大Pod副本数，确保在更新时启动的Pod数量比期望（replicas）Pod数量最大多出25%
#maxUnavailable：滚动更新过程中最大不可用Pod副本数，确保在更新时最大25%Pod数量不可用，即确保75%Pod数量是可用状态。

3.4 回滚

回滚是重新部署某一次部署时的状态，即当时版本所有配置，通过以下指令可以回滚到指定版本以及查看历史发布版本信息：

#查看历史发布版本
kubectl rollout history deployment web

#注意：其实利用K8S原生的指令也可以查看历史信息，如以下指令一起使用
kubectl get rs -o wide
kubectl describe rs <rs的name>

#回滚到上一个版本
kubectl rollout undo deployment web 

#回滚历史指定版本
kubectl rollout undo deployment web --to-revision=3 

3.5 水平扩缩容

水平扩缩容的具体执行者为ReplicaSet，而控制其执行的是Deployment：

这里的扩缩容指的是应用副本数的增加或减少，用于控制并发。有以下2种方法，二选一即可：

• 方法1：修改yaml里replicas值，再apply
• 方法2：kubectl scale deployment web --replicas=10

3.6 删除下线

先删除deployment，再删除service

#删除deployment（或者通过yaml文件删除：kubeclt delete -f deployment.yaml）
kubectl delete deploy/web

#删除service
kubectl delete svc/web

4 DaemonSet

DaemonSet功能：

• 在每一个Node上运行一个Pod
• 新加入的Node也同样会自动运行一个Pod

应用场景：部署网络插件（kube-proxy、calico）、其他Agent

如果需要在每一个Node上都运行一个Pod的话，就可以用DaemonSet来完成，比如在每个Node上部署一个日志采集程序：

#1、创建DaemonSet的yaml
daemonset.yaml

#2、编辑yaml
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: filebeat
  namespace: kube-system
spec:
  selector:
    matchLabels:
      name: filebeat
  template:
    metadata:
      labels:
        name: filebeat
    spec:
      tolerations:
      - effect: NoSchedule
        operator: Exists
      containers:
      - name: log
  
#3、部署
kubectl apply -f daemonset.yaml

#4、查看
kubectl get pod -n kube-system -o wide

5 Job 和 CronJob

Job分为普通任务（Job）和定时任务（CronJob）。

5.1 Job

应用场景：离线数据处理，视频解码等业务。

和之前那种“常驻型进程”不同的是，Job执行完之后，对应的Pod就不再运行了。如果不用K8S，之前执行一次性任务的做法就是找一台机器然后执行某一个临时性的任务，不会进行相应的记录及管理，而K8S可以帮助我们将这些任务管理起来。

实践：打印圆周率的前2000位

#1、创建yaml
vi job.yaml

#2、编辑yaml
apiVersion: batch/v1
kind: Job
metadata:
  name: pi
spec:
  template:
    spec:
      containers:
      - name: pi
        image: perl
        command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
      restartPolicy: Never

#3、启动
kubectl apply -f job.yaml

#4、查看job
kubectl get job

#5、查看pod：该定时任务执行完之后，pod处于completed状态，不会自动删除
kubectl get pod

5.2 CronJob

CronJob用于实现定时任务，像Linux的Crontab一样。

应用场景：通知，备份

实践：创建一个定时任务（每分钟创建一个busybox的Pod，并且打印时间+一句话）

#1、创建yaml
vi cronjob.yaml

#2、编辑yaml
apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: hello
spec:
  schedule: "*/1 * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: hello
            image: busybox
            args:
            - /bin/sh
            - -c
            - date; echo Hello
          restartPolicy: OnFailure

#3、部署
kubectl apply -f cronjob.yaml

#3、等1分钟后，查看pod，发现创建了hello这个定时任务pod
kubectl get pod

#4、进入刚才创建好的pod，查看日志：发现确实完成了一次定时任务
kubectl logs hello-1628478120-xlzbp

#5、查找cronjob
kubectl get cronjob

#6、删除cronjob
kubectl delete cronjob hello