Creating a Cluster

The platform enables you to build a Kubernetes business cluster based on your infrastructure.

Constraints and Limitations

• After the cluster is created successfully, the following parameters cannot be changed: network mode, container network and service network, hardware architecture, IPv4/IPv6 dual-stack, and node proxy configuration. To make adjustments, you need to recreate the cluster, so please configure them carefully.

• The number of control nodes in a cluster can only be 1, 3, or 5. When there is only 1 control node in the cluster, any issues with that node will render the entire cluster unavailable. Therefore, it is not recommended to use such clusters in a production environment.

• Each node can only belong to one cluster, and nodes waiting to be added to a cluster must have the same hardware architecture as the cluster’s hardware architecture.

Prerequisites

• When the number of control nodes in the cluster is 3 or 5, please prepare hardware or software load balancers in advance to provide load balancing capabilities to the cluster. Examples include F5 devices, IaaS-layer load balancers, or HAProxy software.

• If you need to use a self-built VIP as the cluster’s address to ensure high availability, please contact the platform’s network administrator or operations personnel in advance to apply for a VIP (Virtual IP) and VRID (Virtual Router ID).

  Tip: The VIP must be an available IP (IPv4 address) in the subnet where the cluster nodes’ IPs reside and should not be the same as any node’s IP.

• If you need to pull platform component images required for the cluster from an external image repository, please set up a repository to store platform component images in advance. For specific implementation plans, please contact technical support.

• Node-related:

  • Please refer to the Node Availability Check Reference Table to prepare and check nodes to be added to the cluster. Ensure that all conditions are met to avoid deployment failures.

  • When global clusters cannot directly access nodes to be added to the cluster via SSH and require access through a proxy, please prepare a proxy service in advance.

    Tip: Proxy services currently only support SOCKS5 proxies.

Steps

1. In the left navigation bar, click Cluster Management > Clusters.

2. Click Create Cluster.

3. Follow the instructions below to configure Basic Information, Container Network, Node Configuration, and Advanced Parameters.

Configure Basic Information

Configure Container Networking

• Kube-OVN

  It is an open-source enterprise-level cloud-native Kubernetes container network orchestration system developed independently by Lingque Cloud. By moving mature network functions in the OpenStack domain to Kubernetes, it not only supports complex application scenarios such as cross-cloud network management, interconnection between traditional network architecture and infrastructure, and edge cluster landing, but also greatly enhances the security of Kubernetes container network, improves management efficiency and performance.

  Parameter	Description
  Segment	Also known as Cluster CIDR, representing the subnet segment of the default subnet. After the cluster is created, you can add new subnets.
  Transmission Mode	Overlay: A virtual overlay network abstracted on top of the infrastructure that does not occupy physical network resources. When creating an Overlay default subnet, all Overlay subnets in the cluster use the same cluster NIC and node NIC configuration. Underlay: The implementation of this transmission mode depends on physical network devices. It can directly allocate address resources in the physical network to Pods, ensuring better performance and connectivity with the physical network. Nodes in the Underlay subnet must have multiple NICs, and the NIC used for bridged networking must be exclusively used by Underlay and cannot carry other traffic such as SSH. When creating an Underlay default subnet, the cluster NIC is essentially a default NIC for bridged networking, and the node NIC is configured for nodes in the bridged network. Note: Container networking under the Underlay transmission mode depends on physical network support. It is recommended to plan together with the network administrator. You can refer to the best practice Preparing Kube-OVN Underlay Physical Network . - Default Gateway: The gateway address of the physical network, which is the gateway address of the Cluster CIDR subnet (must be within the Cluster CIDR address range). - VLAN ID: Virtual LAN identifier (VLAN number), e.g., 0. - Reserved IPs: The reserved IPs set will not be automatically allocated. For example, if some IPs in the subnet are occupied by other devices, you can set them as reserved IPs.
  Service Segment	The IP address range used by Kubernetes Services of type ClusterIP. It must not overlap with the subnet of the default subnet.
  Join Segment	For Overlay transmission mode, this is the IP address range used for communication between nodes and container groups. It must not overlap with the default subnet or Service segment.

