跳转至

滚动更新简介

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

滚动更新

tomcat.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deployment
  annotations:
    kubernetes.io/change-cause: "部署 tomcat 10.1.18 版本，并保留5个历史版本"
spec:
  revisionHistoryLimit: 5  # 设置保留的历史记录数量为5个
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-container
        image: tomcat:10.1.18
        resources:
          requests:
            cpu: 200m
            memory: 200Mi
          limits:
            cpu: 500m
            memory: 500Mi
tomcat.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deployment
  annotations:
    kubernetes.io/change-cause: "tomcat 从 10.1.18 升级为 11.0.0，并保留5个历史版本"
spec:
  revisionHistoryLimit: 5  # 设置保留的历史记录数量为5个
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-container
        image: tomcat:11.0.0   # 修改为新镜像
        resources:
          requests:
            cpu: 200m
            memory: 200Mi
          limits:
            cpu: 500m
            memory: 500Mi

使用 kubectl 命令进行滚动更新：

kubectl apply -f tomcat.yaml 

--record选项用于记录更新操作，以便后续查看更新历史。 新版本已经废弃
Kubernetes将逐步更新Deployment中的Pod。它会先创建新的Pod副本，然后逐步停止旧的Pod副本，直到所有旧的Pod副本都被替换为新的副本。这样可以确保应用程序在更新过程中保持可用性。

你可以使用以下命令查看滚动更新的状态和进度

kubectl rollout status deployment my-deployment # 查看滚动更新的状态

kubectl rollout history deployment my-deployment # 查看滚动更新的历史记录。

如果需要回滚到先前的版本，可以使用以下命令：

kubectl rollout undo deployment my-deployment --to-revision=1

这将回滚到上一个版本，并逐步替换新版本的Pod副本为旧版本的副本。

这是一个基本的Pod滚动更新的示例。你可以根据需要进行更高级的配置，例如逐步更新策略、更新时间间隔等。滚动更新机制可以确保应用程序在更新过程中不间断地提供服务，并提供了灵活的方式来管理Deployment中的Pod版本。

image-20240117164436676

"自定义滚动更新策略"

更新类型

  • RollingUpdate 在滚动更新过程中，旧的 Pod 副本会逐步被新的 Pod 副本替换。（默认）
  • Recreate：在更新的时候、先删除所有的 pod，（不建议用）

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

  • maxUnavailable: [0,不可用副本数]
  • maxSurge: [0,超过期望副本数]
  • maxUnavailable: [0%,100%] 向下取整,比如 10 个副本,5% 的话 == 0.5 个,但计算按照 0 个;
  • maxSurge: [0%,100%] 向上取整,比如 10 个副本,5% 的话 == 0.5个,但计算按照 1 个;

注意: maxUnavailable maxSurge 两者不能同时为0。

  • maxUnavailable: 和期望的副本数比,不可用副本数最大比例到(或最大值),值越小,服务越稳定,更新越平滑;
  • maxSurge: 和期望的副本数比,超过期望副本数最大比例(或最大值),值越大,副本更新速度越快。

创建一个 Deployment 对象。

tomcat.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-deployment
spec:
  strategy:
    type: RollingUpdate           # 默认，在滚动更新过程中，旧的 Pod 副本会逐步被新的 Pod 副本替换。
    rollingUpdate:
      maxUnavailable: 1           # 最多允许一个Pod不可用（maxUnavailable: 1）
      maxSurge: 25%               # 允许超过当前副本数的 25%
  replicas: 3
  template:
    spec:
      containers:
        - name: myapp-container
          image: tomcat
tomcat.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-deployment
spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 0           # 允许所有Pod副本同时替换
      maxSurge: 3               # 允许最多三个Pod超过当前副本数
  replicas: 3
  template:
    spec:
      containers:
        - name: myapp-container
          image: tomcat

建议的配置

  • maxUnavailable = 10
  • maxSurge = 14

这是我们生产环境提供给用户的默认配置。即"一上一下,先上后下"最平滑原则:

1个新版本 pod ready (结合 readiness )后,才销毁旧版本 pod。此配置适用场景是平滑更新、保证服务平稳,但也有缺点,就是"太慢"了。