Platform Center
Home / Get started / Prepare the business cluster

Prepare the business cluster

A cluster is a collection of resources required for container runtime, including nodes, networks, storage, and other resources. It is a prerequisite for building a business environment (Namespace) on the platform to run your custom applications.

You can create a new Kubernetes cluster on the platform or manage an existing standard Kubernetes cluster, OpenShift cluster, or Amazon EKS cluster by connecting it to the platform.

This article explains how to create a cluster on the platform. For information on connecting to a cluster, please refer to the relevant content in the user manual.

Constraints and limitations

Prerequisites

Configure cluster basic information

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

  2. Click Create Cluster.

  3. Configure the relevant parameters according to the following instructions.

    Parameter Description
    Kubernetes Version The version of the Kubernetes components of the cluster and the types and versions of container runtime components supported by the selected version.

    Tip:
    - When the Kubernetes version of the cluster created through the platform is greater than or equal to 1.21, Containerd is used as the container runtime component by default.
    - When other business components to be deployed on the cluster have a strong dependency on the Kubernetes version, please select the appropriate version based on the business purpose of the cluster and the version requirements of cluster components .
    Cluster Endpoint The access address for the API server exposed by the cluster to the outside world, which must support the https protocol.

    IP Address/Domain Name:
    - When the number of control nodes in the cluster is 3 or 5, you need to enter the access address or domain name of the load balancer (such as F5 devices, IaaS layer load balancers, or HAProxy software) prepared outside the cluster in advance.
    - When there is only 1 control node in the cluster, enter the Private IP or domain name of the control node. If you plan to add control nodes after the cluster is created for easy expansion in the future, it is recommended that you enter the access address or domain name of the load balancer prepared outside the cluster in advance.

    Port: Port number.
    Caution: When using a load balancer, enter the port number of the load balancer; when not using a load balancer, you must enter 6443.
    Image Registry Binding The repository that stores the images of the platform components required by the cluster.
    - Platform Built-in: Use the image repository configured when deploying global.
    - External: Use an external image repository that has been set up in advance. You need to enter the Private Registry, Port, Name, and Password to access the image repository.
    Hardware architecture The hardware architecture of the cluster, which supports X86 or ARM.
    IPv4/IPv6 Dual Stack Whether to enable IPv4/IPv6 dual stack, which can effectively compensate for the limited IPv4 network address resources.
    After the switch is turned on, the nodes under the cluster can run in dual-stack mode, that is, the nodes can have both IPv4 and IPv6 addresses, and both IP addresses can be used for internal/external network access.
    Caution: A cluster that has enabled dual stack does not support restoration to IPv4 single stack.

    It is recommended to enable dual stack when your business application involves the following scenarios:
    - Your application needs to provide access services for users using IPv6 terminals.
    - You need to analyze and process the access sources of services provided to users who access the application using IPv6 terminals.
    - If your application system needs to use IPv6 for internal network access to other systems (such as database systems) or application systems.
    Network Mode Type of Cluster Network Plugin (CNI).

    Kube-OVN : Kube-OVN is an open-source enterprise-level cloud-native Kubernetes container network orchestration system independently developed by LingxCloud. By migrating 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 operation and management efficiency and performance.

    Calico: Calico is a layer 3 network solution that provides secure network connections for containers, with advantages such as simplicity, scalability, high security, and good performance.

    Flannel: Provides a flat network environment for all containers in the cluster, allowing containers created by different node hosts in the cluster to have a unique virtual IP address for the entire cluster. The container network segment is evenly divided into each node in the cluster according to the mask, and the container group on each node will allocate IP addresses from the network segment partitioned on the node. This improves communication efficiency between containers without considering IP conversion issues.

    Custom: If you need to install other network plugins, please select the Custom mode, and you can manually install the network plugin after the cluster is created.
    Container Network Cluster CIDR: The IP address range used by the container group started when the cluster is created.

    Service CIDR: The IP address range used by Kubernetes Service with type ClusterIP, which cannot overlap with the subnet of Cluster CIDR.

    Number of Node IPs: Only supported when the cluster network mode is Flannel. Sets the maximum number of IPs that can be allocated to container groups on each node in the current container network.
    Note: The maximum number of nodes that the cluster can accommodate will be automatically calculated based on the above configuration and displayed in the prompt content below the input box.
    Kube-OVN Network Advanced Settings Join CIDR: The IP address range used for communication between nodes and container groups in overlay transmission mode. It cannot overlap with the network segments of Cluster CIDR and Service CIDR.

    Transmit Mode:
    - overlay: Uses a virtual overlay network abstracted on top of the infrastructure.
    - underlay: The implementation of this transmission mode depends on physical network devices. It can directly allocate address resources in the physical network to containers, ensuring better performance and connectivity with the physical network.
    Gateway: The gateway address of the physical network, which is the gateway address of the Cluster CIDR network segment (must be within the Cluster CIDR address range).
    Bridge Networks: The name of the network card that handles business container traffic on the node, which can be the same as the cluster Network Interface Card. For example: eth1.
    VLAN ID: The virtual LAN identifier (VLAN number), for example: 0.
    Node Name Setting You can choose to use the node IP or the hostname as the name of the node on the platform.
    Caution: When choosing to use the hostname as the name of the node on the platform, ensure that the hostname of the node added to the cluster is unique.
    Network Interface Card The name of the network card device used by the cluster network plugin.
    Caution: When selecting a network card, you need to specify it based on the following situations.
    - When choosing Docker as the container runtime:
       - If the host has multiple network cards, you can leave the network card name blank only when the Kube-OVN network mode selects the overlay transmission mode. The backend will select the network card corresponding to the default route. In other cases, you need to specify the network card name;
       - If the host has only one network card, you can leave the network card name blank, and the backend will select the network card by default.
    - When choosing Containerd as the container runtime: You need to specify the network card name.
    Nodes Add nodes to the cluster. For detailed instructions, please refer to Adding Nodes to a Self-built Cluster .
    Caution:
    - When the operating system of the node is EulerOS, add the cgroup-driver: cgroupfs key-value pair to the kubelet parameters in the Extended area.
    - At least one control node must be added, and the number can only be 1, 3, or 5.
    - The cluster has multi-backup and disaster recovery capabilities only when the number of control nodes is greater than or equal to 3.
    - It is not recommended to use a cluster with only one control node as a production environment cluster.
    Monitoring Type Supports Prometheus and VictoriaMetrics. For the selection of monitoring tools, please refer to the document How to Choose Monitoring Components? .
    When selecting the VictoriaMetrics monitoring component, you need to configure the monitoring deployment method:
    - Deploy VictoriaMetrics includes all components, including VMStorage, VMAlert, VMAgent, etc.
    - Deploy VictoriaMetrics Proxy only deploys the log collection component, that is, VMAgent. When using this deployment method, you need to associate it with VictoriaMetrics instances deployed on other clusters in the platform to provide monitoring services for the cluster.
    Monitoring Nodes Select the nodes used to deploy the cluster monitoring components, including compute nodes and control nodes that allow application deployment.
    To avoid affecting cluster performance, it is recommended to prioritize compute nodes. After the cluster is successfully created, monitoring components with a storage type of Local Volume will be deployed on the selected nodes.
    Tip: If you choose not to configure this parameter when creating a cluster (do not deploy monitoring components temporarily), when the cluster is created successfully and the status is normal, you can go to the monitoring page of the cluster to deploy monitoring components for the cluster. At this time, the storage type can be selected as Local Volume, StorageClass, or Persistent Volume. For specific operations, please refer to Deploying Monitoring Components .

  4. Click Create.