Billing Mode
Pods scheduled on super nodes support two billing modes: prepaid and postpaid (pay-as-you-go and spot pricing).
Kubernetes Versions
Pay-as-you-go super nodes are supported by clusters on v1.16 or later.
Annual and monthly subscription super nodes currently support the highest minor versions of v1.18, v1.20, and v1.24 clusters.
Specifications of Pods Schedulable to Super Nodes
The resource specifications of Pods on super nodes are the basis for available resources during container runtime and service billing. It is essential to understand the resource specifications of Pods on super nodes. Different billing modes for super nodes support different schedulable Pod specifications.
Monthly Subscription Mode
Supports scheduling Pods with standard specifications ranging from 1C to 8C.
Supports scheduling Pods with CPU values greater than 1/4 of the memory values.
List of specifications supported by nodes:
Note
For nonstandard Pods, their specifications are automatically upgraded.
CPU/Core | Memory Range (GiB) | Granularity of Memory Range (GiB) |
1 | 1 - 4 | 1 |
2 | 2 - 8 | 1 |
4 | 8 - 16 | 1 |
8 | 16 - 32 | 1 |
Pay-as-You-Go Mode
0.25C–16C Pods are supported (for nonstandard Pods, their specifications are automatically upgraded).
Pods with a CPU to memory ratio of more than 1:8 are supported.
List of specifications supported by nodes:
Note
For nonstandard Pods, their specifications are automatically upgraded.
CPU/Core | Memory Range (GiB) | Granularity of Memory Range (GiB) |
0.25 | 0.5、1、2 | - |
0.5 | 1、2、3、4 | - |
1 | 1 - 8 | 1 |
2 | 4 - 16 | 1 |
4 | 8 - 32 | 1 |
8 | 16 - 32 | 1 |
12 | 24 - 48 | 1 |
16 | 32 - 64 | 1 |
32 | 64、128、256 | - |
64 | 128、192、256、512 | - |
Super Node Configuration
Pod Temporary Storage
When each Pod scheduled to a super node is created, a temporary image storage of 20 GiB will be allocated.
Note
Temporary image storage will be deleted when the Pod lifecycle ends. Therefore, do not store important data in it.
The actual available storage will be less than 20 GiB due to the stored images.
Annotations can be used to scale out system disk resources.
You are recommended to mount important data and large files to Volume for persistent storage.
Pod network
Pods scheduled on super nodes use a VPC network parallel to cloud servers, cloud databases, and other cloud products. Each Pod occupies a VPC subnet IP. Communication between Pods, and between Pods and other cloud products within the same VPC, occurs directly through the VPC network without performance loss.
Pod isolation
Pods scheduled to super nodes have the same security isolation as CVM instances. Pods are scheduled and created on the underlying physical server of Tencent Cloud, and the resource isolation between Pods is guaranteed by virtualization technology during the creation.
Other special configurations
You can define
template annotation in a YAML file to implement capabilities such as binding security groups, allocating resources, and allocating EIPs for Pods scheduled to super nodes. For configuration details, see the following table:Note
If no security group is specified, a Pod will be bound to the specified security group of the node pool by default. Make sure that the network policy of the security group doesn't affect the normal operation of the Pod. For example, you need to open port 80 if the Pod provides services via port 80.
To allocate CPU resources, you must specify the
cpu and mem annotations in line with the CPU specifications in Resource Specifications.To allocate GPU resources through the method specified by annotation, you must specify the
gpu-type and gpu-count annotations and ensure that their values meet the GPU specifications in Resource Specifications.Annotation Key | Annotation Value and Description | Required |
eks.tke.cloud.tencent.com/security-group-id | For the default security group bound to the workload, please enter the Security Group ID(s): Multiple IDs can be entered, separated by commas. For example, sg-id1,sg-id2. Network policies take effect in the order of the security groups. | No. If you don't specify it, the security group specified by the node pool is bound by default. If you specify it, make sure that the security group ID already exists in the same region. |
eks.tke.cloud.tencent.com/cpu | Number of CPU cores required by a Pod. For more information, see Resource Specifications. The unit is cores by default and doesn't need to be specified. | No. If you specify it, make sure that the specification is supported, and you need to enter the cpu and mem parameters. |
eks.tke.cloud.tencent.com/mem | Amount of memory required by a Pod. For more information, see Resource Specifications. You need to specify the unit, for example, 512 MiB, 0.5 GiB, or 1 GiB. | No. If you specify it, make sure that the specification is supported, and you need to enter the cpu and mem parameters. |
eks.tke.cloud.tencent.com/cpu-type | The required CPU resource model for Pods is currently available in the following models: Intel and AMD specific models, such as S4 and S3. For detailed configurations supported by each model, please refer to Resource Specifications. | No. If you don't specify it, the system will match the most suitable specification according to Specifying resource specifications. If the matched specification is supported by both Intel and AMD, the Intel specification is preferred. |
eks.tke.cloud.tencent.com/gpu-type | The GPU resource models required for Pods currently include the following: V100, 1/4 T4, 1/2 T4, and T4. The priority order can be written as "T4, V100", which means that a T4 resource Pod will be created first. If the available T4 resources in the selected region are insufficient, a V100 resource Pod will be created instead. For specific configurations supported by each model, please refer to the Resource Specifications. | It is required if you need a GPU. When specifying it, make sure that the GPU model is supported; otherwise, an error will be reported. |
eks.tke.cloud.tencent.com/gpu-count | Number of GPUs required by a Pod. For more information, see Resource Specifications. The unit is cards by default and doesn't need to be specified. | No. Make sure that the entered specification is supported. |
eks.tke.cloud.tencent.com/retain-ip | Pod Static IP: Set the value to "true" to enable this feature. For Pods with this feature enabled, the Pod's IP will be retained for 24 hours after the Pod is terminated. If the Pod is recreated within 24 hours, it can still use the same IP. After 24 hours, the IP may be taken by other Pods. This is only effective for StatefulSets and raw Pods. | Not required |
eks.tke.cloud.tencent.com/retain-ip-hours | Modifies the default retention period of a Pod's static IP. Enter a number. The unit is hours, and the default value is 24 hours. An IP can be retained for up to one year. It is valid only for StatefulSet and raw Pods. | Not required |
eks.tke.cloud.tencent.com/eip-attributes | This indicates that the Pods of the workload need to be associated with an EIP. When the value is "", it means that the default EIP configuration is used. You can fill in the EIP cloud API parameter JSON within "" to implement custom configurations. For example, if the annotation value is '{"InternetMaxBandwidthOut":2}', it means using a 2M bandwidth. Note that this is not available for non-bandwidth upgraded accounts. | Not required |
eks.tke.cloud.tencent.com/eip-claim-delete-policy | Indicates whether to repossess the EIP after the Pod is deleted. Never indicates not to repossess. The default value is to repossess. This parameter takes effect only when eks.tke.cloud.tencent.com/eip-attributes is specified. Note that this cannot be used for non-bill-by-IP accounts. | Not required |
eks.tke.cloud.tencent.com/eip-id-list | If the Workload is a StatefulSet, you can also specify one or multiple existing EIPs, such as "eip-xx1,eip-xx2". Note that the number of StatefulSet Pods must be less than or equal to the number of EIP IDs specified in this annotation; otherwise, Pods that cannot be allocated with EIPs will be in the "Pending" status. Note: this cannot be used for non-bill-by-IP accounts. | Not required |
Default Quota
When purchasing an annual or monthly subscription super node, a default quota will be allocated based on the total specifications. For pay-as-you-go super nodes, by default, each cluster can schedule up to 500 Pods on the super node. If you require resources exceeding the above quota, you can submit a quota increase application. Tencent Cloud will assess your actual needs, and upon approval, your quota will be increased.
Applying for a higher quota
1. Please submit a ticket, select Manual Support or Other Issues > Create Now to enter the ticket information submission page.
2. In the Problem description field, enter a description such as "I want to apply for a higher quota for the Pods of cluster super node." Specify the target region and quota. Enter your mobile number and other information as instructed.
3. Click Online consulting.
Pod Limits
Service limits
For cluster services in GlobalRouter mode, if externaltrafficpolicy = local, the traffic won't be forwarded to Pods scheduled to super nodes.
Volume limits
1. Supported volume types include EmptyDir, PVC, Secret, NFS, ConfigMap, Downward API, HostPath, GitRepo, ISCSI, DownwardAPI, Projected, CSI, and Ephemeral.
2. For PVC volumes:
PV Types: Supports NFS, CephFS, HostPath, and static CBS types; other types are not supported.
StorageClass types: Custom, /cloud.tencent.com/qcloud-cbs, com.tencent.cloud.csi.cbs, and com.tencent.cloud.csi.cfs are supported, while others are not.
GPU limits
You must specify the
gpu-type field in the annotation; otherwise, scheduling to super nodes is not supported. Different GPU Pod types come with different CPU and memory specifications, which don't need to be specified. If you need to specify them, make sure that they are identical to those supported by the GPU; otherwise, scheduling will fail.Other limitations
The super node feature is not available for clusters without any server nodes.
The Pods that have specified the hostIP will use the Pod IP as the value of hostIP by default.
Pods scheduled to super nodes are strictly isolated. If hard anti-affinity is enabled, scheduling to super nodes won't take effect, and it happens that multiple Pods of the same workload are scheduled to the same super node.
Pods in the
tke-eni-ip-webhook namespace cannot be scheduled to super nodes.