0


【云原生kubernetes】k8s控制器Deployment使用详解

前言

在上一篇我们聊了k8s中各种控制器的使用,本篇将以控制器中比较常用的一种控制器Deployment 进行详细的说明。

一、Deployment 简介

为了更好解决服务编排的问题,kubernetes在V1.2版本开始,引入了Deployment控制器;

需要说明的是,Deployment控制器并不直接管理pod,而是通过管理ReplicaSet来简介管理Pod,即:Deployment管理ReplicaSet,ReplicaSet管理Pod,所以Deployment比ReplicaSet功能更加强大。

二、Deployment 功能

Deployment主要功能如下:

  • 支持ReplicaSet的所有功能;
  • 支持发布的停止、继续;
  • 支持滚动升级和回滚版本;

三、Deployment 配置文件核心参数说明

如下为Deployment配置模板文件中的部分参数,结合备注进行理解

apiVersion: apps/v1 # 版本号
kind: Deployment # 类型       
metadata: # 元数据
  name: # rs名称 
  namespace: # 所属命名空间 
  labels: #标签
    controller: deploy
spec: # 详情描述
  replicas: 3 # 副本数量
  revisionHistoryLimit: 3 # 保留历史版本
  paused: false # 暂停部署,默认是false
  progressDeadlineSeconds: 600 # 部署超时时间(s),默认是600
  strategy: # 策略
    type: RollingUpdate # 滚动更新策略
    rollingUpdate: # 滚动更新
      max违规词汇: 30% # 最大额外可以存在的副本数,可以为百分比,也可以为整数
      maxUnavailable: 30% # 最大不可用状态的 Pod 的最大值,可以为百分比,也可以为整数
  selector: # 选择器,通过它指定该控制器管理哪些pod
    matchLabels:      # Labels匹配规则
      app: nginx-pod
    matchExpressions: # Expressions匹配规则
      - {key: app, operator: In, values: [nginx-pod]}
  template: # 模板,当副本数量不足时,会根据下面的模板创建pod副本
    metadata:
      labels:
        app: nginx-pod
    spec:
      containers:
      - name: nginx
        image: nginx:1.17.1
        ports:
        - containerPort: 80

Deployment 操作演示

在当前目录下创建deployment-ep.yaml配置文件,内容如下:

apiVersion: apps/v1
kind: Deployment      
metadata:
  name: deployment-eam
  namespace: default
spec: 
  replicas: 3
  selector:
    matchLabels:
      app: nginx-pod
  template:
    metadata:
      labels:
        app: nginx-pod
    spec:
      containers:
      - name: nginx
        image: nginx:1.17.1

执行下面的命令进行deployment和pod的创建

kubectl create -f deployment-ep.yaml

上述结果参数说明

  • UP-TO-DATE 最新版本的pod的数量;
  • AVAILABLE 当前可用的pod的数量

通过查看rs与pod的信息,再次印证了本文开篇的时候 deployment,rs以及与pod的对应关系;

三、Deployment 扩缩容

在实际生产中,随着业务量上升或下降,有必要对运行中Pod数量进行扩缩容,从而达到合理的利用机器的资源的目的;

使用Deployment 进行扩容或缩容比较简单,可以通过命令的方式直接变更,或修改yaml的形式;

使用命令行操作

在上面的操作中,通过Deployment创建了3个Pod;

变更副本数量为5个

kubectl scale deploy deployment-eam --replicas=5  -n default

执行之后,可以看到此时当前的Deployment下面就有5个Pod了;

在线编辑Deployemnt配置文件

使用下面的命令在线编辑Deployment配置文件进行修改

kubectl edit deploy deployment-eam -n default

找到下面这个地方,将其修改为3

保持退出之后,查看Pod可以看到此时Pod的数量就发生了变化

四、Deployment 升级策略

deployment支持两种更新策略:重建更新,滚动更新;

重建更新:旧的Pod直接删掉,然后创建新的;

滚动更新:一边删除旧版本Pod,同时再创建新版本的Pod(整个过程中,新老版本并存);

更新策略可以通过strategy指定策略类型,支持两个属性,配置选项如下:

strategy:指定新的Pod替换旧的Pod的策略, 支持两个属性:
type:指定策略类型,支持两种策略
Recreate:在创建出新的Pod之前会先杀掉所有已存在的Pod
RollingUpdate:滚动更新,就是杀死一部分,就启动一部分,在更新过程中,存在两个版本Pod
rollingUpdate:当type为RollingUpdate时生效,用于为RollingUpdate设置参数,支持两个属性:
maxUnavailable:用来指定在升级过程中不可用Pod的最大数量,默认为25%
max违规词汇: 用来指定在升级过程中可以超过期望的Pod的最大数量,默认为25%

重建更新策略操作演示

1)在配置文添加如下配置参数

2)启动Pod

kubectl apply -f deployment-ep.yaml

3)开启另一个窗口,监测当前Pod的变动情况

目前可以看到有3个Pod处于运行中;

4)更新镜像

使用下面的命令对镜像进行更新

kubectl set image deploy 上面的deployment名称 nginx=nginx:1.17.2 -n default

执行上述命令之后,通过监测窗口的输出变化信息,很明显,这种更新策略,就是按照先干掉老的Pod再创建新Pod的过程完成镜像的更新;

滚动更新策略操作演示

将配置更新策略的位置修改为滚动更新

删除上面的deployment,然后重新创建deployment

再次进行镜像更新

kubectl set image deploy 上面的deployment名称 nginx=nginx:1.17.3 -n default

通过另一个窗口监测Pod的信息变化,从下图中展示的STATUS的变化,不难发现,整个过程中,之前正在运行中的Pod和新的Pod是一个你来我往的交替的过程,简单来说,就是一边开启新的Pod,一边停止老的Pod,直到新的Pod全部更新完成为止;

