Create cluster

This document offers a detailed guide on the steps and parameter configurations needed to create a managed cluster in the console.

Preparation

Before creating a cluster, it is advised to plan and design its configuration based on service needs to ensure stable, efficient, and secure operations.

• Region: Selecting a region closer to the user's location and the deployed resources reduces network latency and enhances access speed.
• Network address planning: Define the VPC network segment and Kubernetes network segment (pod address range and service address range) based on the service scenario and cluster size, specifying the IP address range for the cluster and the available IP count for pods and nodes.
• Public network access: Decide if cluster nodes require public network access (essential for pulling public images).

Prerequisites

Before creating a cluster, you must complete the following tasks:

• [Register a Baidu account](UserGuide/Register an account.md#Register a Baidu Account) and complete real-name certification.
• During cluster creation, multiple resources such as virtual private cloud, subnet, and security group will be utilized or created. Resource regions have quota limits. For details, refer to Usage Limits.
• To add an existing Baidu Cloud Compute (BCC) instance to the cluster, ensure both the cluster and the BCC instance are within the same virtual private cloud (VPC).
• The cluster creation process involves purchasing pay-as-you-go resources such as Baidu Load Balancer (BLB). Ensure your account has sufficient balance to proceed with these resource allocations smoothly.

Note

Once a cluster is created, the following items cannot be modified:

• Modify the cluster type.
• Adjust the number of master nodes in the cluster.
• Update the cluster's location.
• Modify the cluster’s network configurations, such as virtual private cloud (VPC), subnet, service network segment, IPv6, and kube-proxy mode (service forwarding mode).

Cost description

Baidu AI Cloud Container Engine (CCE) provides users with services free of charge, but creating a cluster may incur costs for cloud infrastructure resources such as Baidu Load Balancer (BLB), NAT (Network Address Translation), public IPs, and cloud disks. Check the actual billing under the cost configuration section at the bottom of the cluster creation page. For more billing details and cloud infrastructure resource billing, refer to Product Billing.

Operation steps

1. Log in to the Cloud Container Engine Console, select Product Services - Cloud Native - Cloud Container Engine (CCE), and select Cluster Management - Cluster List in the left navigation bar to access the cluster list page.
2. In the cluster list page, click Create Cluster at the top of the list.
3. CCE provides preconfigured cluster creation templates for various scenarios. In the template selection pop-up window, you can select a template based on the template descriptions and your service requirements, then click OK to access the cluster creation page.
4. On the cluster creation page, follow the creation wizard step by step to configure settings based on your service needs: cluster configuration, Master configuration (only for standard standalone clusters), and Worker configuration.

Description:

• [Recommended] Standard managed cluster: The cluster Master is fully managed by Cloud Container Engine (CCE). You only need to purchase Worker nodes to run workloads.
• Standard standalone cluster: The cluster Master is deployed on the server instance you purchase, and you are responsible for planning, maintaining, and upgrading the cluster servers.

Cluster configuration

Basic configuration

ConfigMap	Description
Cluster name	Cluster name: Supports uppercase and lowercase letters, numbers, and -_/ special characters, must start with a letter, and have a length between 1 and 65.
Cluster scale	When selecting a standard managed cluster, it is necessary to choose the cluster scale. Select the maximum manageable node count per cluster based on service scenarios. Refer to How to Select Cluster Scale. To use a larger cluster scale, submit a ticket.
Kubernetes version	Select the currently supported Kubernetes version. The latest version is recommended. Refer to CCE Kubernetes Version Upgrade Notes for details on CCE version support.
Container runtime	For Kubernetes cluster container runtime components, CCE currently supports the latest versions of Containerd 1.6.36 and 1.7.25. Refer to How to Select Kubernetes Cluster Container Runtime Components.
Node naming pattern	Intranet IP: The cluster will use the instance’s internal IP as the node name (NodeName). Note: NodeName cannot be changed after a node is added to the cluster.
	Hostname:The cluster will use the instance’s hostname as the NodeName. Ensure that hostnames of instances joining the cluster are unique. Note: NodeName cannot be changed after a node is added to the cluster.
Bill type	Subscription: Pay before use with lower price. The associated BCC, BLB, and EIP resources created are all charged in the subscription bill type. Note: If you select subscription as the billing type, you must set the subscription period and enable auto-renewal.
	Postpay: Pay after use, activated on demand. The associated BCC, BLB, and EIP resources created are all charged in the postpay bill type.
Current region	Choose the region where the cluster will be located. Cloud products in different regions have distinct intranets, so the region cannot be changed after purchase. It’s recommended to select a region closer to your clients to reduce access latency and increase download speeds.

Network configuration

The container network requires its own address space, which must remain isolated from the node network, node subnet, and container networks of other clusters. The following example uses the network configuration details for standard managed cluster creation.

ConfigMap	Description
IPv6 dual-stack network	Enabling IPv6 dual-stack network will filter VPC networks and subnets configured with IPv6, and automatically assign IPv6 container network segment and service network segment.Note: Changes are not supported after selection. Select it carefully by referring toCCE IPv4/IPv6 Dual-Stack Network Instructions.
Virtual private cloud	Configure the cluster's network. The virtual private cloud provides the cluster with an isolated, self-configured, and managed virtual network environment. To create a new virtual private cloud, navigate to Create Virtual Private Cloud .
API Server access	Automatically create Baidu Load Balancer (BLB): The system will automatically create an intranet application Baidu Load Balancer (BLB) instance for the cluster API Server. Deleting this BLB instance will render the API Server inaccessible. If you choose to automatically create Baidu Load Balancer (BLB), additional API Server subnet and public access should be set. API Server subnet:Kubernetes API Server will use this subnet to create a Baidu Load Balancer. NAT subnets cannot be selected. If no suitable subnet is available, navigate to Create Subnet. Expose API Server using EIP: It is disabled by default. After being enabled, a public IP will be bound to the cluster API Server; otherwise, external access to the API Server will be unavailable. Note: The system defaults to creating postpay BLB and EIP instances. The bill type can be manually changed. For billing rules, see BLB Billing Instructions and EIP Billing Instructions.
	Use existing Baidu Load Balancer (BLB): The cluster API Server will be bound to the existing Baidu load balancer (BLB) instance. Deleting this BLB instance will render the API Server inaccessible. Note: Only application BLB is supported. If public network access is required to be enabled for the cluster, ensure the selected BLB instance is bound to an EIP; otherwise, public access will be unavailable.
Security group	Specify the security group for Worker nodes, support regular security group and enterprise security group: Auto-create: The system will automatically create a default security group (named {ClusterID}-worker-{randomID}) for the cluster, which is dedicated to binding Worker nodes, ensuring normal communication between nodes in the cluster. Use existing security group: You can select an existing security group to bind to the Worker node. Note: The security group must allow specified ports to ensure normal communication between nodes in the cluster. For security group port configuration details, refer to -3-}CCE Default Security Group Rules. Security groups cannot be modified after creation.
Container network mode	Support the VPC-ENI container network mode.VPC-ENI: A container network mode implemented via elastic network interface, where the container network and cloud host network reside in the same VPC. When selecting VPC-ENI mode, you must configure the elastic network interface mode, container subnet, and ClusterIP network segment. CCE offers two elastic network interface modes: shared and exclusive . Elastic network interface mode: The count of elastic network interfaces bindable to nodes and the count of auxiliary IPs assignable to elastic network interfaces vary by instance specification. For more details, please refer to Elastic Network Interface Quota.Note: Modifications are not supported after cluster creation. Shared: Multiple pods share one elastic network interface, and the system applies for multiple secondary IPs for the elastic network interface to allocate to different pods. If the shared mode is selected, you can also enable eBPF enhancement, Network Policy support, and RDMA as required. Enable eBPF enhancement: Support enabling eBPF enhancement. Once enabled, the native Kube-proxy mode will be replaced.Note: Modifications are not supported after creation. The image only supports the BaiduLinux3.0 system. Enable Network Policy: When being enabled, it supports policy-based network control for the cluster. For more information, see Using Network Policy. Exclusive: Each pod exclusively occupies one elastic network interface, delivering higher network performance based on eBPF technology. The OS only supports public image Ubuntu 20.04. The exclusive elastic network interface mode is currently available only to the allow-list users. To use it, submit a ticket. Container subnet: Pods created by the cluster will be assigned with IP addresses from the container subnet. Please select a subnet in the same availability zone as the nodes as the container network. If no options are available, click Create Subnet. The container subnet determines the maximum count of containers under the cluster. Additional subnets can be added after creation. ClusterIP network segment: Designate the private network address range for allocating IP addresses to Services in the cluster.Note: The ClusterIP network segment must not overlap with the node network segment. The current ClusterIP network segment configuration defines the maximum limit of Service resources. Changes are not allowed after creation.
LB Service subnet	Set the default subnet for BLB association when creating Service and Ingress (NAT subnets are excluded).
Elastic network interface security group	Container network mode: When selecting VPC-ENI, specify the security group bound to the elastic network interface mounted on Worker nodes, supporting regular security groups and enterprise security groups: Auto-create: The system will automatically create a default security group (named {ClusterID}-eni-{randomID}) for the cluster, which is dedicated to binding elastic network interface ENI mounted on the node server, ensuring normal communication between nodes in the cluster. Use existing security group: You may select an existing security group to bind to the Worker node. Ensure this does not affect normal communication between cluster nodes. Learn more about CCE default security group rules. <a
Kube-proxy mode	Configure Kube-proxy mode by selecting either IPTABLES or IPVS. If the cluster enables eBPF enhancement, the native Kube-proxy mode will be replaced without additional configuration. IPVS: It is suitable for scenarios where there are a large number of Services in the cluster and high performance is required for load balancers. IPTABLES: A mature and stable kube-proxy mode. Kubernetes Service discovery and Baidu Load Balancer (BLB) are configured using IPTABLES rules, offering moderate performance that is significantly impacted by scale. It is suitable for clusters with a limited number of Services.
NodePort range	Define the range of port numbers available for NodePort services. In Kubernetes, the default NodePort range is 30000-32767.

