工作负载升级与回退

1. 登录CCE控制台，单击集群名称进入集群。
2. 在左侧导航栏中选择“工作负载”，在右上角单击“创建工作负载”。
3. 在“高级配置”的“升级策略”页签中，配置升级策略，具体参数说明请参见图1和表1。滚动升级与替换升级公共参数含义一致。
   图1 工作负载升级策略
   

   表1 工作负载升级策略

   参数	说明	限制
   最大无效实例数（maxUnavailable）	表示在滚动更新过程中，允许处于不可用状态的最大实例数量或比例，即实际运行Pod数可低于期望副本数的最大允许范围，默认为25%。实际升级过程中，比例会换算为绝对数，并向下取整。 例如spec.replicas为2，默认状态下最多有2*0.25=0个（向下取整）Pod失效，即实际运行Pod数不可低于期望副本数，系统中最少有2个Pod处于运行状态。换言之，在升级过程中，一直会有2个Pod处于运行状态，每次新建一个Pod，等这个Pod创建成功后再删掉一个旧Pod，直至Pod全部为新Pod。	仅Deployment、DaemonSet支持配置
   最大浪涌（maxSurge）	表示在滚动更新过程中，允许超出期望副本数的最大实例数或比例，即决定可以同时创建多少个新Pod替换旧Pod，默认值为25%。实际升级过程中，比例会换算为绝对数，并向上取整。 例如spec.replicas为2，默认状态下最多同时创建2*0.25=1个（向上取整）Pod，即系统中最多同时存在3个Pod。	仅Deployment、DaemonSet支持配置
   实例可用最短时间（minReadySeconds）	表示新创建的Pod在进入可用状态前，需持续保持就绪状态的最小时长。 该参数相当于引入了一个“稳定观察期”，可防止短暂就绪但不稳定的Pod过早参与服务，从而提升应用部署过程的稳定性和可靠性。	-
   最大保留版本数（revisionHistoryLimit）	表示在执行回退操作时，系统最多保留多少个旧版本的 ReplicaSet。这些旧ReplicaSet会占用etcd中的资源，并在执行kubectl get rs时显示在输出结果中。 每个Deployment的历史配置都会保存在对应的ReplicaSet中。因此，如果旧的ReplicaSet被删除，将无法回退至对应版本。系统默认保留最近的10个旧ReplicaSet，	-
   升级最大时长（progressDeadlineSeconds）	表示Deployment更新失败之前，允许的最长无进展时间，以秒为单位。如果指定，则此字段值需要大于minReadySeconds取值。 当Deployment在滚动更新过程中超过progressDeadlineSeconds且无进展时，其资源状态将反应为Type=Progressing、Status=False、Reason=ProgressDeadlineExceeded。这表示Deployment的更新被判定为失败，系统会记录相关事件，但不会自动回滚，需由用户手动干预或通过外部机制触发回退操作。	仅Deployment支持配置
   缩容时间窗（terminationGracePeriodSeconds）	表示Pod在被删除时，Kubelet给容器预留的最大终止等待时间，默认为30秒。容器应在这段时间内优雅退出，否则系统将会发送SIGKILL的系统信号强制终止。	-

4. 填写其他参数后，单击“创建工作负载”。等待一段时间后，工作负载状态将变为“运行中”。

以Deployment类型工作负载为例，展示如何配置工作负载升级策略。

