Cluster Overview

Cloud Container Engine (CCE) is a Kubernetes cluster hosting service for enterprises. It manages the entire lifecycle of containerized applications and delivers scalable, high-performance solutions for deploying and managing cloud native applications.

Cluster Types

CCE standard clusters are for commercial use. They fully support the standard features of open-source Kubernetes clusters. Management and O&M of master nodes are not necessary. Depending on the service scenarios, you can choose to use either the container tunnel network model or the VPC network model. This cluster type is suitable for general scenarios without specific performance or scale requirements.
CCE Turbo clusters run on the Cloud Native 2.0 infrastructure. They feature hardware and software synergy, zero network performance loss, high security and reliability, and intelligent scheduling, offering you a one-stop, cost-effective container service. The Cloud Native 2.0 networks are available for large-scale, high-performance scenarios. In CCE Turbo clusters, pod IP addresses are assigned from VPC CIDR blocks, and pods and nodes can be in different subnets. External networks in the VPC can directly access pod IP addresses for high performance.
CCE Autopilot allows you to create serverless clusters with optimized Kubernetes support, freeing you from time-consuming O&M tasks. You are relieved from deployment, node management, and security configurations. Your costs are now calculated based on actual CPU and memory usage.

For details about the differences between these clusters, see Comparison Between Cluster Types.

Core Features

Feature	Description
Cluster management	Cluster creation: You can create clusters of various types, choose from multiple scales, and adjust resources as needed to meet changing service demands quickly, efficiently, and cost-effectively. For details, see Buying a Cluster. Cluster upgrade: You can upgrade your clusters to the latest Kubernetes version to leverage new features, enhance system stability, and boost performance. For details, see Upgrading a Cluster.
Node or node pool management	Heterogeneous resource management: available across various Huawei Cloud computing instances, including VMs, BMSs, Kunpeng instances, Ascend computing, and GPU-based instances. For details, see Node Overview and Node Pool Overview. Flexible configuration: Node pools can be flexibly configured. You can mix nodes of different specifications and billing types within one pool, and customize Kubernetes settings to suit various needs. Auto scaling: Nodes can be automatically scaled for efficient resource management and quick response to changes in load, maximizing resource usage while minimizing costs. For details, see Node Scaling.
Workload management	Workload lifecycle management: handles every stage of multiple workloads, from creation to upgrade and rollback. It also supports various configurations like environment settings, persistent storage, and logging for applications. For details, see Workload Overview. Affinity scheduling: Node affinity scheduling and workload affinity/anti-affinity scheduling are available to meet scheduling needs in different scenarios. For details, see Overview. Auto scaling: Multiple workload scaling policies such as HPA, CronHPA, and CustomedHPA are available. For details, see Workload Scaling. Release: Grayscale release and blue-green deployment are available in multiple access modes to maintain high availability and stability during updates and migrations.
Scheduling	Heterogeneous resource scheduling GPU: GPU instances with comprehensive ecosystem compatibility can serve as worker nodes in a cluster, enabling full lifecycle management through GPU scheduling, monitoring, and auto scaling. For details, see GPU Scheduling. GPU virtualization: GPU memory and computing resources can be dynamically allocated. This allows multiple containers to run on a single GPU instance, with each container isolated from others for improved GPU utilization. For details, see GPU Virtualization. NPU: NPU instances can serve as worker nodes in a cluster, enabling NPU scheduling, monitoring, auto scaling, and maintenance operations. For details, see Complete NPU Allocation. Advanced scheduling policies: CCE uses Volcano to offer several advanced scheduling policies that enhance application performance and improve cluster resource utilization, including bin packing, descheduling, load-aware scheduling, priority-based scheduling and preemption, DRF, Gang, NUMA affinity scheduling, and hybrid deployment of online and offline services.
Network	Container network: CCE clusters support the following network models: VPC, tunnel, and Cloud Native network 2.0. Each model offers unique features and benefits for various deployment scenarios. For details, see Overview. Service: ClusterIP, NodePort, LoadBalancer, and DNAT Services are provided. For details, see Service Overview. Ingress: LoadBalancer and Nginx ingresses are provided. For details, see Ingress Overview. DNS: Cluster domain name resolution is provided. For details, see DNS Overview.
Storage	Storage add-on: CSI is supported. CCE Container Storage (Everest) is a CCE storage add-on developed based on CSI. It provides different types of persistent storage for containers. StorageClass: EVS, SFS, SFS Turbo, OBS, DSS, local PV, and EV are provided. For details, see Storage Overview.
Auto scaling	Workload scaling: The number of workload pods can be adjusted based on service requirements and policies. For details, see Workload Scaling Rules. Node scaling: The number of nodes in a cluster can be automatically adjusted as needed to match changing service demands, freeing up underutilized resources and reducing waste. For details, see Node Scaling Rules.
Cloud Native Observability	Health Center: diagnoses cluster health, detects faults, and identifies risks. It then provides recommendations for resolving these issues. For details, see Overview. Monitoring Center: monitors resources across various levels, including clusters, nodes, workloads, and pods, with support for custom cluster monitoring based on Prometheus. For details, see Overview. Logging: collects, stores, and displays cluster and application logs on demand to aid in troubleshooting issues. For details, see Overview. Alarm Center: allows for fast alarm searching and configuring within a cluster. Common alarm rules can be configured with just one click using the Alarm Center. For details, see Overview.
Cloud Native Cost Governance	IT teams can view cost and resource usage by department, cluster, or namespace. They can also use methods like workload resource recommendations to optimize cluster efficiency and lower costs. For details, see Overview.
Permissions management	IAM authorization and RBAC-based namespace authorization are supported. For details, see Permissions Overview. IAM authorization manages access to cloud services, including CCE clusters and associated resources like VPC, ELB, and ECS resources. RBAC-based namespace authorization manages access to cluster resources, such as creating workloads in a cluster. However, for the cluster resources such as nodes and load balancers that are dependent on external cloud services, the IAM authorization of the respective cloud service applies.

