Cluster Management
Cluster
General
A cluster mainly refers to a Kubernetes cluster that runs container applications. ZStack Zaku provides standardized, highly available and stable Kubernetes clusters, and simplifies O&M operations such as cluster deployment, scale-out, upgrade and high availability, so that you can focus on your own upper-layer container applications.
Creating a Cluster
Preparations
- Make sure that the customized operating system of ZStack Cloud has been installed on the nodes to be used to create the cluster. Contact official technical support to obtain the customized operating system that matches the current platform version.
- Make sure that each node used as a control plane node has one 500 GB data disk attached, which is used to store the monitoring and log data of the cluster.
- Make sure that the nodes to be used to create the cluster can communicate with each other over the network, and that all the nodes can be accessed by the management cluster.
Creating a Cluster
In the ZStack Zaku main menu, click to enter the Cluster page. Click Create Cluster to enter the Create Cluster page.
Creating a cluster includes the following three steps:
- Node configurationYou can refer to the following example to enter the required information:
- Reuse the Business Network as the Management Network: select whether the business network is reused as the management network. After it is enabled, the management network reuses the business network, and the management cluster accesses the nodes and manages the business cluster through the business network IP addresses of the nodes. Make sure that the management cluster and the business network are connected.
- Cluster HA: select whether to enable cluster HA. It is enabled by default. If it is disabled, the cluster does not support HA and only 1 control plane node is required. It is not recommended to disable cluster HA in a production environment.
- Node Information: enter the information of the
nodes to be used to create the cluster.
- Adding Method: the method of adding nodes, including IP address and IP range.
- Business Network IPv4 Address: enter the business network IPv4 address of the node. Enter this field when the adding method is IP address.
- Management Network IPv4 Address: enter the management network IPv4 address of the node. Enter this field when the adding method is IP address. The management cluster accesses and manages the business cluster nodes through the management network IPv4 addresses, so make sure that the management cluster and this address are connected. When the business network is reused as the management network, the management network IPv4 address is the same as the business network IPv4 address.
- Business Network IPv4 Range: enter the business network IPv4 range of the nodes. Enter this field when the adding method is IP range.
- Management Network IPv4 Range: enter the
management network IPv4 range of the nodes. Enter this field when
the adding method is IP range. When the business network is
reused as the management network, the management network IPv4
range is the same as the business network IPv4 range.
Note:
- Make sure that the IP addresses entered are consistent with the actual configuration of the machines.
- Make sure that the management network IPv4 addresses and the management cluster are connected. When the business network is reused as the management network, make sure that the business network IPv4 addresses and the management cluster are connected.
- Make sure that the business network IPv4 addresses of the nodes are connected to each other.
- The management network IPv4 addresses of different nodes cannot be duplicated. The business network IPv4 addresses of different nodes cannot be duplicated. When the business network is not reused as the management network, a management network IPv4 address and a business network IPv4 address cannot be duplicated.
- When the business network is not reused as the management network, make sure that the IP addresses in the management network IPv4 range correspond to those in the business network IPv4 range one by one. The IP addresses in the same order belong to the same node. For example, the 1st IP address in the business network IPv4 range and the 1st IP address in the management network IPv4 range belong to the 1st node.
- Make sure that the names of the NICs where the business network IPv4 addresses of the 3 control plane nodes are located are the same, and that the names of the NICs where the management network IPv4 addresses of the 3 control plane nodes are located are the same.
- Node Name: set the name of the node.
Naming rules: the length is limited to 2 to 45 characters, and
the input can contain only lowercase letters, digits and the
separator (-). It must start with a lowercase letter and cannot
end with the separator. When the adding method is IP range, a
start suffix must be specified. The node name consists of the name
and the suffix, and the suffix increases from the start suffix in
turn, such as "-1/-2/-3".
Note:
- The hostname of a host is set to the node name during the process of adding the node.
- The node names used in this batch cannot be duplicated.
- Node Role: select the role of the node.
Control plane node, compute node and GPU node are available. When
cluster HA is enabled, a cluster must have 3 control plane nodes.
When cluster HA is disabled, a cluster must have 1 control plane
node.
Note:
- A control plane node can also be used as a compute node, and then the business pods can also be scheduled to the control plane node.
- The corresponding components are installed automatically on a GPU node during the deployment process. Select whether to install a machine as a GPU node according to the actual situation.
- If GPU node is selected, make sure that the GPU driver has been installed correctly on the node. If the driver is not installed, only the corresponding components are installed and the node is not set to the GPU node role.
- GPU Manufacturer: this field must be
entered when GPU node is selected as the node role. Select the
manufacturer of the GPUs on the node, and the system installs the
GPU-related components of the corresponding manufacturer.
Currently the following manufacturers are supported: NVIDIA,
Huawei, HYGON, Iluvatar and Alibaba
Note:
- The huawei NPU driver and related components require the system accounts HwHiAiUser and hwMindX, and UID/GID 1000 and 9000. A UID/GID conflict message means that UID/GID 1000 or 9000 on the listed nodes is already used by users or groups other than these huawei accounts.
- If huawei is selected as the GPU manufacturer, resolve the conflicts on the listed nodes and run the check again. You can continue only after the check passes.
- If huawei is not selected as the GPU manufacturer, you can acknowledge the risk and continue. However, resolve the conflicts before using huawei NPUs later, or the driver or related components may fail to install.
- Iluvatar GPU Virtualization License: this field must be entered when there is a GPU node and the GPU manufacturer is Iluvatar. Enter the license of Iluvatar GPU virtualization. This license is required to share Iluvatar GPUs in containers, and it is obtained from Iluvatar officially.
- Node ROOT Password: enter the password of the root account of the nodes, which is used to connect to the nodes over SSH to execute the installation steps during the process of adding the nodes. Make sure that the ROOT password of each node is the same.
- Node SSH Port: enter the port used to connect to the nodes over SSH, which is used to connect to the nodes over SSH to execute the installation steps during the process of adding the nodes. Make sure that this port of each node can be connected.
- Basic configurationYou can refer to the following example to enter the required information:
- Cluster Name: set the name of the cluster. Naming rules: the length is limited to 2 to 50 characters, and the input can contain only lowercase letters, digits and the separator (-). It must start with a lowercase letter and cannot end with the separator.
- Cluster Version: select the Kubernetes version of the cluster. The default is version 1.35, and version 1.30 can be enabled by configuration.
- Business Network VIP: enter the high-availability address of the cluster API Server on the business network. Use an IPv4 address within the business network segment.
- Cloud Network for the Business Network: if the platform is connected to ZStack Cloud 5.2.0 or later and a cloud network contains this VIP, select that network. The platform reserves the IP address in the selected network to prevent other cloud platform resources from using it.
- Management Network VIP: enter the high-availability address of the cluster API Server on the management network. Use an IPv4 address within the management network segment. If the business network is reused as the management network, both networks use the same VIP.
- Cloud Network for the Management Network: if the business network is not reused as the management network, select the network containing the management network VIP under the conditions described above. The platform reserves the IP address in the selected network.
- Maximum Number of Pods per Node: enter the maximum number of pods allowed to run on each node. The default is 110, and only an integer from 50 to 1000 can be entered.
- Monitoring and Log Disk: the monitoring and log disk is used by the monitoring and log components to create PVCs and store the monitoring and log data. Select 1 disk for each control plane node as the monitoring and log disk.
- Network Plugin: the network plugin used by the cluster, which is fixed to Calico.
- Network Mode: select the network mode of the
cluster. The default is VXLAN.
- VXLAN (default): an overlay network. It has no requirement on the data center and is ready to use out of the box. It applies to most scenarios.
- BGP: no encapsulation, and pod IP addresses can be accessed directly from outside the cluster. It applies to the scenarios where BGP is already used in the data center, where pod IP addresses need to be accessed directly from outside the cluster, or where the performance requirement is extremely high.
Note: Preconditions for selecting
the BGP mode: the data center switches support BGP and have been
configured with BGP (AS/neighbors), the pod network segment does not
conflict with the data center network segments, and TCP port 179 is
allowed. The BGP mode requires the data center network to support BGP
and to have been configured for interconnection, otherwise the cluster
network is not connected.
Note: The BGP
mode currently has the following usage limitations:- Only business clusters support the BGP mode. The management cluster does not support it.
- A cluster in the BGP mode does not support enabling microservices governance or deploying the microservices governance component.
- A cluster in the BGP mode does not support using the pod external network.
- A cluster in the BGP mode does not support cluster upgrade currently.
- Router BGP Address: this field must be entered when the network mode is BGP. Enter the BGP address of the peer router. It must be in IPv4 format and cannot conflict with the node IP addresses, the pod network segment or the service network segment.
- Router AS Number: this field must be entered when the network mode is BGP. Enter the AS number of the peer router. It can only be an integer from 1 to 4294967294, and 23456 and 65535 cannot be entered.
- Cluster AS Number: this field must be entered when the network mode is BGP. Enter the AS number used by the cluster. It can only be an integer from 1 to 4294967294, and 23456 and 65535 cannot be entered. It cannot be the same as the router AS number or the AS number of an existing cluster on the platform.
- BGP RR Node: this field is displayed when the network mode is BGP. It refers to the nodes that establish BGP sessions with the peer router, and they must be configured as BGP neighbors on the router. For an HA cluster, it is fixed to the 3 control plane nodes entered in the node configuration. For a cluster with a single control plane node, it is fixed to this control plane node.
- Pod Network Segment: enter the network segment used
by the pods in the cluster, which is used to allocate the IP addresses used
by the pods.
- When the network mode is VXLAN, the default is 10.233.64.0/18. It must be in CIDR format and the mask must be less than 24. If the default pod network segment is modified, avoid overlapping with the intranet network segment and the other network segments used when this cluster is created.
- When the network mode is BGP, there is no default value. It must be in CIDR format and the mask must be less than or equal to 26. This network segment is advertised to the physical network and is routable outside the cluster, so enter a network segment that is allocated by the network administrator, is globally unique and has been allowed on the router side. Meanwhile, avoid overlapping with the existing network segments in the data center, the network segment where the management network IP addresses of the nodes are located and the pod network segments of the other clusters.
- Node IP Block Mask: select the mask of the IP
blocks requested from the pod network segment each time for the pods on a
node. /24 to /30 are available and the default is /26 (64 IP addresses are
requested each time). The mask must be greater than the mask of the pod
network segment. When the network segment is limited or the number of the
pods on a single node is small, the mask can be increased to accommodate
more nodes.
Note: The node IP block mask cannot be
modified after the cluster is created. - Service Network Segment: enter the network segment used by the services in the cluster, which is used to allocate the ClusterIP addresses used by the services. The default is 10.233.0.0/18. If the default service network segment is modified, avoid overlapping with the intranet network segment and the other network segments used when this cluster is created.
- DNS Server: add DNS servers to provide DNS resolution services and resolve the domain names outside the cluster. If no dedicated DNS server is deployed, you can enter the address of a public DNS server, such as 223.5.5.5.
- Microservices Governance: select whether to enable microservices governance. After it is enabled, the microservices governance related components are deployed in the cluster, and the microservices governance related features can be used in the cluster. It cannot be enabled when the network mode is BGP.
- Image Data Disk: optional. Select the image data disk used to store the image data. If no image data disk is set, the image data is stored on the system disk by default. When there are many large images in use, it is recommended to attach a dedicated disk to the nodes to store the images, so as to avoid the image data filling up the system disk and causing system exceptions.
- Configuration confirmation
Confirm the configuration information of the cluster. You can go back to modify it.
After you click OK, the system starts to create the cluster. You can click to enter the Cluster page and view the creation progress of the cluster.
Managing Clusters
In the ZStack Zaku main menu, click to enter the Cluster page.
Clusters support the following operations:
| Operation | Description |
|---|---|
| Create Cluster | Create a cluster. |
| Reinstall | Reinstall a cluster that failed to be created. |
| Cluster Details | Enter the cluster details page to view the basic
information, the network configuration, the resource usage and the kubeconfig
of the cluster, as well as the cluster operation logs, including the logs of
creating the cluster, adding nodes and removing nodes. Note:
Click the pod tab to view the pods in the current cluster. You can export the results matching your query from the current page or all pages. For pod operations, see Managing Pods. Note: If the namespace containing the pod has not been added to a project, you cannot open the pod details or web terminal. Contact the administrator to add the namespace to a project. |
| Functional Component | Enter the cluster details page and click Functional Component to view the functional components supported by the platform and their deployment status in the cluster, and deploy the components as needed. |
| Integrate Cluster | Integrate an existing Kubernetes cluster into the platform
for management. Note:
|
| Cancel Integration | Cancel the integration of a cluster. After the integration is canceled, the cluster can no longer be used or managed on the current platform. |
| Delete Cluster | Delete the cluster. Note: Deleting a
cluster also deletes all the resources in the current cluster and clears
the cluster configuration on the nodes. The cleared resources and
configuration cannot be recovered. Perform this operation with
caution. |
Cluster Access Configuration
- Download and install the latest version of the kubectl client. For details, see Installing and Deploying the kubectl Client.
- View the kubeconfig of the cluster.
- In the ZStack Zaku main menu, click in the upper right corner to view the KubeConfig of the current cluster.
- An administrator can also enter the cluster details page directly to view the KubeConfig of the cluster.
- According to the network situation of the cluster, you can choose to access the cluster using the business network VIP or the management network VIP. Select the corresponding KubeConfig, copy the content in Kubeconfig and paste it into the $HOME/.kube/config directory of the kubectl client to complete the access configuration.
Kubectl Terminal
The Kubectl terminal is a web-based command line tool provided by the platform. With it, you can connect to a cluster and execute kubectl commands directly without installing the kubectl client locally.
- In the ZStack Zaku main menu, click in the upper right corner, select a cluster in the dialog box and click OK. The system opens the Kubectl terminal in a new tab.
- On the Cluster page, click Kubectl Terminal in the operation column of a cluster to open the Kubectl terminal of the cluster in a new tab directly.
- Enter the cluster details page, and click Kubectl Terminal in the operations in the upper right corner, or click Open Kubectl Terminal in the basic information card of the overview, to open the Kubectl terminal of the cluster in a new tab directly.
Note:
- You can open the Kubectl terminals of the clusters to which the namespaces under all the projects you have joined belong. The operation permissions in a terminal are consistent with your projects and read/write permissions on the platform, and operations beyond the permissions cannot be performed.
- The Kubectl terminal of a self-built cluster or the management cluster can be opened when the cluster is in the Running or Scaling state. The Kubectl terminal of an integrated cluster can be opened only when the cluster is in the Running state. It cannot be opened in the other states.
- Multiple Kubectl terminal pages can be opened at the same time. The terminal sessions are independent of each other and do not affect each other.
- The connection is disconnected when you leave the page or close the tab. The connection is disconnected automatically after 20 minutes of inactivity.
Cluster Advanced Settings
In the ZStack Zaku main menu, click to enter the Cluster page. Click the name of a cluster to enter the cluster details page, and click Advanced Settings to enter the advanced settings sub-page.
Clusters support the following advanced settings:
| Name | Description |
|---|---|
| Log Data Retention Period |
|
| Log PVC Size |
|
| Resume Log Data Writing |
Note:
|
| Monitoring Data Retention Period |
Note:
|
| Monitoring PVC Size |
Note:
|
| Node Auto-Scaling Group |
Note:
|
Functional Components
The functional component list displays the functional components supported by the platform and their deployment status in a cluster, and you can deploy the components as needed. Currently the following 5 functional components are supported: the microservices governance component, the workload auto-scaling component, ZStone-RBD-CSI, ZCE-iSCSI-CSI and ZCE-NFS-CSI.
Microservice Governance Component
The microservices governance component includes all the components required by microservices governance, such as istiod and the visualization plugin, and provides microservices governance capabilities. After the microservices governance component is deployed, the microservices governance related features can be used in the cluster.
Deploying the Microservices Governance Component
In the ZStack Zaku main menu, click to enter the Cluster page. Click the name of the cluster to enter the cluster details page, and click Functional Component to enter the functional component sub-page. Click the Deploy button after the microservices governance component in the functional component list, and the Deploy Microservices Governance Component dialog box is displayed.
Note:
- The default namespace is istio-system. If a new namespace is entered, the namespace is created by default and the microservices governance component is deployed in it.
- Make sure that no istio related component has been deployed under the namespace entered, so as to avoid conflicts.
- If the deployment of the microservices governance component fails, it can be deployed again, and the namespace cannot be changed then.
- The microservices governance component cannot be deployed again in a cluster where it has been deployed successfully.
- A cluster whose network mode is BGP does not support microservices governance, and the microservices governance component cannot be deployed in it.
ZStone-RBD-CSI
ZStone-RBD-CSI is used to connect Kubernetes to the block storage service of ZStone and provide persistent block storage for containers. After ZStone-RBD-CSI is deployed, the block storage of ZStone can be connected, and it can be used in the cluster by creating PVCs with the related storageclass.
Preparations
- An available ZStone storage service exists.
- The image and the chart of ZStone-RBD-CSI have been prepared in the management
cluster. You can follow the steps below:
- Contact official technical support to obtain the image and chart resource package of ZStone-RBD-CSI.
- Upload the obtained resource package to the third node of the management
cluster (the first node if it is not an HA cluster), and execute the
following command to install the resource package:
bash zaku-${k8s version}-${version}-all-in-one-addon-csi.bin. ${k8s version} and ${version} are the version of the k8s cluster and the version of the platform respectively. Enter them according to the actual name of the resource package. - The resource package needs to be uploaded to the management cluster only once, and then ZStone-RBD-CSI can be installed in any cluster in this environment.
Deploying ZStone-RBD-CSI
In the ZStack Zaku main menu, click to enter the Cluster page. Click the name of the cluster to enter the cluster details page, and click Functional Component to enter the functional component sub-page. Click the Deploy button after ZStone-RBD-CSI in the functional component list, and the Deploy ZStone-RBD-CSI dialog box is displayed.
- Storage Cluster ID: enter the UUID of the ZStone storage
cluster to be connected. It can be obtained by executing the following command on a
storage node:
ceph -s | grep id: | awk '{print $2}' - Mon Address: enter the Mon addresses of the storage service.
They can be obtained by executing the following command on a storage node:
ceph mon dump
Note:
- When the storage service has multiple Mon addresses, enter them in the input boxes respectively.
- A Mon address must contain the IP address and the port, for example, "172.31.12.216:6789".
- Storage Pool: enter the ID of the storage pool. It can be
obtained by executing the following command on a storage node:
rados lspools. The block storage corresponding to a PVC is created in this storage pool.
Note:
- The CSI of ZStone and that of ZCE cannot be deployed in the same cluster at the same time.
- ZStone-RBD-CSI cannot be deployed again in a cluster where it has been deployed successfully.
- For a cluster where the deployment failed, it can be uninstalled and then deployed again.
- ZStone-RBD-CSI is deployed in the zstack-csi namespace by default. When the CSI is deployed, a storageclass named zaku-rbd is created at the same time, and PVCs can be created with this storageclass to use block storage volumes.
- You can view the detailed deployment logs on the operation log sub-page of the cluster details page.
ZCE-iSCSI-CSI
ZCE-iSCSI-CSI is used to connect Kubernetes to the block storage service of ZCE and provide persistent block storage for containers. After ZCE-iSCSI-CSI is deployed, the block storage of ZCE can be connected, and it can be used in the cluster by creating PVCs with the related storageclass.
Preparations
- An available ZCE storage service exists.
- The image and the chart of ZCE-iSCSI-CSI have been prepared in the management
cluster. You can follow the steps below:
- Contact official technical support to obtain the image and chart resource package of ZCE-iSCSI-CSI.
- Upload the obtained resource package to the third node of the management
cluster (the first node if it is not an HA cluster), and execute the
following command to install the resource package:
bash zaku-${k8s version}-${version}-all-in-one-addon-csi.bin. ${k8s version} and ${version} are the version of the k8s cluster and the version of the platform respectively. Enter them according to the actual name of the resource package. - The resource package needs to be uploaded to the management cluster only once, and then ZCE-iSCSI-CSI and ZCE-NFS-CSI can be installed in any cluster in this environment.
Deploying ZCE-iSCSI-CSI
In the ZStack Zaku main menu, click to enter the Cluster page. Click the name of the cluster to enter the cluster details page, and click Functional Component to enter the functional component sub-page. Click the Deploy button after ZCE-iSCSI-CSI in the functional component list, and the Deploy ZCE-iSCSI-CSI dialog box is displayed.
- multipathVendor: enter the multipathVendor, which can be
obtained by executing the following command on a storage node:
sed -n -re 's/(.*DiskVendor\s*=\s*)(.*)/\2/p' /etc/xms/xms.conf - multipathProduct: enter the multipathProduct, which can be
obtained by executing the following command on a storage node:
sed -n -re 's/(.*DiskModel\s*=\s*)(.*)/\2/p' /etc/xms/xms.conf - Storage Service Access Token: enter the access token generated on the ZCE storage service console.
- Block Storage Access Path: set the block storage access path. When ZCE-iSCSI-CSI is deployed, a block storage access path with this name is created automatically in the storage service. Make sure that the name set does not conflict with the names of the existing access paths in Block Storage Management - Access Path on the storage service console.
- Storage Service Control Plane Node IP: obtain the IP addresses of the nodes with the management role from Resource Management - Node List on the storage service console, and enter the IP address of each control plane node in each input box respectively.
- Storage Service Control Plane Node Name: obtain the names of the nodes with the management role from Resource Management - Node List on the storage service console, and enter the name of each control plane node in each input box respectively.
- Storage Pool Name: enter the name of a storage pool in Resource Management - Storage Pool on the storage service console. The block storage corresponding to a PVC is created in this storage pool.
Note:
- The CSI of ZStone and that of ZCE cannot be deployed in the same cluster at the same time.
- ZCE-iSCSI-CSI cannot be deployed again in a cluster where it has been deployed successfully.
- For a cluster where the deployment failed, it can be uninstalled and then deployed again.
- ZCE-iSCSI-CSI is deployed in the zstack-csi namespace by default. When the CSI is deployed, a storageclass named zaku-rbd is created at the same time, and PVCs can be created with this storageclass to use block storage volumes.
- You can view the detailed deployment logs on the operation log sub-page of the cluster details page.
ZCE-NFS-CSI
ZCE-NFS-CSI is used to connect Kubernetes to the file storage service of ZCE and provide persistent file storage for containers. After ZCE-NFS-CSI is deployed, the file storage of ZCE can be connected, and it can be used in the cluster by creating PVCs with the related storageclass.
Preparations
- An available ZCE storage service exists.
- The image and the chart of ZCE-NFS-CSI have been prepared in the management
cluster. You can follow the steps below:
- Contact official technical support to obtain the image and chart resource package of ZCE-NFS-CSI.
- Upload the obtained resource package to the third node of the management
cluster (the first node if it is not an HA cluster), and execute the
following command to install the resource package:
bash zaku-${k8s version}-${version}-all-in-one-addon-csi.bin. ${k8s version} and ${version} are the version of the k8s cluster and the version of the platform respectively. Enter them according to the actual name of the resource package. - The resource package needs to be uploaded to the management cluster only once, and then ZCE-iSCSI-CSI and ZCE-NFS-CSI can be installed in any cluster in this environment.
Deploying ZCE-NFS-CSI
In the ZStack Zaku main menu, click to enter the Cluster page. Click the name of the cluster to enter the cluster details page, and click Functional Component to enter the functional component sub-page. Click the Deploy button after ZCE-NFS-CSI in the functional component list, and the Deploy ZCE-NFS-CSI dialog box is displayed.
- Storage Service Access Token: enter the access token generated on the ZCE storage service console.
- NFS Share Address: enter the share addresses of the NFS
shares created in File Storage Management - File Share - NFS Share on the storage
service console, and enter each share address in each input box respectively.
Note:
- Different ZCE-NFS-CSIs need to use different NFS shares, so create an NFS share for each ZCE-NFS-CSI.
- When creating an NFS share on the ZCE storage service console, set the client group (V5) or the client IP (V6) to Every-Client.
- Storage Service Control Plane Node IP: obtain the IP addresses of the nodes with the management role from Resource Management - Node List on the storage service console, and enter the IP address of each control plane node in each input box respectively.
Note:
- The CSI of ZStone and that of ZCE cannot be deployed in the same cluster at the same time.
- ZCE-NFS-CSI cannot be deployed again in a cluster where it has been deployed successfully.
- For a cluster where the deployment failed, it can be uninstalled and then deployed again.
- ZCE-NFS-CSI is deployed in the zstack-csi namespace by default. When the CSI is deployed, a storageclass named zaku-share is created at the same time, and PVCs can be created with this storageclass to use file storage.
- You can view the detailed deployment logs on the operation log sub-page of the cluster details page.
Workload Auto-Scaling Component
The workload auto-scaling component is built on KEDA and includes core components such as the scaling controller, the metrics service and admission validation. It manages resource metrics, Prometheus metrics and scheduled scaling policies in a unified way, and provides unified and scalable automatic scaling capabilities for workloads. After the workload auto-scaling component is deployed, scaling rules can be configured for a workload on the Auto Scaling tab of the workload details page.
Deploying the Workload Auto-Scaling Component
In the ZStack Zaku main menu, click to enter the Cluster page. Click the name of the cluster to enter the cluster details page, and click Functional Component to enter the functional component sub-page. Click the Deploy button after the workload auto-scaling component in the functional component list, and the Deploy Workload Auto-Scaling Component dialog box is displayed.
Note:
- Only self-built clusters support deploying the workload auto-scaling component. This component is not displayed in the functional component list of an integrated cluster.
- The component is deployed in the zstack-autoscaling namespace by default. This namespace is reserved by the system and is not visible on the namespace page or other pages.
- If the system detects that workload auto-scaling (KEDA) related resources that are not deployed by the platform already exist in the current cluster, the deployment cannot be performed, so as to avoid cluster-level resource conflicts caused by duplicate deployment. Clean up the related resources and try again.
- If the system detects that a zstack-autoscaling namespace that is not created by the platform already exists in the cluster, the deployment cannot be performed, so as to avoid deployment conflicts or an impact on the existing resources in this namespace. Migrate the resources in it, delete the namespace and then try again.
- After the component is deployed successfully, it cannot be uninstalled manually currently. When the deployment fails, it can be deployed again or uninstalled.
Node Auto-Scaling Group
General
A node auto-scaling group is a core resource scheduling component adapted to Kubernetes clusters. It creates and deletes VM nodes automatically by connecting to a cloud platform, and then increases or decreases the number of cluster nodes dynamically according to the business load, which achieves an accurate match between the resource supply and the business requirements. It is a key tool to ensure the efficient and stable running of a K8s cluster.
How It Works
- Scaling out: when the system detects that the cluster resources are insufficient (there are pods to be scheduled), it filters out the eligible node auto-scaling groups automatically, creates VMs automatically through the cloud platform API according to the node configuration preset in the node auto-scaling groups (such as the computing specifications, the image, the network and the storage), and adds them to the cluster for pod scheduling after the initialization is completed.
- Scaling in: when the system detects that the cluster resources have been idle for a long time (for example, the CPU/memory request rate is continuously lower than 50%), it selects the eligible node auto-scaling groups automatically, migrates the schedulable pods on the target nodes through the native eviction mechanism of K8s first, and then removes the nodes and deletes the corresponding VMs at the same time to release the resources.
- Scaling group filtering: during the auto-scaling process, the system randomly selects a target group from all the node auto-scaling groups that meet the preset conditions to perform the corresponding operation.
Key Features
- Multi-dimensional trigger conditions. Scaling can be triggered based on the pod Pending state, the CPU/memory usage, etc.
- Compatible with the native rules of K8s. The node selector and the node affinity/anti-affinity configuration can be associated to ensure that the nodes scaled out meet the pod scheduling requirements.
- Graceful scaling mechanism. The schedulable pods on a node are evicted to other healthy nodes automatically before scaling in, which avoids business interruption. The built-in node health check replaces abnormal nodes automatically.
Typical Application Scenarios
- Periodic task scenarios: the computing load peaks in a fixed period every day (such as data processing during the morning rush hours and backup at night). The scaling group scales out according to the load metrics and scales in quickly after the tasks are completed, which improves the resource utilization.
- Burst traffic scenarios: an APP version update or a hot event causes a burst of access traffic. The scaling group scales out quickly through real-time load monitoring to avoid cluster overload, and scales in automatically when the traffic falls back without manual intervention.
- E-commerce promotion scenarios: the traffic surges during a promotion activity and the pod scheduling requests increase sharply. The scaling group triggers scaling out to supplement nodes, which ensures the normal running of the core services such as order placing and payment. After the activity ends, it scales in automatically, which reduces the cost of idle resources.
Usage Restrictions
- Clusters of Kubernetes 1.30 and later versions are supported.
- Only self-built clusters are supported. Integrated clusters are not supported.
- During auto scaling out, the total vCPUs of the nodes to be scaled out cannot exceed the available quota of the license.
- The nodes initialized when a cluster is created and the nodes added manually in the node list are not managed by a node auto-scaling group, and cannot be scaled in automatically.
Creating a Node Auto-Scaling Group
In the ZStack Zaku main menu, click to enter the Node Auto-Scaling Group page. Click Create Node Auto-Scaling Group to enter the Create Node Auto-Scaling Group page.
Creating a node auto-scaling group includes the following three steps:
- Basic configurationYou can refer to the following example to enter the required information:
- Scaling Group Name: set the name of the node auto-scaling group. Naming rules: the length is limited to 1 to 50 characters, and the input can contain only lowercase letters, digits and the special character "-". It must start with a lowercase letter and end with a digit or a lowercase letter.
- Description: optional. Add the related information.
- Minimum Number of Nodes: set the minimum number of nodes. The system ensures that the number of the nodes in the node auto-scaling group is never less than the minimum number of nodes.
- Maximum Number of Nodes: set the maximum number of nodes. During auto scaling out, the number of the nodes in the group does not exceed the maximum number of nodes set.
- Node Label: add node labels. The labels set are added to the nodes automatically during scaling out. Meanwhile, the system follows the node selector specified by a pod and the requiredDuringSchedulingIgnoredDuringExecution constraints in the node affinity, and considers only the node auto-scaling groups with the node labels that meet these constraints.
- Node configurationSet the node configuration. During auto scaling out, VMs are created on the cloud platform according to this node configuration. You can refer to the following example to enter the required information:
- Node Name Prefix: set the node name prefix. A node name consists of the node name prefix and a random number generated by the system automatically, and a VM name consists of the name of the k8s cluster and the node name.
- Zone of the VM: select a zone of the cloud platform, and the VMs are created in this zone.
- CPU Architecture: set the CPU architecture of the VMs.
- Operating System: select the operating system of the VMs.
- CPU: set the CPU size of the VMs.
- Memory: set the memory size of the VMs.
- Root Volume Capacity: set the root volume capacity of the VMs.
- Image Data Disk: optional. If there are many applications in the cluster and the images are large, it is recommended to add a data volume as the image data disk to store the image data.
- Network Configuration: select the L3 networks used by the
business network and the management network of the nodes, and the business network
is used as the default network of the VMs.
Note:
- Make sure that the L3 network used by the business network can communicate with the other nodes in the cluster.
- When the business network is reused as the management network of the cluster, make sure that the business network can be accessed by the management cluster.
- The management network needs to be set only when the business network is not reused as the management network of the cluster. In this case, the management network must use a network in the same network segment as the network of the management cluster.
- ROOT Password: set the password of the ROOT account of the VMs.
- SSH Port: set the port used to connect to the VMs over SSH. The default is 22.
- DNS Server: add DNS servers, which are used to resolve the domain names outside the K8s cluster. If no dedicated DNS server is deployed, you can enter the address of a public DNS server, such as 223.5.5.5.
- HA Mode: optional. Set the HA mode of the VMs. None and NeverStop are supported, and the default is None.
- VM Cluster: optional. Select a cluster of the cloud platform, and the VMs are created in this cluster. If it is not specified, the cloud platform allocates it automatically.
- Primary Storage of the Root Volume: optional. Set the primary storage used by the root volumes of the VMs. If it is not specified, the cloud platform allocates it automatically.
- Primary Storage of the Data Volume: optional. Set the primary storage used by the data volumes of the VMs. If it is not specified, the cloud platform allocates it automatically.
- Information confirmation
Confirm the configuration information of the node auto-scaling group. You can go back to modify it.
Managing Node Auto-Scaling Groups
In the ZStack Zaku main menu, click to enter the Node Auto-Scaling Group page.
| Operation | Description |
|---|---|
| Create Node Auto-Scaling Group | Add a node auto-scaling group to the cluster to scale nodes automatically. |
| Modify Basic Configuration | Modify the basic configuration of the node auto-scaling
group. Note: The basic configuration cannot be modified
when the status of the node auto-scaling group is abnormal. |
| Modify Node Configuration | Modify the node configuration of the node auto-scaling
group. Note:
|
| Fault Recovery | When auto scaling out fails repeatedly due to a cloud platform fault or a license overrun, the node auto-scaling group may become faulty. After the cause of the fault is located and handled, the node auto-scaling group can be recovered automatically through fault recovery. |
| Node Auto-Scaling Group Details |
|
| Delete Node Auto-Scaling Group | Delete the node auto-scaling group. Note: When a node auto-scaling group is deleted, the nodes
in the scaling group are removed and the VMs corresponding to the nodes are
deleted at the same time, which may cause the pods originally running on
the nodes to become abnormal due to insufficient resources. Perform this
operation with caution. |
Node
General
A node is a basic component of a Kubernetes cluster. Nodes are divided into control planes (Master) and compute nodes (Node). You can add compute nodes to a cluster or remove them from a cluster according to the actual requirements.
Adding a Node
Adding a node mainly means adding a compute node to a Kubernetes cluster to scale out the cluster.
Preparations
- Before adding a host to a cluster as a compute node, make sure that the customized operating system of ZStack Cloud has been installed on the host. Contact official technical support to obtain the customized operating system that matches the current platform version.
- Make sure that the NICs of the external networks corresponding to all the pod external network segments exist on the host, so as to ensure that the related network services run normally.
Adding a Node
In the ZStack Zaku main menu, click to enter the Node page. Click Add Node to enter the Add Node page.
Adding a node includes the following three steps:
- Node configurationYou can refer to the following example to enter the required information:
- Cluster Name: displays the name of the current cluster by default.
- Reuse the Business Network as the Management Network: displays whether the business network is reused as the management network in the current cluster by default. If it is enabled, the management network IPv4 address of a node is the same as its business network IPv4 address.
- Node Information: enter the information of the nodes
to be added.
- Adding Method: the method of adding nodes, including IP address and IP range.
- Business Network IPv4 Address: enter the business network IPv4 address of the node. Enter this field when the adding method is IP address.
- Management Network IPv4 Address: enter the management network IPv4 address of the node. Enter this field when the adding method is IP address. When the business network is reused as the management network, the management network IPv4 address is the same as the business network IPv4 address.
- Business Network IPv4 Range: enter the business network IPv4 range of the nodes. Enter this field when the adding method is IP range.
- Management Network IPv4 Range: enter the
management network IPv4 range of the nodes. Enter this field when the
adding method is IP range. When the business network is reused as the
management network, the management network IPv4 range is the same as
the business network IPv4 range.
Note:
- Make sure that the IP addresses entered are consistent with the actual configuration of the machines.
- Make sure that the management network IPv4 addresses and the management cluster are connected. When the business network is reused as the management network, make sure that the business network IPv4 addresses and the management cluster are connected.
- Make sure that the business network IPv4 addresses of the nodes are connected to each other.
- When the business network is not reused as the management network, make sure that the IP addresses in the management network IPv4 range correspond to those in the business network IPv4 range one by one. The IP addresses in the same order belong to the same node. For example, the 1st IP address in the business network IPv4 range and the 1st IP address in the management network IPv4 range belong to the 1st node.
- When nodes are added in batches, the management network IPv4 addresses of the nodes in this batch cannot be duplicated, and the business network IPv4 addresses of the nodes in this batch cannot be duplicated. When the business network is not reused as the management network, a management network IPv4 address and a business network IPv4 address cannot be duplicated.
- The management network IPv4 addresses and the business network IPv4 addresses of the nodes in this batch cannot be the same as those of the existing nodes in the cluster.
- Node Name: set the name of the node. Naming
rules: the length is limited to 2 to 45 characters, and the input can
contain only lowercase letters, digits and the separator (-). It must
start with a lowercase letter and cannot end with the separator. When
the adding method is IP range, a start suffix must be specified. The
node name consists of the name and the suffix, and the suffix
increases from the start suffix in turn, such as "-1/-2/-3".
Note:
- The hostname of a host is set to the node name during the process of adding the node.
- A node name cannot be the same as that of an existing node in the cluster.
- When nodes are added in batches, the names used by the nodes in this batch cannot be duplicated.
- Node Role: the default is compute node, and
GPU node is available.
Note:
- The corresponding components are installed automatically on a GPU node during the deployment process. Select whether to install a machine as a GPU node according to the actual situation.
- If GPU node is selected, make sure that the GPU driver has been installed correctly on the node. If the driver is not installed, only the corresponding components are installed and the node is not set to the GPU node role.
- GPU Manufacturer: this field must be entered
when GPU node is selected as the node role. Select the manufacturer of
the GPUs on the node, and the system installs the GPU-related
components of the corresponding manufacturer. Currently the following
manufacturers are supported: NVIDIA, Huawei, HYGON, Iluvatar and
Alibaba
Note: - The huawei NPU driver and related components require the system accounts HwHiAiUser and hwMindX, and UID/GID 1000 and 9000. A UID/GID conflict message means that UID/GID 1000 or 9000 on the listed nodes is already used by users or groups other than these huawei accounts.
- If huawei is selected as the GPU manufacturer, resolve the conflicts on the listed nodes and run the check again. You can continue only after the check passes.
- If huawei is not selected as the GPU manufacturer, you can acknowledge the risk and continue. However, resolve the conflicts before using huawei NPUs later, or the driver or related components may fail to install.
- Iluvatar GPU Virtualization License: this field must be entered when there is no Iluvatar GPU in the cluster yet and there is a GPU node whose GPU manufacturer is Iluvatar in this addition. Enter the license of Iluvatar GPU virtualization. This license is required to share Iluvatar GPUs in containers, and it is obtained from Iluvatar officially.
- Node ROOT Password: enter the password of the root account of the nodes, which is used to connect to the nodes over SSH to execute the installation steps during the process of adding the nodes. Make sure that the ROOT password of each node is the same.
- Node SSH Port: enter the port used to connect to the nodes over SSH, which is used to connect to the nodes over SSH to execute the installation steps during the process of adding the nodes. Make sure that this port of each node can be connected.
- DNS Server: add DNS servers to provide DNS resolution services and resolve the domain names outside the cluster. If no dedicated DNS server is deployed, you can enter the address of a public DNS server, such as 223.5.5.5.
- Advanced configurationYou can refer to the following example to enter the required information:
- Image Data Disk: optional. Select the image data disk used to store the image data. If no image data disk is set, the image data is stored on the system disk by default. When there are many large images in use, it is recommended to attach a dedicated disk to the node to store the images, so as to avoid the image data filling up the system disk and causing system exceptions.
- Configuration confirmation
Confirm the configuration information of the nodes. You can go back to modify it.
After you click OK, the system starts to add the nodes and the cluster status changes to Scaling. You can click to enter the Cluster page and view the progress of adding the nodes.
Note:
- Currently only compute nodes and GPU nodes can be added. Control plane nodes cannot be added.
- Nodes cannot be added when the cluster is in the Abnormal or Deleting state.
Managing Nodes
In the ZStack Zaku main menu, click to enter the Node page.
| Operation | Description |
|---|---|
| Add Node | Add a compute node to the cluster to scale out the
cluster. Note:
|
| Remove Node | Remove the node from the cluster. Note:
|
| disable schedule | After you disable scheduling for a node, newly deployed applications cannot be scheduled to it. You can perform this operation in batches for node maintenance. If Evict Existing Pods on the Node is not selected, running pods are unaffected. If it is selected, pods on the node are evicted, and pods managed by controllers are recreated on other eligible nodes. Note:
|
| enable schedule | After you enable scheduling for a node, newly deployed applications can be scheduled to it. You can perform this operation in batches, skip ineligible nodes, and continue processing the remaining nodes. Note:
|
| Edit label | Add, edit, or delete node labels. Note:
|
| Modify Role | Modify the role of a control plane node, and set it as a
compute node or cancel the compute node role.
Note:
|
| Terminal Connection | Connect to the node over SSH through the web terminal, so
that you can log in to the node and execute commands without using a
third-party tool. After you click Terminal
Connection, the node username, the node password and the node
SSH port (22 by default) must be entered to complete the authentication. After
the authentication is passed, the web terminal of the node is opened. Note:
|
| Node Details |
|
| Export Node Information | Export the node information as a CSV file. The current page and all can be exported. |
GPU Pool
A GPU pool is a resource sharing unit formed by aggregating multiple GPUs. It dynamically manages and allocates GPUs, improving resource utilization and making resource allocation more flexible.
Viewing the GPU Pool
In the ZStack Zaku main menu, click to enter the GPU Pool page.
- Monitoring charts: view GPU status, GPU memory utilization, GPU memory request rate, and GPU utilization in the selected cluster to understand the health and usage of its GPU resources.
Note: GPU status changes do not reduce the total GPU memory or total GPU count. Removing devices in the Dropout state reduces these capacity statistics accordingly. - GPU list: view each GPU's UUID, status, manufacturer, model, device address, node, scheduled/total schedulable pod count, GPU memory and its usage, temperature, and power consumption. You can filter the list by GPU status.
- Normal: the GPU is operating normally.
- Crashed: the GPU is present, but a fault has been detected.
- Unknown: the GPU status cannot be determined.
- Dropout: the previously used GPU is no longer detected.
Managing GPUs
GPUs support the following operations:
| Operation | Description |
|---|---|
| GPU Details | Click a GPU UUID to view its basic information, hardware information, real-time load, and scheduled pods. Monitoring charts are available for GPU utilization, GPU memory utilization, temperature, power consumption, fan speed, and PCIe transmit and receive throughput. Note: Available monitoring metrics depend on the GPU manufacturer and model. You can still query monitoring data collected before a device entered the Crashed or Dropout state. |
| Remove | Remove the record of a GPU in the Dropout state from the GPU pool. Note: Only GPUs in the Dropout state can be removed. A recovered device appears in the GPU pool again. |
GPU Scheduling Policy
GPU scheduling policies determine how GPU pods are distributed across nodes and across GPUs within a node.
In the ZStack Zaku main menu, click to enter the GPU pool page. Select a cluster, click the Scheduling Policy tab, and edit Default Scheduling Policy.
- node scheduling policy: determine how GPU pods are distributed across nodes. The default is binpack.
- spread: distribute pods across as many GPU nodes as possible while meeting their resource requirements.
- binpack: place pods on as few GPU nodes as possible while meeting their resource requirements.
- GPU Card Scheduling Policy: determine how GPUs are selected for GPU pods within the target node. The default is spread.
- spread: distribute pods across as many GPUs as possible while meeting their resource requirements.
- binpack: place pods on as few GPUs as possible while meeting their resource requirements.
Note: - GPU scheduling policies apply to NVIDIA, huawei, HYGON, and Alibaba GPUs. Iluvatar GPUs are not currently supported.
- Policies not configured for a workload or job use the cluster defaults. Policies configured for a workload or job take precedence over the cluster defaults.
- Changes affect only GPU pods created or rescheduled afterward. Running pods are not migrated automatically. During the change, GPU pods that are newly created, scaled out, recreated, or rescheduled may briefly wait for scheduling.
