Manage Virtual Nodes
Manage Virtual Nodes
This document mainly introduces virtual nodes and BCI, and how to create BCI Pod by creating virtual nodes in CCE.
Virtual Node and Baidu Cloud Container Instance (BCI)
Baidu Cloud Container Instance (BCI) Provide serverless container resources. You can run the container only by providing the container image and the configuration parameters required to start the container, without worrying about how these containers are scheduled and deployed to the underlying physical server resources. The BCI service will complete the IaaS layer resource scheduling and operation for you, thereby simplifying your use of containers and reducing deployment and maintenance costs. Meanwhile, BCI will only charge for the resources you apply for when you create the container, thus achieving the real on-demand billing.
The virtual node Virtual Node is derived from the virtual-kubelet technology of the Kubernetes community, which realizes the scheduling of BCI instances in the CCE cluster, so that users can quickly start and schedule container without purchasing physical cluster nodes. The number of startup containers is not limited by the capacity of physical nodes, which gives the cluster great elastic scalability.
Preparation
- Register Baidu Account, and complete Identity Authentication.
- Enable Baidu Cloud Container Instance Service. Login Container Container Instance Console Enable the corresponding service.
- Create a container cluster. Refer to Create Cluster for operation steps.
Operation Guide
Create a virtual node
Log in to the CCE Management Console, click on the cluster to add a virtual node, select the virtual node tag in the left navigation bar, and click the button of Create Virtual Node on the page.
Note: If the user has not yet enabled the container instance service, the create button will be grayed out. You will be prompted to activate the container instance service when clicking the create button.
After clicking the create button, enter the virtual node creation page, and the related parameters are described as follows:
Basic information:The attributes of the virtual node are defined:
Parameter | Meaning | Comments |
---|---|---|
Virtual node name | The virtual node name will be displayed in the virtual node list and kubernetes node list on the page | The node names in the same cluster cannot be repeated |
CPU quota | CPU Quota of the virtual node, which limits the total amount of CPU of the BCI instance that can be scheduled on the virtual node | Explicit declaration is needed to enable the resource quota of the BCI Pod to take effect |
Memory usage limit | Memory Quota of the virtual node, which limits the total amount of BCI instance memory that can be scheduled on the virtual node | Explicit declaration is needed to enable the resource quota of the BCI Pod to take effect |
Container instance properties Defines the properties of the BCI instance launched on the virtual node:
Parameter | Meaning | Comments |
---|---|---|
VPC | VPC where the BCI instance is located | If the selected VPC is different from the VPC where the cluster is located, it may cause network address conflicts. For details, see Network conflict description |
Availability zone and subnet | Availability zone and subnet where the BCI instance is located | Only the availability zones and subnets where BCI instances can be created under the corresponding VPC are displayed |
Security group | Security group applied to BCI instance | - |
Click OK and redirect to the virtual node list page, where the newly added virtual node and its status will be displayed.
Manage virtual nodes
In the virtual node list, you can view the current status of the virtual node and the attribute information of the virtual node.
- Virtual node name: Virtual node name.
-
Virtual node status:
- Creating: The virtual node is being created. Generally, the creation does not last for more than one minute.
- normal The virtual node is Ready and you can schedule the Pod to the virtual node to start the corresponding BCI instance.
- Abnormal: The virtual node is NotReady, and you can check the corresponding virtual-kubelet to troubleshoot the cause of the exception.
- Deleting: After clicking the delete button, the virtual node status will change to deleting until the virtual node is completely deleted.
-
Operation:
- View virtual-kubelet: View the virtual-kubelet running status corresponding to the virtual node.
- Deletion: Delete the virtual node.
- How to use: Provide the Pod Spec field that needs to be specified to schedule Pod to the corresponding virtual node.
Delete virtual node
Click the delete button corresponding to the virtual node in the virtual node list. After confirming the virtual node to delete, click OK. The virtual node enters the deleting state until it is not visible in the list, which means the deletion is successful.
If you are prompted to prohibit deletion when deleting, please refer to Why can’t the virtual node be deleted.
FAQ
Why a network conflict is prompted when creating a virtual node
When creating a virtual node, select a VPC (called VPC B) other than the VPC where the cluster is located (called VPC A) as the container instance VPC, and the BCI instance running on the virtual node will run in the B VPC.
The address space of VPC A and VPC B may overlap. Meanwhile, the CCE cluster container network will also occupy a segment of the address outside the A VPC address space as the container network segment. This segment of address may also overlap with the address space of VPC B. Therefore, the IP address of the BCI Pod represents the corresponding network address in VPC B, and there may be another entity in VPC A that has the same IP address. Then, if the IP address of the BCI instance is accessed in the cluster, the object actually accessed is not the BCI instance, but a network entity in VPC A with the same IP address. In this case, unexpected access results may occur.
That is, in the following figure, the traffic that accesses 172.16.0.3 in VPC A will not go to the BCI instance through the dashed path, but to the other Pod in the cluster through the solid path.
If you fully understand the problems that this scenario may bring, there are still business scenarios that need to schedule container instances in VPC B, and you can continue to create them.
We strongly recommend that the CCE cluster only schedule BCI instances in the same VPC as the cluster.
Why can't a virtual node be deleted
When there are still running BCI instances located on a certain virtual node, CCE does not allow deleting the virtual node, because deleting the virtual node directly may cause the leakage of the BCI instance running on the virtual node.
Normally, we don't need to delete virtual nodes. Virtual nodes are different from real nodes and will not occupy cluster computing resources. If the user needs to delete a virtual node, we recommend manually stopping the Pod running on the virtual node, or expelling all Pods on the virtual node.
To expel the Pod on the virtual node, you can use the Kubectl Command Line Tool to execute the following command, assuming the name of the virtual node to delete is bci-virtual-kubelet -0
:
$ kubectl drain bci-virtual-kubelet-0 --force