k8s中控制器使用详解

一、什么是控制器

控制器是管理pod的中间层，只需要告诉Pod控制器，想要创建多少个什么样的Pod，它会创建出满足条件的Pod ；
控制器相当于一个状态机，用来控制Pod的具体状态和行为；
controller会自动创建相应的pod资源，并在当pod发生故障的时候按照策略进行重新编排；
通过它来实现对pod的管理，比如启动pod、停止pod、扩展pod的数量等等；

通俗来说就是，控制器就是pod的幕后老板

二、k8s中常用的控制器

k8s发展到今天，产生了很多种控制器，以下列举常用的几类控制器；

ReplicaSet

ReplicaSet 主要具备下面的特点：

一种副本控制器，简称rs，主要是控制由其管理的pod，使pod副本的数量始终维持在预设的个数；
并支持pod数量扩缩容，镜像版本升级；
官方建议不要直接使用ReplicaSet，用Deployments更好，并提供很多其它有用的特性；

Deployment

通过控制ReplicaSet来控制Pod，并支持滚动升级、回退版本，适合无状态的服务部署

主要特点如下：

当某个应用有新版本发布时，Deployment会同时操作两个版本的ReplicaSet ；
内置多种滚动升级策略，会按照既定策略降低老版本的Pod数量，同时也创建新版本的Pod ；
Deployment控制器不直接管理Pod对象，而是 Deployment 管理ReplicaSet, 再由ReplicaSet管理Pod对象；

DaemonSet

在K8S集群部署中由于节点数量不定，那么如果我们需要对每个节点中都运行一个守护进程、日志收集进程等情况时，在k8s中如何实现呢？这个时候就是DaemonSet应用场景了

其主要特点如下：

这类Pod 运行在K8S 集群里的每一个节点（Node）上，确保所有节点上有且仅有一个pod ；
有新的节点加入 K8S集群后，该 Pod 会自动地在新节点上被创建出来；
而当旧节点被删除后，它上面的 Pod也相应地会被回收掉；
应用场景：监控告警Agent、日志组件、监控组件等；

StatefulSet

像RS、Deployment、DaemonSet都是面向无状态的服务，所管理的Pod的IP、名字，启停顺序都是随机，StatefulSet就是有状态的集合，管理所有有状态的服务

其特点如下：

StatefulSet 中的 Pod 具有黏性的、独一无二的身份标识，重新调度后PodName和HostName不变；
Pod重新调度后还是能访问到相同的持久化数据，基于PVC实现；
分配给每个 Pod 的唯一顺序索引，Pod 的名称的形式为：<statefulset name>-<ordinal index> ；

应用场景：比如MySQL、MongoDB集群

Horizontal Pod Autoscaler

可以基于 CPU 利用率或其他指标实现Pod水平自动扩缩；
被伸缩的pod需要是通过deployment或者replica set管理；
HPA不能应用于不可伸缩的对象，如：DaemonSets ；
由资源来决定控制器行为，控制器周期性调整目标pod的副本数量，让目标pod的实际cpu使用率符合用户指定的数值；

Job

普通任务容器控制器，只会执行一次,只要完成任务就立即退出，不需要重启或重建；
容器中的进程在正常运行结束后不会对其进行重启,而是将pod对象置于completed状态；
若容器中的进程因错误而终止,则需要依据配置确定是否需要重启；
应用场景：批处理程序，完成后容器就退出等；

Cronjob

顾名思义，Linux 中有 cron 程序定时执行任务，K8s的 CronJob 提供了类似的功能，可以定时执行 Job；

创建的Pod负责周期性任务控制；
应用场景：执行周期性的重复任务，如备份数据、发送邮件、数据报表、报告生成等；

三、k8s控制器之ReplicaSet

上文系统介绍了k8s中常用的几类控制器，接下来以ReplicaSet这种控制器为例进行详细的说明；

早期k8s没那么多控制器，使用Replication Controller 来部署、升级Pod，简称RC ，也被称为下一代Replication Controller

1、关于ReplicaSet特性

一种副本控制器，简称rs，主要是控制由其管理的pod，使pod副本的数量始终维持在预设的个数；
并支持pod数量扩缩容，镜像版本升级；
官方建议不要直接使用ReplicaSet，用Deployments更好，并提供很多其它有用的特性；

2、ReplicaSet控制器配置模板样例

通常在实际业务中，控制器的设置，也是通过在yaml中通过一些标签元素进行设置，如下：




apiVersion: apps/v1 # 版本号




kind: ReplicaSet  #资源文件 