• Calico

  Calico is a Layer 3 network solution that provides secure network connectivity for containers. It offers advantages such as simplicity, scalability, high security, and good performance.

  Parameter	Description
  Default Subnet	Also known as Cluster CIDR, representing the subnet segment of the default subnet. After the cluster is created, you can add new subnets.
  Service Segment	The IP address range used by Kubernetes Services of type ClusterIP. It must not overlap with the default subnet.

• Flannel

  Flannel provides a flat network environment for all containers in the cluster, giving containers created on different nodes in the cluster a unique virtual IP address across the entire cluster. Container network segments are evenly divided into IP addresses allocated to container groups on each node in the cluster. This improves communication efficiency between containers without the need to consider IP translation issues.

  Parameter	Description
  Container Segment	Also known as Cluster CIDR, it is the IP address range used by container groups launched when the cluster is created. It supports setting the maximum number of IPs allocated to container groups on each node in the current container network. Note: The platform will automatically calculate the maximum number of nodes the cluster can accommodate based on the above configuration and display it in the prompt content below the input box. Note: After the cluster is created, the cluster network cannot be changed, so please plan your network reasonably.
  Service Segment	The IP address range used by Kubernetes Services of type ClusterIP. It must not overlap with the container segment.

• Custom

  If you need to install other network plugins, please select the Custom mode. After the cluster is created successfully, you can manually install network plugins.

  Parameter	Description
  Container Segment	Also known as Cluster CIDR, it is the IP address range used by container groups launched when the cluster is created.
  Service Segment	The IP address range used by Kubernetes Services of type ClusterIP. It must not overlap with the container segment.

Configure Node Settings

Table - Node Configuration Parameter Description

Parameter	Description
Type	Control Node: Responsible for running components such as kube-apiserver, kube-scheduler, kube-controller-manager, etcd, container network, and part of platform management components in the cluster. When Deployable Applications is enabled, control nodes can also be used as compute nodes. Compute Node: Responsible for running business container groups in the cluster. Note: If there are no compute nodes in the cluster, the cluster can only run platform components and a few businesses and cannot run normal production businesses. Note: Clicking on the left of Type can expand more node configuration parameters.
IPv4 Address	The IPv4 address of the node. For clusters created in intranet mode, please enter the private IP of the node.
IPv6 Address	This parameter is effective when the cluster enables IPv4/IPv6 dual stack. It is the IPv6 address of the node.
Deployable Applications	This parameter is effective when the Node Type is Control Node. It specifies whether to allow business applications to be deployed on this control node, which schedules container groups related to business applications to this node.
Display Name	The display name of the node.
SSH Connection IP	When accessing the node through the SSH service, you can connect to the node’s IP address. If you can log in to the node using ssh <username>@<node's IPv4 address>, you do not need to set this parameter. Otherwise, you need to enter the public IP of the node or the external IP of NAT to ensure that the global cluster and agents can connect to the node through this IP.
NIC Name	Please fill in the NIC name used by the node. The priority of NIC configuration that takes effect is as follows, from left to right, in descending order of priority: kube-OVN Underlay: Node NIC > Cluster NIC kube-OVN Overlay: Node NIC > Cluster NIC > NIC corresponding to the default route of the node Calico: Cluster NIC > NIC corresponding to the default route of the node Flannel: Cluster NIC > NIC corresponding to the default route of the node
Associated Bridged Network	Note: Bridged networks cannot be configured when creating clusters. When adding nodes to the cluster, you can configure this option only if Underlay subnets have been created in the cluster. Select the created bridged network . If you do not want to use the default NIC of the bridged network, you can configure the node NIC separately.
SSH Port	The SSH service port number, e.g., 22.
SSH Username	SSH username, you need to enter the username with root privileges, e.g., root.
Proxy	Whether to access the node’s SSH port through a proxy. When the global cluster cannot directly access the node to be added (e.g., the global cluster and the business cluster are not in the same network segment; the node’s IP is an intranet IP and the global cluster cannot directly access it), you need to turn on this switch and configure proxy-related parameters. After configuring the proxy, you can access and deploy the node through the proxy. Note: Currently, only SOCKS5 proxy is supported. Address: The address of the proxy server, e.g., 192.168.1.1:1080. Username: The username for accessing the proxy server. Password: The password for accessing the proxy server.
Node Authentication	The authentication method for logging in to the added node and the corresponding authentication information. You can choose: Password: You need to enter the username with root privileges and the corresponding SSH password. Key: You need to enter the private key and private key password with root privileges.
Save as Draft	Save the configured data in the current dialog box as a draft and close the Add Node dialog box. Without leaving the Create Cluster page, you can open the Add Node dialog box and restore the configured data saved as a draft by selecting Restore from Draft. Note: The data restored from the draft is the data saved as a draft most recently.

