Help Center/ Application Service Mesh/ Best Practices/ Istio-ingressgateway HA Configuration/ Gateway Workloads/ Rolling Upgrade Policy
Updated on 2024-09-24 GMT+08:00
View PDF
Share

Rolling Upgrade Policy

  1. Log in to the CCE Console console and click the cluster name to access the cluster console. In the navigation pane, choose Workloads. Then, locate the workload you want to upgrade and choose More > Edit YAML in the Operation column.
  2. Configure the following parameters in YAML: 

    spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 0
      maxSurge: 10%

    You can also click Upgrade in the Operation column of the workload to configure the parameters.

    Parameter description

    Parameter

    Description

    Max. Unavailable Pods (maxUnavailable)

    The maximum number or percentage of pods that can be deleted based on the value of spec.replicas. The recommended value is 0.

    For example, if spec.replicas is set to 3, there should be at least three pods during the upgrade.

    Max. Surge (maxSurge)

    The percentage of pods that are allowed based on the value of spec.replicas. The recommended value is 10.

    For example, if spec.replicas is set to 3, there should be a maximum of four pods during the upgrade, and 10% of pods can be added each time. During the upgrade, the value is converted into a number and rounded up. (10% of pods in this example is one pod.) So, you can also set this parameter to the maximum number of pods.

  • If only maxUnavailable and maxSurge are configured, the workload rolling upgrade will not be triggered. This means pods will not restart. The new values take effect in the next rolling upgrade.
  • When you redeploy a workload on the CCE console, you are performing a workload rolling upgrade. The workload version does not change.
Parent topic: Gateway Workloads