1. 请参见通过kubectl连接集群，使用kubectl连接集群。
2. 创建一个名为nginx-deployment.yaml的文件。其中，nginx-deployment.yaml为自定义名称，您可以随意命名。

   vi nginx-deployment.yaml

   文件示例如下，关于Deployment配置的详细说明请参见Kubernetes官方文档。

   apiVersion: apps/v1
   kind: Deployment  
   metadata:
     name: nginx   
     namespace: default  
   spec:
     replicas: 2   
     selector:
       matchLabels:   
         app: nginx
     template:  
       metadata:
         labels:  
           app: nginx
       spec:
         containers:
         - image: nginx:latest    
           imagePullPolicy: Always  
           name: nginx  
           resources:  
             requests:  
               cpu: 250m
               memory: 512Mi
             limits:  
               cpu: 250m
               memory: 512Mi
         imagePullSecrets:  
         - name: default-secret  
         terminationGracePeriodSeconds: 30
     strategy:
       type: RollingUpdate # 表示滚动升级，Recreate表示替换升级
       rollingUpdate: # 用于配置滚动升级参数
         maxUnavailable: 25%
         maxSurge: 25%
     minReadySeconds: 0
     revisionHistoryLimit: 10
     progressDeadlineSeconds: 600

   表2 工作负载升级策略

   参数	说明	限制
   maxUnavailable	表示在滚动更新过程中，允许处于不可用状态的最大实例数量或比例，即实际运行Pod数可低于期望副本数的最大允许范围，默认为25%。实际升级过程中，比例会换算为绝对数，并向下取整。 例如spec.replicas为2，默认状态下最多有2*0.25=0个（向下取整）Pod失效，即实际运行Pod数不可低于期望副本数，系统中最少有2个Pod处于运行状态。换言之，在升级过程中，一直会有2个Pod处于运行状态，每次新建一个Pod，等这个Pod创建成功后再删掉一个旧Pod，直至Pod全部为新Pod。	仅滚动升级支持配置
   maxSurge	表示在滚动更新过程中，允许超出期望副本数的最大实例数或比例，即决定可以同时创建多少个新Pod替换旧Pod，默认值为25%。实际升级过程中，比例会换算为绝对数，并向上取整。 例如spec.replicas为2，默认状态下最多同时创建2*0.25=1个（向上取整）Pod，即系统中最多同时存在3个Pod。	仅滚动升级支持配置
   minReadySeconds	表示新创建的Pod在进入可用状态前，需持续保持就绪状态的最小时长。 该参数相当于引入了一个“稳定观察期”，可防止短暂就绪但不稳定的Pod过早参与服务，从而提升应用部署过程的稳定性和可靠性。	-
   revisionHistoryLimit	表示在执行回退操作时，系统最多保留多少个旧版本的 ReplicaSet。这些旧ReplicaSet会占用etcd中的资源，并在执行kubectl get rs时显示在输出结果中。 每个Deployment的历史配置都会保存在对应的ReplicaSet中。因此，如果旧的ReplicaSet被删除，将无法回退至对应版本。系统默认保留最近的10个旧ReplicaSet，	-
   progressDeadlineSeconds	表示Deployment更新失败之前，允许的最长无进展时间，以秒为单位。如果指定，则此字段值需要大于minReadySeconds取值。 当Deployment在滚动更新过程中超过progressDeadlineSeconds且无进展时，其资源状态将反应为Type=Progressing、Status=False、Reason=ProgressDeadlineExceeded。这表示Deployment的更新被判定为失败，系统会记录相关事件，但不会自动回滚，需由用户手动干预或通过外部机制触发回退操作。	-
   terminationGracePeriodSeconds	表示Pod在被删除时，Kubelet给容器预留的最大终止等待时间，默认为30秒。容器应在这段时间内优雅退出，否则系统将会发送SIGKILL的系统信号强制终止。	-

3. 执行以下命令，创建Deployment。

   kubectl create -f nginx-deployment.yaml

   回显如下表示已开始创建Deployment。

   deployment.apps/nginx created

4. 执行以下命令，查看Deployment状态。

   kubectl get deployment

   回显结果如下，则表示Deployment已创建成功。

   NAME           READY     UP-TO-DATE   AVAILABLE   AGE 
   nginx          2/2       2            2           4m5s

5. 执行以下命令，将上述工作负载的镜像改为nginx:alpine。

   kubectl edit deploy nginx

   请在spec.containers.image字段中修改镜像，修改完成后，保存并退出。

6. 执行以下命令，查看上述工作负载的副本情况。

   kubectl get rs

   回显结果如下：

   NAME               DESIRED   CURRENT   READY     AGE 
   nginx-6f9f58dffd   2         2         2         1m    # 新版本 ReplicaSet（活跃） 
   nginx-7f98958cdf   0         0         0         48m   # 旧版本 ReplicaSet（已停用）

   由于spec.replicas设置为2，且maxSurge和maxUnavailable均设置为25%，在实际升级过程中：

   • maxSurge = 1（2 × 25% = 0.5，向上取整为1）→ 最多允许新增1个额外Pod；
   • maxUnavailable = 0（2 × 25% = 0.5，向下取整为0）→ 不允许有不可用的Pod。

   因此，升级期间总Pod数最多为3个，且始终有2个可用Pod对外服务。CCE会采用“先创建新Pod、验证就绪后再删除旧Pod”的方式，逐个替换，直到全部升级完成。

7. 待升级完成后，执行以下命令，查看Pod状态。

   kubectl get pods

   回显结果如下，Pod的状态皆为Running，则说明升级成功。

   NAME                     READY     STATUS    RESTARTS   AGE
   nginx-6f9f58dffd-tdmqk   1/1       Running   0          1m
   nginx-6f9f58dffd-tesqr   1/1       Running   0          1m