Cluster Network

A cluster network can be divided into three network types:

Node network: IP addresses are assigned to nodes in a cluster.
Container network: IP addresses are assigned to containers in a cluster for communication. Currently, multiple container network models are supported, and each model has its own working mechanism.
Service network: A Service is a Kubernetes object used to access containers. Each Service has a static IP address.

When you create a cluster, select a proper CIDR block for each network. Ensure that the CIDR blocks do not conflict with each other and have sufficient available IP addresses. You cannot change the container network model after the cluster is created. Plan the container network model properly in advance.

You are advised to learn about the cluster network and container network models before creating a cluster. For details, see Container Networks.

Number of Master Nodes in a Cluster and Cluster Scale

In a CCE cluster, the number of master nodes does not determine the cluster scale. These are two different aspects of the cluster.

Master nodes: When creating a cluster on CCE, you have the option to choose one or three master nodes. If you choose three master nodes, the cluster will have high availability.
Cluster scale: refers to the maximum number of worker nodes that can be managed by a cluster. For example, you can choose a cluster management scale of 50 or 200 nodes when creating the cluster. The flavors of the master nodes are influenced by the cluster scale. Higher cluster scales require higher flavors of the master nodes.
It is possible to change the cluster scale after creating the cluster. However, you can only increase the scale and cannot decrease it. For details, see Changing a Cluster Scale.

Cluster Lifecycle

**Table 1** Cluster status
Status	Description
Creating	A cluster is being created and is requesting for cloud resources.
Running	A cluster is running properly.
Hibernating	A cluster is hibernating.
Awaking	A cluster is being woken up.
Upgrading	A cluster is being upgraded.
Resizing	The cluster flavor is being changed.
Unavailable	A cluster is unavailable.
Deleting	A cluster is being deleted.