metadata: # 元对象信息




  name: test-rs #rs控制器名称




  namespace: default #名称空间




spec: #具体详情




  replicas: 2 #副本数量




  selector: # 选择器，指定rs控制器管理哪些pod资源




    matchLabels: # 标签匹配规则




      app: test-nginx-pod #标签key是app,值是xdclass-nginx-pod




      



  template: # pod模板，当数量不满足的时候，根据下面编码创建pod副本




    metadata: # 元对象信息




      labels: # pod资源标签




        app: test-nginx-pod



    spec: #具体详情




      containers: # 容器数组列表




      - name: test-nginx  #容器名称




        image: nginx:1.23.0  # 镜像和版本

在当前目录下创建一个yaml，拷贝上面的内容，然后执行 apply命令创建pod

kubectl apply -f

执行完成后，可以看到，上面创建了2个副本的pod

3、使用ReplicaSet命令行进行缩容

如果在业务的低峰期，不需要开启那么多pod的时候，就可以考虑缩减pod的个数，使用ReplicaSet的操作命令很容易达到这个目的；

kubectl scale rs test-rs --replicas=1 -n default

参数说明：

test-rs ，上面的rs名称；
-n default ，pod所在的namespace名称；

执行完成后，可以看到 pod只剩1个了；

4、删除rs创建的pod

可以直接删除rs；也可以通过yaml删除

kubectl delete -f

执行之后，可以看到下面的效果，pod就被删掉了

四、k8s控制器之Deployment

Deployment 也是一种控制器，在之前的文章中也在反复的使用它创建pod，其特点如下：

通过控制ReplicaSet来控制Pod，并支持滚动升级、回退版本，适合无状态的服务部署；
当某个应用有新版本发佈时，Deployment会同时操作两个版本的ReplicaSet ；
内置多种滚动升级策略，会按照既定策略降低老版本的Pod数量，同时也创建新版本的Pod ；
Deployment控制器不直接管理Pod对象，而是 Deployment 管理ReplicaSet, 再由ReplicaSet管理Pod对象；

总的来说，Deployment、ReplicaSet、Pod三者之间是一种阶梯控制的关系

1、Deployment 控制器配置模板样例




apiVersion: apps/v1



kind: Deployment



metadata:



  name: test-deploy



  namespace: default



spec:



  replicas: 2



  selector: 



    matchLabels:



      app: test-nginx-pod



  template:



    metadata:



      labels:



        app: test-nginx-pod



    spec:



      containers:



      - name: test-nginx



        image: nginx:1.23.0

在当前目录下创建一个yaml，拷贝上面的内容，然后执行 apply命令创建pod

kubectl apply -f

执行完成后，可以看到，上面创建了2个副本的pod

2、查看集群中的Deployment详细信息

kubectl get deploy -o wide -n default

结果参数说明：

NAME ： 列出了集群中 Deployment 的名称；
READY 显示应用程序的可用的“副本”数,格式是“就绪个数/期望个数” ；
UP-TO-DATE 显示为了达到期望状态已经更新的副本数；
AVAILABLE 显示可用的副本数；
AGE 应用程序运行的时间；

3、删除Deployment 的pod

通过apply创建的pod直接使用 delete -f 删除即可

kubectl delete -f

五、基于Deployment 使用rollout 实现滚动升级

滚动升级在日常的生产变更过程中可以说是非常常见的业务了，简单来说，滚动升级的目的就是为了保证在升级过程中不停服，减少因升级带来服务不可用造成的用户不好的产品体验；

通常，传统的滚动升级，一般是针对无状态的应用服务，而且是集群部署的那种，升级的时候，先通过一定的手段，控制集群中的部分节点服务先升级，然后再逐步完成全部节点的升级；

一般这个过程可以通过脚本控制，或者可视化操作界面手工来完成，在k8s中，Deployment这种控制器提供了一种很好的控制机制，基于rollout就可以完成服务的滚动升级；

1、Deployment控制器核心介绍

适合部署无状态的应用服务；
用来管理pod和replicaset ；
上线部署、副本控制、滚动更新、回滚等功能；

