Help Center/ Cloud Container Instance (CCI)/ User Guide/ Using CCI Through the Console/ Workload Management/ Pods/ Pod Flavor/ Upgrading Pod Flavors
Updated on 2025-08-12 GMT+08:00
View PDF
Share

Upgrading Pod Flavors

For pods created on the CCI 2.0 console or using APIs, their flavors will be automatically upgraded based on the vCPUs and memory of containers to make full use of resources. This section describes how pod flavors are upgraded.
Table 1 Supported pod flavors

Container vCPUs

Container Memory (GiB)

0.25

0.5, 1, and 2

0.5

0.5, 1, 2, 3, and 4

1

1 to 8 (increment: 1 GiB)

2

2 to 16 (increment: 1 GiB)

4

4 to 32 (increment: 1 GiB)

8

8 to 64 (increment: 4 GiB)

16

16 to 128 (increment: 8 GiB)

32

32, 64, 128, and 256

48

96, 192, and 384

64

128, 256, and 512

There are two ways to specify pods flavors.

Method 1: Specifying the Memory and vCPUs for the Pod

  • Use the pod annotation resource.cci.io/pod-size-specs to specify the pod flavor. The specified pod flavor must be the same as one listed in Table 1, or the API for creating a pod returns an error message and refuses to create the pod. The value of resource.cci.io/pod-size-specs can be in the format of ${CPU}_${MEM}, for example, 2.00_4.0.
  • The total vCPUs and memory of containers in a pod cannot exceed the pod flavor specified by resource.cci.io/pod-size-specs, or the API for creating a pod returns an error message and refuses to create the pod.

Method 2: Specifying vCPUs and Memory of Containers

  • If the pod flavor is not specified, the memory and vCPUs required by the pod are calculated based on the total vCPUs and memory of containers in the pod. If the calculated result matches a flavor listed in Table 1, this flavor is used for the pod. If the calculated result does not match any listed flavor, it will be automatically upgraded to the next available flavor. Assume that the calculated result is 6 vCPUs and 15-GiB memory. The pod flavor will be automatically upgraded to 8 vCPUs and 16-GiB memory.
  • The pod flavor is calculated as follows:

    Pod flavor = max(max(sum(spec.Containers.Request), container.Limit), max(spec.initContainer))

    sum(spec.Containers.Request): total vCPU requests and memory requests of all containers

    max(sum(spec.Containers.Request), container.Limit): the larger values between the total requests and the limits of each container

    max(spec.initContainer): the larger values between vCPU requests and limits and the larger values between memory requests and limits

    max(max(sum(spec.Containers.Request), container.Limit), max(spec.initContainer resource value)): the larger values between container resource specifications and init container resource specifications

  • The rules for upgrading pod flavors as follows:

    The pod flavor is upgraded to the next available flavor, and the vCPUs and memory must not exceed those allowed in the pod flavor. If the pod flavor cannot be upgraded, the pod fails to be created.

    The upgraded pod flavor is included in the pod annotation: resource.cci.io/size=${cpuCeil}_${memoryCeil}.

    If the number of vCPUs is greater than 32, the pod flavor will not be upgraded. If the vCPUs of containers in the pod do not match any pod flavor in Table 1, the pod fails to be created. To upgrade the pod flavor to one with more than 32 vCPUs, set resource.cci.io/resizing-large-size-instance-greater-than-32-cores to true in the pod annotation.
    • If resource.cci.io/pod-size-specs is not set for the pod and requests and limits are not specified for all containers in the pod, an error message is returned, and the pod fails to be created.
    • The vCPUs and memory of each container must meet the Kubernetes validation requirements. If both requests and limits are specified, both requests and limits must be greater than or equal to 0, and the requests must be greater than or equal to the limits.
    • A maximum of 10 containers can be created for each pod. If you have special requirements, you can apply for removing this restriction.

Examples of Automatic Pod Flavor Upgrades

Table 2 Automatic upgrades

Scenario

Container Settings

Resource Requests or Limits

Upgraded Pod Flavor

Description

Single container, with only requests specified

 
containers:
  - resources:
      requests:
        cpu: '1.5'
        memory: 2Gi