Advanced settings (optional)

ConfigMap	Description
Resource labels	You can configure resource tags to classify resources by purpose, owner, project, etc.
Cluster deletion protection	By default, accidental cluster deletion through the console or API is prevented.
Certification method	By default, the commonly used X509 client certificate authentication is used. OIDC authentication can be optionally enabled. For details, refer to Cluster Authentication Instructions.
Custom certificate SAN	Add custom IPs or domain names to the SAN (Subject Alternative Name) field in the cluster API Server’s certificate to enable client access control. Updating this setting is not supported after the cluster is created.
Cluster notes	Provide a description for the cluster.

Worker configuration

When creating a standard managed cluster, Work must be configured on the cluster creation page. An example below explains relevant Work configuration items for a standard managed cluster.

Node configuration

ConfigMap	Description
Node source	Support two node sources: Create New Nodes or Use Existing Servers. If selecting existing servers, only available instances within the current cluster’s virtual private cloud is supported.
Worker node	Click Add Node to configure Worker nodes. For node configuration parameters, refer to Add Node.
Resource labels	You can configure resource tags to categorize resources by purpose, owner, project, etc., and uniformly apply them to related resources such as CDS, EIP, snapshots, and snapshot chains.

Advanced settings (optional)

ConfigMap		Description
Data storage	Kubelet data directory	The directory in the file system where kubelet stores runtime data, such as volume files, plugin files, and other data storage directories. If a data disk is mounted, it is recommended to save the data on the data disk.
	Container data directory	Directories used for storing container images and related data. If a data disk is mounted, it is recommended to save the data on the data disk.
