K8S之使用Deployment实现滚动更新

滚动更新简介

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

使用Deployment实现滚动更新

相关字段介绍

通过编写资源文件实现，涉及的字段如下：

kubectl explain deployment.spec
1

• paused：暂停，当我们更新的时候创建pod先暂停，不是立即更新
  （ps. 金丝雀发布 会使用到）
• strategy：更新策略，支持的滚动更新策略
• revisionHistoryLimit ： 保留的历史版本数，默认是10个。
  （ps. 需要回滚时使用，每更新镜像会产生一个版本，默认保留10个版本，回滚时可指定版本）

看更新策略

kubectl explain deploy.spec.strategy
1

更新的2种策略

• Recreate：重建式更新，删除一个pod更新一个 pod。
• RollingUpdate ：滚动更新，定义滚动更新的更新方式的，也就是pod能多几个，少几个，控制更新力度的

看RollingUpdate 滚动更新的配置

kubectl explain deploy.spec.strategy.rollingUpdate
1

• maxSurge：更新的过程当中最多允许超出的指定的目标副本数有几个
  它有两种取值方式，第一种直接给定数量，第二种根据百分比，百分比表示原本是5个，最多可以超出20%，那就允许多一个，最多可以超过40%，那就允许多两个
• maxUnavailable：最多允许几个不可用
  假设有5个副本，maxUnavailable = 1表示：最多一个不可用，就 最少有4个可用

测试滚动更新

观察滚动更新

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

vim deploy-demo.yaml 
1

编写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     # 容器里的应用的端口
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

更新资源清单文件

kubectl apply -f deploy-demo.yaml
1

在终端1下 执行如下：

kubectl get pods -l app=myapp -w
1

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

vim deploy-demo.yaml
1

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

保存退出，执行

kubectl apply -f deploy-demo.yaml 
1

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

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

在另外一个终端3 执行

kubectl get rs
1

显示如下：

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

查看历史版本

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

kubectl rollout history deployment myapp-v1 -n default
1

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

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

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

kubectl get pods -l app=myapp -w
1

发现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}}}}' 
1

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

kubectl describe deployment myapp-v1
1

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

使用Recreate更新策略

vim deploy-demo.yaml 
1

编写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     
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

更新资源清单文件

kubectl apply -f deploy-demo.yaml
1

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

kubectl get pods -l app=myapp -w
1

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

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