五、Deployment 实现版本回退

版本回退这个概念对于很多使用过docker部署微服务的同学来说并不陌生,在使用docker部署微服务的时候,只需要给制作好的镜像打上版本标签,如果最新的版本上线有严重的bug,只需快速找到某个标签版本的镜像就可以快速完成版本的回退;

从上面的这张图可以了解到,Deployment是通过控制res来达到控制Pod的目的,在上述演示升级策略的过程中,我们通过另一个窗口监测到了Deployment和Pod的变化情况,对于Deployment,如果要实现版本回退该怎么做呢?

在创建Deployment过程中,通过指定 record 可以记录本次的版本信息

接下来通过实际操作,演示下record在版本回退中的作用;

1、创建Deployment并使用record

kubectl create -f deployment.yaml --record=true

也可以具体的查看下rs的详细信息,此时运行着如下这个rs,可以记住其尾号为:4f89;

2、执行镜像更新

kubectl set image deploy deployment名称 nginx=nginx:1.17.3 -n default

deployment信息

rs 信息

从rs的变化过程来看,对于4f89 ,即之前的rs来说,其下面挂着3个Pod,随着执行镜像更新策略,之前的Pod在不断的停止,所以从rs的信息来看,4f89下面的Pod数量逐渐减少;

同时,产生了一个新的尾号为8b8c的rs,随着时间的推移,这个rs下面的Pod数量从1开始,直到增加到3个,这么来看就容易理解了,简而言之:

带有record参数的镜像更新的过程中,老的rs下面的Pod逐渐减少并销毁,新产生的rs下的Pod逐渐增加,最后停止之前的rs;

用一张图来看,整个过程的经历,大概长下面这样

等待跟新的过程完成之后再次查看rs的信息,可以看到集群中老的rs下已经没有Pod了;

为什么k8s并没有将这个老的rs一起删掉呢?因为这个rs就是后面用于版本回退使用的

3、版本回退

deployment支持版本升级过程中的暂停、继续功能以及版本回退等诸多功能,即:kubectl rollout,支持下面的选项:

  • status 显示当前升级状态;
  • history 显示 升级历史记录;
  • pause 暂停版本升级过程;
  • resume 继续已经暂停的版本升级过程;
  • restart 重启版本升级过程;
  • undo 回滚到上一级版本(可以使用--to-revision回滚到指定版本);

基于上面演示使用的Pod,使用rollout进行版本回退

查看当前升级版本的状态

kubectl rollout status deploy deployment名称 -n default

查看升级历史记录

kubectl rollout history deploy deployment名称 -n default

此时如果再升级一个版本,然后再看看升级历史记录信息,可以看到此时的最大版本号来到3;

此时,查看rs的信息也能发现,升级到最新的那个rs下面挂着3个Pod;

执行版本回退

kubectl rollout undo deployment pc-deployment --to-revision=1 -n default

执行完成后,再次查看rs的信息,不难发现这时候集群中的Pod重新挂在第一次创建的那个rs下面了;

关于回退参数说明

  • --to-revision=1回滚到了1版本,版本号可以自己指定,即你想回退到的某个历史版本号;
  • 如果省略这个选项,就回退到上个版本,即上图中的3个版本的第二个版本(当前版本为3)

六、Deployment 实现金丝雀发布

在生产环境的版本变更中,金丝雀发布这个概念,对很多同学来说并不陌生,一种典型的应用场景就是,整个发布过程中,新旧版本同时存在,这样一部分流量打到新服务,一部分服务仍然打到老的服务,这样在确保整体服务的可用性同时,还能让一部分用户体验新功能的目的;

在上面的版本回退相关的参数中,还有pause和resume这两个参数没有提到,Deployment控制器支持控制更新过程中的控制,如“暂停(pause)”或“继续(resume)”更新操作。

Deployment中的金丝雀发布可以如下理解;

例如,有一批新的Pod资源创建完成后立即暂停更新过程,此时,仅存在一部分新版本的应用,主体部分还是旧的版本。然后,再筛选一小部分的用户请求路由到新版本的Pod应用,继续观察能否稳定地按期望的方式运行。确定没问题之后再继续完成余下的Pod资源滚动更新,否则立即回滚更新操作,这就是所谓的金丝雀发布。

操作演示

更新deployment版本,并配置暂停deployment

kubectl set image deploy deployment名称 nginx=nginx:1.17.4 -n default && kubectl rollout pause deployment deployment名称 -n default

该命令的意思可以理解为升级当前的Pod-nginx版本为1.17.4,升级过程中,立即使用pause暂停版本升级过程,执行上面的命令观察效果;

查看rs变化

从rs的信息展示来看,执行命令之后,集群中同时存在两个rs,一个rs下面挂了3个Pod,另一个rs里面挂了一个Pod,不难理解,上面的命令前半部分执行没多久,老的Pod还来不及停止,新的Pod还没有完全创建完成就被Pause了;

查看更新状态

kubectl rollout status deploy deployment名称 -n default

这段信息意思大概是:等待当前的deployment更新,新的rs中,3个Pod中有1个Pod得到了更新;

确保更新的pod没问题之后,继续更新

kubectl rollout resume deploy deployment名称 -n default

观察rs的变化情况

观察更新状态的变化信息,不难理解,其反应的状态正好就是老的Pod停止,而新的rs下面的Pod更新的过程;


本文转载自: https://blog.csdn.net/zhangcongyi420/article/details/128554738
版权归原作者 小码农叔叔 所有, 如有侵权,请联系我们删除。

“【云原生kubernetes】k8s控制器Deployment使用详解”的评论:

还没有评论