(Optional) Configure Extended Parameters

Note:

• In addition to the required configurations, it is not recommended to set extended parameters, as setting them incorrectly may render the cluster unavailable, and the cluster cannot be modified after creation.
• If the Key you fill in conflicts with the default parameter Key, it will overwrite the default configuration.

Operational Steps

1. Click Extended Parameters to expand the extended parameter configuration area. You can choose to set the following extended parameters for the cluster.

   Parameter	Description
   Docker Parameters	dockerExtraArgs, additional Docker configuration parameters that will be written to /etc/sysconfig/docker. It is recommended not to modify them. When configuring Docker through the daemon.json file, it must be configured in the key-value pair format.
   Kubelet Parameters	kubeletExtraArgs, additional Kubelet configuration parameters. Note: After entering the Number of Node IPs parameter in the Node IP Count parameter under Container Network, a default Kubelet parameter configuration with the key max-pods and the value being the Node IP Count will be automatically generated. This is used to set the maximum number of container groups that can run on any node in the cluster, and this configuration will not be displayed on the interface. If you add max-pods: Maximum number of containers that can run key-value pairs to the Kubelet Parameters area, it will overwrite the default value. The value can be any positive integer, and it is recommended to use the default value (number of node IPs) or enter a value not exceeding 256.
   Controller Manager Parameters	controllerManagerExtraArgs, additional Controller Manager configuration parameters.
   Scheduler Parameters	schedulerExtraArgs, additional Scheduler configuration parameters.
   APIServer Parameters	apiServerExtraArgs, additional APIServer configuration parameters.
   APIServer Address	publicAlternativeNames, the APIServer access addresses included in the certificate. You can only enter IP addresses or domain names, with a maximum length of 253 characters.
   Cluster Annotation Parameters	Annotation information for the cluster, marking the characteristics of the cluster under metadata in the form of key-value pairs for platform components or business components to obtain related information.

2. Click Create. Return to the cluster list page, and the cluster is in the Creating state.

Note: When the cluster is in the Creating state, you can check the progress of the execution. For specific operations, please refer to the Follow-Up Operations section.

Follow-Up Operations

View Execution Progress

In the cluster list page, you can view the list information of the created clusters. Among them, clusters in the Creating state can view the execution progress.

Operational Steps

1. Click View Execution Progress > on the right side of the cluster in the Creating state.

2. In the pop-up execution progress dialog box, you can view the execution progress of the cluster (status.conditions).

Note: When a certain type is being executed or the status is failed with a reason, you can hover over the corresponding reason (displayed in blue font) to view the detailed information of the reason (status.conditions.reason).

Deploy Plugins

After successfully creating the cluster, you can go to Plugin Management to select the necessary plugins for the cluster, including monitoring components, log collection components, log storage components, and more.

Associate Projects

You can add the newly created cluster to an existing project through Create Project based on the cluster or by Adding a Project Associated with the Cluster .

You can then create namespaces under the cluster through Create Namespace to allocate cluster resources to namespaces, providing a runtime environment for business containers.