Help Center> Cloud Container Engine> User Guide> Clusters> Buying a Cluster> CCE Turbo Clusters and CCE Standard Clusters
Updated on 2024-03-11 GMT+08:00
View PDF

CCE Turbo Clusters and CCE Standard Clusters

Comparison Between CCE Turbo Clusters and CCE Standard Clusters

The following table lists the differences between CCE Turbo clusters and CCE standard clusters.

Category

Subcategory

CCE

CCE Turbo

Positioning

-

Standard clusters that provide highly reliable and secure containers for commercial use

Next-gen container cluster designed for Cloud Native 2.0, with accelerated computing, networking, and scheduling

Application scenario

-

For users who expect to use container clusters to manage applications, obtain elastic computing resources, and enable simplified management on computing, network, and storage resources

For users who have higher requirements on performance, resource utilization, and full-scenario coverage

Specification difference

Network model

Cloud-native network 1.0: applies to common, smaller-scale scenarios.

  • Tunnel network
  • Virtual Private Cloud (VPC) network

Cloud Native Network 2.0: applies to large-scale and high-performance scenarios.

Max networking scale: 2,000 nodes

Network performance

Overlays the VPC network with the container network, causing certain performance loss.

Flattens the VPC network and container network into one, achieving zero performance loss.

Network isolation
  • Tunnel network model: supports network policies for intra-cluster communications.
  • VPC network model: supports no isolation.

Associates pods with security groups. Unifies security isolation in and out the cluster via security groups' network policies.

Security isolation

Runs common containers, isolated by cgroups.
  • Physical machine: runs Kata containers, allowing VM-level isolation.
  • VM: runs common containers, isolated by cgroups.

Edge infrastructure management

None

Supports management of Intelligent EdgeSite (IES).

Performance on Batch Creating Pods in a CCE Turbo Cluster

Pods in a CCE Turbo cluster request elastic network interfaces (ENIs) or sub-ENIs from VPC. Currently, pods are bound with ENIs or sub-ENIs after pod scheduling is complete. The pod creation speed is constrained by how fast NICs are created and bound. The following table describes the constraints.

Table 1 ENI creation duration

Node Type

ENI Type

Maximum Number of Supported ENI

Binding ENI to Node

ENI Availability

Concurrency Control

Pre-Binding Configuration

ECS

Sub-ENI

256

Specify the ENI of the node to create a sub-ENI.

Within one second

Tenant-level: 600/minute

For clusters of versions earlier than 1.19.16-r2, 1.21.5-r0, or 1.23.3-r0, ENI pre-binding is not supported.

For clusters of versions between 1.19.16-r2, 1.21.5-r0, or 1.23.3-r0 and 1.19.16-r4, 1.21.7-r0, or 1.23.5-r0, dynamic ENI pre-binding is supported (nic-minimum-target=10; nic-warm-target=2).

For clusters of versions 1.23.5-r0 , 1.19.16-r4, 1.21.7-r0, or 1.25.1-r0 and their later versions, dynamic ENI pre-binding is supported (nic-minimum-target=10; nic-maximum-target=2; nic-warm-target=2; nic-max-above-warm-target=2).

BMS

ENI

128

Bind an ENI to a node.

20s-30s

Node-level: 3 concurrently

For clusters earlier than 1.19.16-r4, 1.21.7-r0, and 1.23.5-r0, the total number of ENIs is based on the threshold ratio (nic-threshold=0.3:0.6).

For clusters of 1.19.16-r4, 1.21.7-r0, 1.23.5-r0, 1.25.1-r0, or later, dynamic pre-binding is supported (nic-minimum-target=10; nic-maximum-target=2; nic-warm-target=2; nic-max-above-warm-target=2).

Creating Pods on ECS Nodes (Using Sub-ENIs)

  • If no pre-bound ENI is available on the node to which the pod is scheduled, the API for creating a sub-ENI is called to create a sub-ENI on an ENI of the node and allocate the sub-ENI to the pod.
  • If a pre-bound ENI is available on the node to which the pod is scheduled, the earliest unused sub-ENI is allocated to the pod.
  • Limited by the concurrent creation speed of sub-ENIs, a maximum of 600 pods can be created per minute without pre-binding. If a larger-scale creation is required, you can configure pre-binding for sub-ENIs.

Creating Pods on BMS Nodes (Using Sub-ENIs)

  • If no prebound ENI is available on the node to which the pod is scheduled, the API for binding an ENI to the node is called to bind and allocate an ENI to the pod. It takes about 20 to 30 seconds to bind an ENI to a BMS node.
  • If a pre-bound ENI is available on the node to which the pod is scheduled, the earliest unused ENI is allocated to the pod.
  • Limited by the speed of binding ENIs to BMS nodes, the startup speed of pods on the same node is 3/20 seconds without pre-binding. Therefore, you are advised to pre-bind ENIs for BMS nodes.
Parent topic: Buying a Cluster