Allowing the Number of Pods in the Cluster to Exceed the Limit During a Rolling Upgrade
During a rolling upgrade, CCI temporarily allows the number of pods on cluster nodes to exceed the preset maximum number in specific phases to ensure smooth services. This feature is only available during the upgrade. After the upgrade is complete, CCI automatically restores the number of replicas and scheduling policy you set to avoid affecting resource usages in the long run.
Constraints
Before using this feature, ensure that the following conditions are met:
- The SchedulingProfile is set to localPrefer, and the maximum number of local pods (local: maxNum) must be configured.
- The cluster has reserved sufficient resources for the pods that are temporarily added during the rolling upgrade, or the pods may be scheduled to CCI.
Process Principle

During the rolling upgrade, the new and old pods coexist due to the maxSurge setting, causing the number of pods to temporarily exceed the replicas value. During this period:
- The total number of pods associated with the ScheduleProfile will temporarily exceed the maximum number of local pods (local: maxNum).
- To ensure scheduling consistency, excess pods will not be scheduled to CCI and remain in the cluster.
- Retaining excess pods locally ensures that the number of pods distributed in the cluster and CCI before the rolling upgrade is the same as that after the rolling upgrade.
- After the rolling upgrade is complete, the number of pods in the cluster returns to the normal value and does not exceed the maximum number of local pods (local: maxNum).
Procedure
- Log in to the CCE console.
- Click the name of the target CCE cluster to go to the cluster Overview page.
- In the navigation pane, choose Add-ons.
- Select the CCE Cloud Bursting Engine for CCI add-on and click Edit.
- In the upper left corner, click Edit YAML.
- Set enableScheduleProfileLocalSurge to true and click OK.
enableScheduleProfileLocalSurge:true
Examples
- ScheduleProfile.yaml
apiVersion: scheduling.cci.io/v2 kind: ScheduleProfile metadata: name: test-local-profile namespace: test spec: objectLabels: matchLabels: app: whd-test strategy: localPrefer virtualNodes: - type: bursting-node location: local: maxNum: 10 # maxNum can be configured either for local or cci. scaleDownPriority: 2 cci: scaleDownPriority: 10 - Deployment YAML (rolling upgrade):
apiVersion: apps/v1 # Note the difference from that of pods. It is apps/v1 instead of v1 for Deployments. kind: Deployment # The resource type is Deployment. metadata: name: deploy-test # Name of the Deployment namespace: test spec: replicas: 10 # Number of pods. 10 pods are running for the Deployment. selector: # Label Selector matchLabels: app: deploy-test template: # Pod definition, which is used to create pods. It is also known as the pod template. metadata: labels: app: deploy-test spec: containers: - image: swr.cn-north-7.myhuaweicloud.com/cci-test/nginx:latest name: container-0 resources: requests: cpu: 200m memory: 200Mi imagePullSecrets: - name: default-secret strategy: type: RollingUpdate rollingUpdate: maxUnavailable: 35% maxSurge: 35%
Feedback
Was this page helpful?
Provide feedbackThank you very much for your feedback. We will continue working to improve the documentation.See the reply and handling status in My Cloud VOC.
For any further questions, feel free to contact us through the chatbot.
Chatbot