Updated on 2025-07-17 GMT+08:00

CCE Cloud Bursting Engine for CCI

The bursting add-on functions as a virtual kubelet to connect Kubernetes clusters to APIs of other platforms. This add-on is mainly used to extend Kubernetes APIs to serverless container services such as Huawei Cloud CCI.

With this add-on, you can schedule Deployments, StatefulSets, jobs, and CronJobs running in CCE clusters to CCI during peak hours. In this way, you can reduce consumption caused by cluster scaling.

Constraints

  • Only CCE standard and CCE Turbo clusters that use the VPC network model are supported.
  • The CCE Burst Elastic Engine (CCI) add-on earlier than v1.5.37 cannot be used in clusters of the Arm architecture. The pods for the add-on will not be scheduled on Arm nodes, if any, running in the cluster.
  • The subnet where the cluster is located cannot overlap with 10.247.0.0/16, or the subnet conflicts with the Service CIDR block in the CCI namespace.
  • Currently, Volcano Scheduler of 1.17.10 or earlier cannot be used to schedule pods with cloud storage volumes mounted to CCI.
  • If the bursting add-on is used to schedule the pods to CCI 2.0, dedicated load balancers can be configured for ingresses and Services of the LoadBalancer type. The bursting add-on of a version earlier than 1.5.5 does not support Services of the LoadBalancer type.
  • DaemonSets are not supported.
  • Dynamic resource allocation is not supported, and related configurations are intercepted in plugin 1.5.27.
  • After the add-on is installed, a namespace named bursting-{Cluster ID} will be created in CCI and managed by the add-on. Do not use this namespace when manually creating pods in CCI.

Installing the Add-on

  1. Log in to the CCE console.
  2. Click the name of the target CCE cluster to go to the cluster Overview page.
  3. In the navigation pane, choose Add-ons.
  4. Select the CCE Cloud Bursting Engine for CCI add-on and click Install.
  5. Select the add-on version. The latest version is recommended.
  6. On the Install Add-on page, configure the specifications as needed.
    • If you select Preset, the system will configure the number of pods and resource quotas for the add-on based on the preset specifications. You can see the configurations on the console.
    • If you select Custom, you can adjust the number of pods and resource quotas as needed. High availability is not possible with a single pod. If there is an error on the node where the add-on pod runs, the add-on will not function.
      • The CCE Cloud Bursting Engine for CCI add-on of v1.5.2 or later uses more node resources. You need to reserve sufficient pods that can be created on a node before upgrading the add-on. For details about the number of pods that can be created on a node, see Maximum Number of Pods That Can Be Created on a Node.
      • The resource usages of the add-on vary depending on the workloads scaled to CCI. The resource requests and limits of the proxy, resource-syncer, and bursting-resource-syncer components are related to the maximum number of pods that can be scaled out. The resource requests and limits of the virtual-kubelet, bursting-virtual-kubelet, profile-controller, webhook, and bursting-webhook components are related to the maximum number of pods that can be created or deleted concurrently. For details about the recommended formulas for calculating the resource requests and limits of each component, see Table 1. P indicates the maximum number of pods that can be scaled out, and C indicates the maximum number of pods that can be created or deleted concurrently. You are advised to evaluate your service volume and select appropriate specifications.
      Table 1 Formulas for calculating resource requests and limits of each component

      Component

      CPU Request (m)

      CPU Limit (m)

      Memory Request (MiB)

      Memory Limit (MiB)

      virtual-kubelet/bursting-virtual-kubelet

      (C + 400)/2,400 × 1,000

      (C + 400)/600 × 1,000

      (C + 400)/2,400 × 1,024

      (C + 400)/300 × 1,024

      profile-controller

      (C + 1,000)/6,000 × 1,000

      (C + 400)/1,200 × 1,000

      (C + 1,000)/6,000 × 1,024

      (C + 400)/1,200 × 1,024

      proxy

      (P + 2,000)/12,000 × 1,000

      (P + 800)/2,400 × 1,000

      (P + 2,000)/12,000 × 1,024

      (P + 800)/2,400 × 1,024

      resource-syncer/bursting-resource-syncer

      (P + 800)/4,800 × 1,000

      (P + 800)/1,200 × 1,000

      (P + 800)/4,800 × 1,024

      (P + 800)/600 × 1,024

      webhook/bursting-webhook

      (C + 400)/2,400 × 1,000

      (C + 400)/600 × 1,000

      (C + 1,000)/6,000 × 1,024

      (C + 400)/1,200 × 1,024

    • (Optional) Networking: If this option is enabled, pods in the CCE cluster can communicate with pods in CCI through Services. The Proxy component will be automatically deployed upon add-on installation. For details, see Networking.
  7. Configure the add-on parameters.
    • Subnet: Pods running workloads scheduled to CCI use IP addresses in the selected subnet. Plan the CIDR block to ensure IP address provisioning is not impacted.
    • Enterprise Project: Select an enterprise project.
  8. Click Install.

