Deployment更新策略

在Kubernetes中,Deployment的更新策略主要有两种:

  1. 滚动更新(Rolling Update)
  • 这是Kubernetes Deployment 的默认更新策略。
  • 在滚动更新过程中,Deployment 控制器会逐步地将新版本的Pod逐个替换旧版本的Pod。这个过程会确保在升级过程中始终有一定数量的可用Pod服务于客户端请求,从而实现平滑的服务过渡。
  • 滚动更新有两个重要的参数:maxUnavailable 和 maxSurgemaxUnavailable 用于指定在滚动更新过程中允许的最大不可用Pod数或百分比;而 maxSurge 用于指定在滚动更新过程中可以超出期望副本数的最大Pod数或百分比。
  • 滚动更新特别适用于需要确保服务持续可用的场景。
  1. 重建更新(Recreate)
  • 当 .spec.strategy.type 设置为 Recreate 时,Deployment 将采取这种策略。
  • 使用此策略时,Deployment 会先停止所有旧的Pod副本,等到所有旧副本都终止后,再一次性创建出新的Pod副本。
  • 这种策略会导致应用程序的短暂中断,因为在删除旧副本和创建新副本之间存在时间差。
  • 重建更新适用于无状态应用程序或可以容忍短暂中断的应用程序。


Pod数量的控制

在Kubernetes中,当使用滚动更新(RollingUpdate)策略时,可以通过设置maxSurgemaxUnavailable参数来控制Pod的启动与关闭数量。

  1. maxSurge: 这个参数决定了在滚动更新过程中,可以超出期望副本数的最大Pod数。它可以是一个整数(表示Pod的绝对数量)或一个百分比(表示相对于期望副本数的百分比)。当设置为百分比时,它默认是期望Pod数量的25%。如果设置为整数,比如maxSurge: 1,那么滚动更新过程中,最多可以比期望的副本数多一个Pod。
  2. maxUnavailable: 这个参数决定了在滚动更新过程中,可以处于不可用状态的最大Pod数。同样,它也可以是一个整数或百分比。当设置为百分比时,它表示相对于期望副本数的百分比。例如,如果设置为maxUnavailable: 25%,那么在任何时候,最多只能有25%的Pod处于不可用状态。

以下是一个设置滚动更新策略的示例YAML配置:

apiVersion: apps/v1
kind: Deployment
metadata:
    name: pyapp-deploy
spec:
    strategy:  
        type: RollingUpdate  
        rollingUpdate:  
            maxSurge: 25%  # 或者设置为一个整数,如 maxSurge: 1  
            maxUnavailable: 25%  # 或者设置为一个整数,如 maxUnavailable: 1
    replicas: 3
    selector:
        matchLabels:
            app: pyapp
    template:
        metadata:
            labels:
                app: pyapp
        spec:
            imagePullSecrets:
              - name: harbor-admin
            containers:
            - name: pyapp-pod
              image: harbor.tangotz.com/pyapp/pyapp:v1
              ports:
              - containerPort: 5000

在上面的示例中,滚动更新策略被设置为允许最多比期望的副本数多25%的Pod,并且在任何时候最多只能有25%的Pod处于不可用状态。你可以根据自己的需要调整这些值。

需要注意的是,maxSurgemaxUnavailable是相互影响的。如果同时设置了两者,并且它们的值使得在滚动更新的任何阶段都无法满足(例如,如果maxUnavailable设置得太高,而maxSurge设置得太低),那么滚动更新可能会失败。因此,在设置这两个参数时,需要确保它们的值是合理的并且相互兼容的。


触发更新

触发更新有两种方式:

通过kubectl set

kubectl set image deployment/pyapp-deploy ^Capp=harbor.tangotz.com/pyapp/pyapp:v2


通过资源清单

直接编辑资源清单并执行kubectl apply -f 资源清单文件


查看历史记录

使用命令

kubectl rollout history deployment/<deployment-name>

可以查看更新记录

从0开始搞K8S:控制器 Deployment 更新策略_滚动更新

从记录上看CHANGE-CAUSE为<none>,这个值没有设么意义,可以通过命令来记录

kubectl annotate deployment/<deployment-name> kubernetes.io/change-cause="xxxx"

从0开始搞K8S:控制器 Deployment 更新策略_Deployment_02

同样也可以用资源描述文件来记录变更。变更记录在metadate.annotations.kubernetes.io/change-cause

从0开始搞K8S:控制器 Deployment 更新策略_滚动更新_03

效果相同

从0开始搞K8S:控制器 Deployment 更新策略_滚动更新_04

更新回滚

使用kubectl rollout undo 并指定 --to-revision来进行回滚

从0开始搞K8S:控制器 Deployment 更新策略_Deployment_05