2、使用Deployment控制器滚动升级 (金丝雀发布 or 灰度发布）

对各个实例批次进行单独更新,而非同一时刻对所有实例进行全部更新，达到不中断服务的更新升级方式；
Deployment控制器给旧版本(old_rs)副本数减少至0、给新版本(new_rs)副本数量增至期望值(replicas) ；

3、Deployment 更新策略

对应于yaml中的核心配置参数




spec:



  strategy:  # 策略 RollingUpdate Recreate 




    type: RollingUpdate

策略1：Recreate

删除全部旧的pod，然后创建新的pod

策略2：RollingUpdate

滚动升级更新，删除部分，更新部分，在整个更新过程中，存在两个版本的pod

经验来讲，RollingUpdate实际应用场景更多，RollingUpdate根据业务需求的不同，又有下面两个重要的参数可供选择：

maxUnavailable

1、升级过程中不可用Pod的最大数量，默认为25%；
2、在滚动更新时，我们可以忍受多少个 Pod 无法提供服务；
3、值越小越能保证服务稳定,更新越平滑；

maxSurge

1、升级过程中可以超过期望的Pod的最大数量，默认为25%；
2、在滚动更新时，可以有多少个额外的 Pod；
3、值调的越大，副本更新速度越快；

4、yaml 模板配置样例

在当前目录下创建一个的文件，内容如下：




apiVersion: apps/v1



kind: Deployment



metadata:



  name: congge-deploy



  namespace: default



spec:



  replicas: 5



  revisionHistoryLimit: 5  #保留历史版本5个




  strategy: 



    type: RollingUpdate



  selector: 



    matchLabels:



      app: congge-nginx-pod



  template:



    metadata:



      labels:



        app: congge-nginx-pod



    spec:



      containers:



      - name: congge-nginx



        image: nginx:1.23.0

在当前的目录下执行命令

kubectl apply -f

执行后，可以看到一个5副本的pod就创建出来

5、查看控制器参数

使用下面的命令，可以查看上面控制器的详细描述信息

kubectl describe deploy congge-deploy -n default

关于图中展示的信息中的几点补充说明：

MaxUnavailable为0，在新 Pod 启动并就绪之前，不要关闭任何旧Pod；
MaxSurge 为100%, 立即启动所有新 Pod，也就是有足够的资源希望尽快完成更新，默认两个值都是 25%；
如果更新一个 100 Pod 的 Deployment，会立刻创建 25 个新 Old，同时会关闭 25 个旧 Pod；
每次有 Pod 启动就绪，就可以关闭旧 Pod；

6、实现滚动升级

在上面部署的nginx的版本为1.23.0，现在来实现一个需求，将现有的版本降至1.15.8，直接使用下面的命令：

kubectl set image deployment/congge-deploy congge-nginx=nginx:1.15.8 -n default

注意：命令里面的参数主要涉及到deploy的名称和一个container的名称，与上面的yaml中保持一致即可；

当前的状态

执行之后的状态，从状态上来看，有一个短暂的切换状态，并不是一下子就把所有现有的容器停止掉，而是一个很明显的中间状态，也就是滚动升级的过程；

稍等一会儿再看，这时候5个pod对应的nginx就全部完成了版本的降级；

补充参数说明：

可以在上面的命令行后面追加 --record 以保存正在更改资源的 kubectl 命令，方便查看history版本列表修改命令

kubectl set image deployment/congge-deploy congge-nginx=nginx:1.15.8 -n default --record=true

升级过程中，如果涉及到的pod非常多，也可以动态查看升级过程中存在的不同版本的pod

kubectl get pods -n dev -w

7、发布回滚

如果在升级之后发现问题，需要进行回退，就可以用上回退相关的操作命令了；

kubectl rollout 版本升级（回滚）相关参数介绍

history 升级（回滚）历史记录；
undo 默认回滚上一版本，使用--to-revision回滚到指定版本；
pause 暂停版本升级发布；
resume 继续恢复刚暂停的版本升级；
status 升级状态；

查看历史版本列表

kubectl rollout history deployment/congge-deploy -n default

这里会展示出版本回退的相关历史记录信息

查看具体某一个历史版本信息

kubectl rollout history deployment/congge-deploy -n default --revision=3

回滚到上一版本

kubectl rollout undo deployment/congge-deploy -n default

查看升级情况

kubectl rollout status deployment/congge-deploy -n default

回滚到指定版本

如果历史版本比较多的情况下，也可以根据实际需要回滚到某个指定的版本

kubectl rollout undo deployment/congge-deploy -n default --to-revision=3

删除deployment

kubectl delete -f

六、K8S控制器之DaemonSet控制器

在K8S集群部署中由于节点数量不定，那么如果我们需要对每个节点中都运行一个守护进程、日志收集进程等情况时，在k8s中如何实现呢？这个时候就是DaemonSet应用场景了

DaemonSet特点

这类Pod 运行在K8S 集群里的每一个节点（Node）上，确保所有节点上有且仅有一个pod ；
有新的节点加入 K8S集群后，该 Pod 会自动地在新节点上被创建出来；
而当旧节点被删除后，它上面的 Pod也相应地会被回收掉；
应用场景：监控告警Agent、日志组件、监控组件等；

daemonset 配置样例模板

在当前目录下创建一个的文件，配置如下：




apiVersion: apps/v1



kind: DaemonSet   



metadata:



  name: congge-ds



  namespace: default



spec:



  selector: 



    matchLabels:



      app: congge-nginx-pod



  template:



    metadata:



      labels:



        app: congge-nginx-pod



    spec:



      containers:



      - name: congge-nginx



        image: nginx:1.23.0



        imagePullPolicy: IfNotPresent

内容和上面的差不多，主要把kind那里调整下即可，执行apply命令创建pod，创建成功后，使用命令查看：

kubectl get pod,deploy,ds,rs -o wide -n default

可以看到，通过这种方式创建的pod，在其他节点上也会开启一个pod，类似于JVM中的守护进程；

七、K8S控制器之job控制器

job控制器是一种普通任务容器控制器，只会执行一次,只要完成任务就立即退出，不需要重启或重建；

job控制器特点

容器中的进程在正常运行结束后不会对其进行重启，而是将pod对象置于completed状态；
若容器中的进程因错误而终止，则需要依据配置确定是否需要重启；
启动pod在运行完毕任务后，就会变成Completed状态，job的状态会更新为complete，这个job任务已经执行完成，pod不在系统中继续运行；

应用场景：批处理程序，完成后容器就退出等

daemonset 核心配置参数说明




apiVersion: batch/v1



kind: Job



metadata:



  name: test-job



  namespace: default



spec:



  parallelism: 2 #job并发运行Pods的数量，默认 1




  completions: 3 #job需要成功运行Pods的次数,默认 1




  backoffLimit: 5 #job失败后进行重试的次数，默认是6




  activeDeadlineSeconds: 100 #job运行超时时间，当job超过timeout时间，则job的状态也会更新为failed




  template:



    spec:



      restartPolicy: Never #job重启策略，OnFailure或Never 




      containers:



      - name: demo



        image: busybox:1.35.0 



				# 容器的启动命令列表,在pod中的容器初始化完毕后运行命令




				command: ["echo","hello k8s job"]

BusyBox 参数补充说明：

是一个集成了三百多个最常用Linux命令和工具的软件；
包含了简单的工具，例如ls、cat和echo等等，还包含了一些更复杂的工具，例grep、find、telnet ；

daemonset 配置样例模板

在当前目录下创建一个的文件，配置内容如下：




apiVersion: batch/v1



kind: Job



metadata:



  name: test-job



spec:



  parallelism: 2



  completions: 3



  backoffLimit: 5



  activeDeadlineSeconds: 100



  template:



    spec:



      restartPolicy: Never



      containers:



      - name: demo



        image: busybox:1.35.0 



        command: ["echo","hello k8s job"]

使用apply命令执行创建pod；

查看创建的job

kubectl get job -n default -o wide

查看pod容器中的输出日志

在yaml中，容器那一栏里面输出了一段内容，可以查看下容器的日志看看是否输出了，选择其中一个job，执行下面的命令进行查看，发现内容成功输出了；

kubectl logs test-job-bl9n7

k8s中控制器使用详解

一、什么是控制器

二、k8s中常用的控制器

ReplicaSet

Deployment

DaemonSet

StatefulSet

Horizontal Pod Autoscaler

Job

Cronjob

三、k8s控制器之ReplicaSet

1、关于ReplicaSet特性

2、ReplicaSet控制器配置模板样例

3、使用ReplicaSet命令行进行缩容

4、删除rs创建的pod

四、k8s控制器之Deployment

1、Deployment 控制器配置模板样例

2、查看集群中的Deployment详细信息

3、删除Deployment 的pod

五、基于Deployment 使用rollout 实现滚动升级

1、Deployment控制器核心介绍

2、使用Deployment控制器滚动升级 (金丝雀发布 or 灰度发布）

3、Deployment 更新策略

4、yaml 模板配置样例

5、查看控制器参数

6、实现滚动升级

补充参数说明：

7、发布回滚

查看历史版本列表

查看具体某一个历史版本信息

回滚到上一版本

查看升级情况

回滚到指定版本

删除deployment

六、K8S控制器之DaemonSet控制器

DaemonSet特点

daemonset 配置样例模板

七、K8S控制器之job控制器

job控制器特点

daemonset 核心配置参数说明

daemonset 配置样例模板

查看创建的job

查看pod容器中的输出日志

相关文章