K8S之使用Deployment实现滚动更新

滚动更新

滚动更新简介
使用Deployment实现滚动更新
自定义滚动更新策略
- 自定义配置建议
- 实践自定义策略
- - [通过 RollingUpdateStrategy 字段来设置滚动更新策略](#通过 RollingUpdateStrategy 字段来设置滚动更新策略)
  - 使用Recreate更新策略

滚动更新简介

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

使用Deployment实现滚动更新

测试滚动更新

观察滚动更新

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

bash 复制代码

vim deploy-demo.yaml

编写Deployment资源文件

yaml 复制代码

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     # 容器里的应用的端口

更新资源清单文件

bash 复制代码

kubectl apply -f deploy-demo.yaml

在终端1下执行如下：

bash 复制代码

kubectl get pods -l app=myapp -w

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

bash 复制代码

vim deploy-demo.yaml

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

保存退出，执行

bash 复制代码

kubectl apply -f deploy-demo.yaml

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

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

在另外一个终端3 执行

bash 复制代码

kubectl get rs

显示如下：

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

查看历史版本

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

bash 复制代码

kubectl rollout history deployment myapp-v1 -n default

显示如下：每更新镜像会产生一个版本

回滚操作如下：

"--to-revision" 指定要回滚到的版本号

bash 复制代码

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

bash 复制代码

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

bash 复制代码

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

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

bash 复制代码

kubectl describe deployment myapp-v1

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

使用Recreate更新策略

bash 复制代码

vim deploy-demo.yaml

编写Deployment资源文件

yaml 复制代码

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

更新资源清单文件

bash 复制代码

kubectl apply -f deploy-demo.yaml

打开新的终端，看pod更新过程

bash 复制代码

kubectl get pods -l app=myapp -w

发现先都删除旧pod后再启动新的pod

总结：recreate这种更新策略，会把之前的所有pod都删除，再创建新的pod，风险很大

K8S之使用Deployment实现滚动更新

滚动更新

滚动更新简介

使用Deployment实现滚动更新

相关字段介绍

测试滚动更新

观察滚动更新

查看历史版本

自定义滚动更新策略

自定义配置建议

实践自定义策略

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

使用Recreate更新策略