Creating a Workload

  1. Log in to the CCE console.
  2. Click the name of the target CCE cluster to go to the cluster console.
  3. In the navigation pane, choose Workloads.
  4. Click Create Workload. For details, see Creating a Workload.
  5. Specify basic information. Select Force scheduling for Burst to CCI and then CCI 2.0 (bursting node) for CCI Resource Pool. For more information about scheduling policies, see Scheduling Workloads to CCI.

  6. Configure the container parameters.
  7. Click Create Workload.
  8. On the Workloads page, click the name of the created workload to go to the workload details page.
  9. View the node where the workload is running. If the workload is running on bursting-node, it has been scheduled to CCI.

Uninstalling the Add-on

  1. Log in to the CCE console.
  2. Click the name of the target CCE cluster to go to the cluster console.
  3. In the navigation pane, choose Add-ons.
  4. Select the CCE Cloud Bursting Engine for CCI add-on and click Uninstall.

    Table 2 Special scenarios for uninstalling the add-on

    Scenario

    Symptom

    Description

    There are no nodes in the CCE cluster that the CCE Cloud Bursting Engine for CCI add-on needs to be uninstalled from.

    Failed to uninstall the CCE Cloud Bursting Engine for CCI add-on.

    If the CCE Cloud Bursting Engine for CCI add-on is uninstalled from the cluster, a job for clearing resources will be started in the cluster. To ensure that the job can be started, there is at least one node in the cluster that can be scheduled.

    The CCE cluster is deleted, but the CCE Cloud Bursting Engine for CCI add-on is not uninstalled.

    There are residual resources in the namespace on CCI. If the resources are not free, additional expenditures will be generated.

    The cluster is deleted, but the resource clearing job is not executed. You can manually clear the namespace and residual resources.

    For more information about the add-on, see CCE Cloud Bursting Engine for CCI.

Change History

Table 3 Release history

Add-on Version

Supported Cluster Version

New Feature

1.5.44

v1.21

v1.23

v1.25

v1.27

v1.28

v1.29

v1.30

v1.31

v1.32

  • CCE clusters v1.32 are supported.
  • Supported automatic injection of sidecar containers.
  • Supported ARM64 nodes.

1.5.29

v1.21

v1.23

v1.25

v1.27

v1.28

v1.29

v1.30

v1.31

Specific subnets can be configured for pods.

1.5.28

v1.21

v1.23

v1.25

v1.27

v1.28

v1.29

v1.30

v1.31

Optimized some functions.

1.5.27

v1.21

v1.23

v1.25

v1.27

v1.28

v1.29

v1.30

v1.31

CCE clusters v1.31 are supported.

1.5.26

v1.21

v1.23

v1.25

v1.27

v1.28

v1.29

v1.30

Fixed some issues.

1.5.24

v1.21

v1.23

v1.25

v1.27

v1.28

v1.29

v1.30

Optimized some functions.

1.5.16

v1.21

v1.23

v1.25

v1.27

v1.28

v1.29

v1.30

Compacted pod CPU and memory resources.

1.5.8

v1.21

v1.23

v1.25

v1.27

v1.28

v1.29

CCE clusters v1.29 are supported.

1.3.57

v1.21

v1.23

v1.25

v1.27

v1.28

CCE clusters v1.28 are supported.

1.3.48

v1.21

v1.23

v1.25

v1.27

  • Clusters v1.25 and v1.27 are supported.
  • Supported JuiceFS.

1.3.25

v1.17

v1.19

v1.21

v1.23

  • Supports Downward API volumes.
  • Supports Projected volumes.
  • Supports custom StorageClass.

1.3.19

v1.17

v1.19

v1.21

v1.23

Supported schedule profile.

1.3.7

v1.17

v1.19

v1.21

v1.23

Clusters v1.21 and v1.23 are supported.

1.2.12

v1.13

v1.15

v1.17

v1.19

  • Adds some metrics.
  • Supports HPA and CustomedHPA.
  • Enables the hostPath in the pod that is scaled to CCI to be converted to other types of storage.
  • Fixes an issue that the Kubernetes dashboard cannot run on terminals.

1.2.5

v1.13

v1.15

v1.17

v1.19

  • Automatically cleared CCI resources that are no longer used by pods.
  • Requests and Limits can be set to different values. When CCI is scaled, the number of applied resources is subject to Limits.
  • Fixed the issue that the add-on fails to be uninstalled when the CCI namespace does not exist.
  • Added the function of intercepting creation requests when the pod specifications exceed the CCI limit.

1.2.0

v1.13

v1.15

v1.17

v1.19

  • Clusters v1.19 are supported.
  • Supported SFS and SFS Turbo storage.
  • Supported CronJobs.
  • Supported envFrom configuration.
  • Supported automatic logs dumping.
  • Shielded TCP socket health check.
  • Supported resource tags (pod-tag).
  • Improved performance and reliability.
  • Resolved some known issues.

1.0.5

v1.13

v1.15

v1.17

Clusters v1.17 are supported.