K8S之使用Deployment实现滚动更新

news2024/10/5 19:18:43

滚动更新

滚动更新简介
使用Deployment实现滚动更新
- 相关字段介绍
- 测试滚动更新
- - 观察滚动更新
  - 查看历史版本
自定义滚动更新策略
- 自定义配置建议
- 实践自定义策略
- - 通过 RollingUpdateStrategy 字段来设置滚动更新策略
  - 使用Recreate更新策略

滚动更新简介

滚动更新是一种自动化程度较高的发布方式，用户体验比较平滑，是目前成熟型技术组织所采用的主流发布方式，一次滚动发布一般由若干个批次组成，每批的数量一般是可以配置的（通过发布模板定义）。批次间可留观察间隔，通过手工验证或监控反馈确保没有问题再继续下一批次，所以总体上滚动式发布过程是比较缓慢的。

使用Deployment实现滚动更新

测试滚动更新

观察滚动更新

例子：用deployment先创建一个pod ，变更镜像再重新更新pod。观察

vim deploy-demo.yaml

编写Deployment资源文件

apiVersion: apps/v1  # deployment对应的api版本
kind: Deployment     # 创建的资源是deployment
metadata:
  name: myapp-v1    # deployment的名字
spec:
  replicas: 2     # deployment管理的pod副本数
  selector:       # 标签选择器
    matchLabels:  # 筛选定义的标签需要跟template.metadata.labels定义的标签一致
      app: myapp
      version: v1
  template:
    metadata:
      labels:    # Pod具有的标签
        app: myapp
        version: v1
    spec:   #定义容器的属性
      containers:  
      - name: myweb
        image: janakiramm/myapp:v1     # 容器使用的镜像
        imagePullPolicy: IfNotPresent  # 镜像拉取策略
        ports:
        - containerPort: 80     # 容器里的应用的端口

更新资源清单文件

kubectl apply -f deploy-demo.yaml

在终端1下执行如下：

kubectl get pods -l app=myapp -w

打开一个新的终端2窗口更改镜像版本，按如下操作：

vim deploy-demo.yaml

把 "image: janakiramm/myapp:v1 "变成 “image: janakiramm/myapp:v2”

保存退出，执行

kubectl apply -f deploy-demo.yaml

再回到终端1 监测的那个窗口，可以看到信息如下：

在这里插入图片描述

pending表示正在进行调度，ContainerCreating表示正在创建一个pod，running表示运行一个pod，running起来一个pod之后再Terminating一个pod，以此类推，直到所有pod完成滚动升级

在另外一个终端3 执行

kubectl get rs

显示如下：
在这里插入图片描述

上面可以看到rs有两个，下面那个是升级之前的，已经被停掉，但是可以随时回滚

查看历史版本

查看 myapp-v1 这个控制器的滚动历史

kubectl rollout history deployment myapp-v1 -n default

显示如下：每更新镜像会产生一个版本
在这里插入图片描述

回滚操作如下：
“–to-revision” 指定要回滚到的版本号

kubectl rollout undo deployment/myapp-v1 --to-revision=1 -n default

在这里插入图片描述

kubectl get pods -l app=myapp -w

发现runing状态的又回到了第一版
在这里插入图片描述

自定义滚动更新策略

自定义配置建议

maxSurge 和 maxUnavailable 用来控制滚动更新的更新策略

取值范围

填写整数类型的话，范围如下（ps. 两者不能同时为0）：
– maxUnavailable: 0 ~ replicas的值（副本数）
– maxSurge: 0 ~ replicas的值（副本数）
填写比例的话，范围如下（ps. 两者不能同时为0）：
– maxUnavailable: 0%~100%；（向下取整，比如10个副本，5%的话相当于 0.5个，但计算按照0个）
– maxSurge: 0%~100%；（向上取整，比如10个副本，5%的话相当于 0.5个，但计算按照1个）

建议配置
maxUnavailable 设置为 0
maxSurge 设置为 1
建议生产环境提供的默认配置。即 “一上一下，先上后下” 最平滑原则：1个新版本pod ready（结合readiness就绪性探测）后，才销毁旧版本pod。
此配置适用场景：平滑更新、保证服务平稳，但也有缺点，就是“太慢”了。

配置总结： maxUnavailable：和期望的副本数比，不可用副本数最大比例（或最大值），这个值越小，越能保证服务稳定，更新越平滑；
maxSurge：和期望的副本数比，超过期望副本数最大比例（或最大值），这个值调的越大，副本更新速度越快。

实践自定义策略

通过 RollingUpdateStrategy 字段来设置滚动更新策略

修改更新策略：maxUnavailable=1，maxSurge=1

kubectl patch deployment myapp-v1 -p '{"spec":{"strategy":{"rollingUpdate": {"maxSurge":1,"maxUnavailable":1}}}}'

查看myapp-v1这个控制器的详细信息

kubectl describe deployment myapp-v1

在这里插入图片描述

这个rollingUpdate更新策略变成了新设定的，因为创建deployment 时，设定的pod副本数是3，1 max unavailable表示：最少不能少于2个pod，1 max surge表示：最多不能超过4个pod

使用Recreate更新策略

vim deploy-demo.yaml

编写Deployment资源文件

apiVersion: apps/v1  
kind: Deployment     
metadata:
  name: myapp-v1    
spec:
  strategy:  # 使用更新策略类型为Recreate
    type: Recreate
  replicas: 2     
  selector:       
    matchLabels:  
      app: myapp
      version: v1
  template:
    metadata:
      labels:    
        app: myapp
        version: v1
    spec:   
      containers:  
      - name: myweb
        image: janakiramm/myapp:v2  # 变更镜像apply才更新生效     
        imagePullPolicy: IfNotPresent  
        ports:
        - containerPort: 80