1.5 vCPUs and 2 GiB of memory

2 vCPUs and 4 GiB of memory

The pod flavors are upgraded based on the requests.

Single container, with both requests and limits specified

 
containers:
  - resources:
      limits:
        cpu: '3.5'
      requests:
        cpu: '1.5'
        memory: 4.5Gi

3.5 vCPUs and 4.5 GiB of memory

4 vCPUs and 5 GiB of memory

The requests and limits are compared, and the larger values are used.

Multiple containers, with only requests specified

 
containers:
  - resources:
      requests:
        cpu: '1.5'
        memory: 2Gi
  - resources:
      requests:
        cpu: '1.5'
        memory: 2Gi

3 vCPUs and 4 GiB of memory

4 vCPUs and 4 GiB of memory

The sum of requests is used.

Multiple containers, with only limits specified

 
containers:
  - resources:
      limits:
        cpu: '1.5'
        memory: 2Gi
  - resources:
      limits:
        cpu: '1.5'
        memory: 2Gi

1.5 vCPUs and 2 GiB of memory

2 vCPUs and 4 GiB of memory

The maximum limit is used.

Multiple containers, with both requests and limits specified

 
containers:
  - resources:
      limits:
        cpu: '5'
        memory: 8Gi
      requests:
        cpu: '1.5'
        memory: 2Gi
  - resources:
      requests:
        cpu: '1.5'
        memory: 2Gi

5 vCPUs and 8 GiB of memory

8 vCPUs and 8 GiB of memory

The requests and limits are compared, and the larger values are used.

Containers + init containers, with a large number of container resources

 
initContainers:
  - resources:
      requests:
        cpu: '1.5'
        memory: 2Gi
containers:
  - resources:
      requests:
        cpu: '3'
        memory: 4Gi

3 vCPUs and 4 GiB of memory

4 vCPUs and 4 GiB of memory

The requests and limits of containers are compared with those of init containers, and the larger values are used.

Containers + init containers, with a large number of init container resources

 
initContainers:
  - resources:
      requests:
        cpu: '5'
        memory: 8Gi
  - resources:
      requests:
        cpu: '6'
        memory: 9Gi
containers:
  - resources:
      requests:
        cpu: '3'
        memory: 4Gi

6 vCPUs and 9 GiB of memory

8 vCPUs and 12 GiB of memory

The requests and limits of containers are compared with those of init containers, and the larger values are used.

Resource requests, same as those in the flavor

 
containers:
  - resources:
      requests:
        cpu: '48'
        memory: 96Gi

48 vCPUs and 96 GiB of memory

48 vCPUs and 96 GiB of memory

There is no need to upgrade to the flavor.

Upgrading to 32 vCPUs

 
containers:
  - resources:
      requests:
        cpu: '31'
        memory: 32Gi

31 vCPUs and 32 GiB of memory

32 vCPUs and 32 GiB of memory

Fewer than 32 vCPUs after the upgrade

More than 32 vCPUs after the upgrade

 
containers:
  - resources:
      requests:
        cpu: '33'
        memory: 96Gi

33 vCPUs and 96 GiB of memory

No matched flavor

If the vCPU request is more than 32 vCPUs, no upgrade is performed.

More than 32 vCPUs, and upgrading to a large flavor allowed

 
annotations:
  "resource.cci.io/resizing-large-size-instance-greater-than-32-cores": "true"
containers:
  - resources:
      requests:
        cpu: '33'
        memory: 96Gi

33 vCPUs and 96 GiB of memory

48 vCPUs and 96 GiB of memory

Upgrading to a large flavor is allowed.

When a workload pod that has multiple containers is scheduled from CCE to CCI 2.0 and only limits are set for the containers, the pod creation complies with the default Kubernetes resource configuration rule as follows:

If only limits are specified, requests that have the same values as limits will be automatically specified.

Take a Deployment created on the CCE console as an example. The spec.template file of the Deployment contains two containers, and only limits are set for each container. After a pod is created, the requests of each container are specified and equal to the limits.

The pod flavor may be greater than expected. You can manually specify the requests for the containers to avoid this issue.

Parent topic: Pod Flavor