Script execution	Pre-deployment execution script	Before node deployment, the system will automatically execute the specified scripts. Ensure the script has reentrancy and retry logic. Script content and generated logs will be automatically saved to the node’s /usr/local/cce/scripts/ directory.
	Post-deployment execution script	The system will automatically execute this script upon node deployment. You need to independently monitor and verify script execution status. Script content and generated logs will be automatically saved to the node’s /usr/local/cce/scripts/ directory.
Node parameters	Cordon	This feature is disabled by default. Once node blocking is enabled, the node enters a non-schedulable state, and no newly created Pods will be scheduled onto it.
	Custom kubelet parameters	You may manually configure kubelet’s startup parameters based on specific requirements or cluster environments. For more information, see Custom Kubelet Parameters.
	Labels	K8S labels serve as identifiers for managing and selecting K8S objects. These labels are automatically assigned to newly created nodes and consist of a key-value pair.
	Taints	In a Kubernetes cluster, taints are a mechanism to prevent pods from being scheduled onto specific nodes. Taints are markers added to nodes, which can indicate that the node should be not accessed by certain pods. Node taints and pod Node taints and pod tolerations work in conjunction. After setting taints on a node, pod scheduling onto the node can be prevented, or pods can be evicted from the node. Unless the pod tolerations can match the node taints. A taint consists of three parts: Key: Unique identifier of the taint. Value: String associated with the key Effect: Rules for taint application, including the following types: NoSchedule: Pods without tolerations matching this taint It will not be scheduled onto this node. PreferNoSchedule: It is not recommended to schedule pods without tolerations to this node, but scheduling is still allowed if necessary. NoExecute: Pods without toleration It will not be scheduled to this node. If it is already running on the node, it will be evicted.

Master configuration

When setting up a standard standalone cluster, the Master node must be configured on the cluster creation page. Using a standard standalone cluster as an example, the Master node configuration items are explained below.

Node configuration

ConfigMap	Description
Node source	Support two node sources: Create New Nodes or Use Existing Servers. If selecting existing servers, only available instances within the current cluster’s virtual private cloud is supported.
Master node	You may select either 3 replicas or 5 replicas. If selecting 3 replicas, a minimum of 3 nodes must be added. Click Add Node to configure Master nodes. For node configuration parameters, refer to Add Node.

Server configuration

ConfigMap	Description
Security group for masters	Specify the security group bound to Master nodes, supporting both regular security group and enterprise security group. Auto-create: The system will automatically create a default security group (named {ClusterID}-worker-{randomID}) for the cluster, which is dedicated to binding Worker nodes, ensuring normal communication between nodes in the cluster. Use existing security group: You may select an existing security group to bind to the Master node. Ensure this does not affect normal communication between cluster nodes. Learn more about CCE Default Security Group Rules.
Resource labels	You can configure resource tags to categorize resources by purpose, owner, project, etc., and uniformly apply them to related resources such as CDS, EIP, snapshots, and snapshot chains.

Advanced settings (optional)

ConfigMap		Description
Data storage	etcd data directory	The directory in the file system used for storing etcd data files on the server where etcd runs. If a data disk is mounted, it is recommended to save the data on the data disk.
	Kubelet data directory	The directory in the file system where kubelet saves runtime data, such as volume files, plugin files, and other data storage directories. If a data disk is mounted, it is recommended to save the data on the data disk.
	Container data directory	Directories used for storing container images and related data. If a data disk is mounted, it is recommended to save the data on the data disk.
Script execution	Pre-deployment execution script	Before deploying a node, the system will automatically execute the predefined scripts. Make sure the script includes reentrancy and retry mechanisms. The script content and generated logs will be saved to the /usr/local/cce/scripts/ directory on the node.
	Post-deployment execution script	During node deployment, the system will automatically execute the specified script. Ensure you monitor and verify the script's execution independently. The script content and generated logs will be saved to the /usr/local/cce/scripts/ directory on the node.

Confirm configuration

After confirming the selected configuration details and billing costs, pass the pre-check in the pre-check module, then click Submit to initiate cluster creation.

• You can view the cluster's creation status in the cluster list. Once the cluster is successfully created, its status will appear as "running".