Overview of general-purpose and performance-enhanced ACS pods - Container Compute Service

This topic describes the prerequisites, limits, and key features of Alibaba Cloud Container Compute Service (ACS) pods. The key features of ACS pods include security isolation, configurations for CPU, memory, and GPU resources, image pulling, storage, networking, and log collection.

Compute classes

ACS pods are classified into the following compute classes: general-purpose, performance-enhanced, and GPU-accelerated. The general-purpose and performance-enhanced compute classes are suitable for common computing scenarios. The GPU-accelerated compute class is suitable for heterogeneous computing scenarios. The resource supply for a pod varies based on the compute class of the pod.

Compute class	Label	Benefit
General-purpose (default)	general-purpose	This compute class is suitable for most stateful microservices applications, Java web applications, and computing tasks.
Performance-enhanced	performance	This compute class is suitable for scenarios that require higher performance, such as CPU-based AI and machine learning model training and inference and high-performance computing (HPC) batch processing.
GPU-accelerated	gpu	This compute class is suitable for heterogeneous computing scenarios such as AI and HPC scenarios. For example, you can use GPU-accelerated pods to perform inference on a one-pod-one-GPU basis or on a one-pod-multi-GPU basis. You can also use GPU-accelerated pods to run GPU parallel computing tasks.

To specify the compute class of a pod, add the alibabacloud.com/compute-class label to the pod. The following code block shows the sample code of an NGINX application that runs in general-purpose pods:

apiVersion: apps/v1 
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
        alibabacloud.com/compute-class: general-purpose 
    spec:
      containers:
      - name: nginx
        image: registry.cn-hangzhou.aliyuncs.com/acs-sample/nginx:latest

Computing power QoS

ACS supports two computing power quality of service (QoS) classes. The resource supply for a pod also varies based on the computing power QoS class of the pod.

QoS class	Label	Benefit	Scenario
Default	default	Computing power allocation may be unstable. ACS does not forcefully evict pods assigned the default computing power QoS class. If issues occur in a pod, ACS performs a hot migration to migrate the workloads in the pod to a new one or notifies you to manually trigger an eviction.	Microservice applications Web applications Computing tasks
BestEffort	best-effort	Computing power allocation may be unstable. ACS forcefully preempts and evicts pods in specific cases. ACS sends an event notification 5 minutes before it preempts or evicts a pod.	Big data computing Audio and video transcoding Batching processing

To assign a computing power QoS class to a pod, add the alibabacloud.com/compute-qos label to the pod. The following code block shows the sample code of an NGINX application that runs in pods assigned the default computing power QoS class.

apiVersion: apps/v1 
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
        alibabacloud.com/compute-qos: default
    spec:
      containers:
      - name: nginx
        image: registry.cn-hangzhou.aliyuncs.com/acs-sample/nginx:latest

Note

The computing power QoS classes defined by ACS are different from the pod QoS classes defined by Kubernetes. The default computing power QoS class in ACS corresponds to the Guaranteed pod QoS class in Kubernetes.

Mappings between compute classes and computing power QoS classes

Compute class (label)	Supported computing power QoS class (label)
General-purpose (general-purpose)	Default (default) and BestEffort (best-effort)
Performance-enhanced (performance)	Default (default)
GPU-accelerated (gpu)	Default (default)

Limits on Kubernetes

ACS is seamlessly integrated with Kubernetes based on virtual nodes. ACS pods are not collectively deployed on a physical machine, but are spread across Alibaba Cloud resource pools. Due to the purpose of public cloud security and the limits of virtual nodes, ACS does not support Kubernetes features such as hostPath volumes and DaemonSets. The following table describes the details.

Item	Description	Solution to validation failures	Recommended alternative
DaemonSet	DaemonSets are not supported.	Pods can run but cannot work as expected.	Deploy sidecar containers in the pod.
HostPath	hostPath volumes cannot be mounted to pods.	You cannot submit requests for mounting hostPath volumes.	Use emptyDir volumes, disks, or File Storage NAS (NAS) file systems.
NodePort Services	NodePort Services are not supported. NodePort Services can expose containers by using the ports on the host.	You cannot submit requests for creating NodePort Services.	Create `LoadBalancer` Services.
HostNetwork	The hostNetwork mode is not supported. The hostNetwork mode can expose containers by using the ports on the host.	Specify `HostNetwork=false` to disable the hostNetwork mode.	None
HostIPC	The hostIPC mode is not supported. The hostIPC mode can enable processes in containers to communicate with the processes on the host.	Specify `HostIPC=false` to disable the hostIPC mode.	None
HostPID	The hostPID mode is not supported. The hostIPC mode can enable processes in containers to access the process ID (PID) namespace on the host.	Specify `HostPID=false` to disable the hostPID mode.	None
HostUsers	User namespaces are not supported.	Leave the hostUsers parameter empty.	None
Linux capabilities	Only specific Linux capabilities (securityContext.capabilities) are supported. Note The following Linux capabilities are supported: CHOWN DAC_OVERRIDE FOWNER FSETID KILL SETGID SETUID SETPCAP NET_BIND_SERVICE NET_RAW NET_ADMIN SYS_CHROOT MKNOD AUDIT_WRITE SETFCAP	You cannot submit requests for enabling Linux capabilities not included in the preceding list.	Enable Linux capabilities included in the preceding list.
Sysctl	Only specific Kernel parameters (securityContext.sysctls) are supported. Note kernel.shm* (kernel.shm_rmid_forced is not supported) kernel.msg* kernel.sem* fs.mqueue.* net.* (net.ipv4.tcp_syncookies is not supported)	You cannot submit requests for configuring kernel parameters not included in the preceding list.	Configure kernel parameters included in the preceding list.
PrivilegeEscalation	Privilege escalation (securityContext.allowPrivilegeEscalation) is not supported.	You cannot submit requests for allowing privilege escalation.	Use the default setting.
Privileged Container	Privileged containers are not supported.	You cannot submit requests for creating privileged containers.	Specify the supported Linux capabilities and kernel parameters in the security context of the pod.
ImagePullPolicy	Only one image download policy is supported.	If you specify an image download policy that is not supported, ACS automatically replaces the policy with the `ImagePullPolicy=Always` policy.	Specify the supported image download policy.
DNSPolicy	Only specific DNS policies are supported. Note None Default ClusterFirst	If you specify the ClusterFirstWithHostNet policy, ACS automatically replaces the policy with the ClusterFirst policy. You cannot submit requests for configuring other DNS policies.	Specify the supported DNS policies.

Key features

Configuration item	Description
Security isolation	ACS pods provide a secure and reliable runtime environment for containers by running sandboxes at the underlying layer to isolate pods from each other. In addition, ACS preferentially schedules different pods to different physical machines to ensure the high availability of the pods.
CPU, memory, GPU, and ephemeral storage configurations	You can use Kubernetes standard definitions to configure CPU, memory, GPU, and ephemeral storage requests in the `resources.requests` parameter for each container. The resource request of a pod equals the sum of the resource requests of all containers that run in the pod. ACS automatically adjusts the resource request of a pod. You can use Kubernetes standard definitions to configure CPU, memory, GPU, and ephemeral storage limits in the `resources.limits` parameter for each container. The default resource limit of a container in a pod equals the sum of the adjusted resource requests of all containers that run in the pod.
Image	By default, each time an ACS pod is restarted, it pulls an image from a remote container registry through the virtual private cloud (VPC) where the pod is deployed. If the registry is publicly accessible, you must configure a NAT gateway for the VPC. We recommend that use Container Registry (ACR) to host container images. This can accelerate image pulling through VPCs. In addition, ACS allows you to pull private images from Container Registry without using Secrets.
Storage	ACS supports disk volumes and NAS volumes for data persistence. Cloud disk ACS supports only performance level 0 (PL0) Enterprise SSDs (ESSDs), ESSD AutoPL disks, and ESSD AutoPL Burst disks. You can select the preceding disk types based on your business requirements. For more information, see Disk volume overview. ACS allows you to dynamically provision disks as persistent volumes (PVs). For more information, see Mount a dynamically provisioned disk volume. NAS You can use statically provisioned NAS volumes to mount Capacity and Extreme NAS file systems as volumes. If you use dynamically provisioned NAS volumes, Capacity NAS file systems are mounted by default. For more information, see Details. ACS allows you to statically and dynamically provision disks as PVs. For more information, see NAS volume overview
Network	By default, each ACS pod is assigned a separate IP address and a separate elastic network interface (ENI) from a vSwitch. ACS pods use the following methods to communicate with each other: Pods use IP addresses to communicate with each other. A pod can use a LoadBalancer Service to access the backend pods of the Service. For more information, see Use an existing SLB instance to expose an application. A pod can use the cluster IP address of a ClusterIP Service to access the backend pods of the Service. For more information, see Create ClusterIP Services. After you associate an elastic IP address (EIP) with a pod, other pods can use the EIP to access the pod. For more information, see Associate an exclusive EIP with a pod.
Log collection	You can specify pod environment variables to collect `stdout` or log files from pods to Simple Log Service.

Resource specifications

General-purpose and performance-enhanced compute classes

vCPU	Memory (GiB)	Memory step size (GiB)	Maximum inbound and outbound bandwidth (Gbit/s)	Storage
0.25	0.5, 1, and 2	N/A	0.08	30 GiB to 512 GiB. You can expand the storage space by mounting NAS volumes.
0.5	1~4	1	0.08
1	1~8		0.1
1.5	2~12		1
2	2~16		1
2.5	3~20		1.5
3	3~24
3.5	4~28
4	4~32
4.5	5~36
5	5~40
5.5	6~44
6	6~48
6.5	7~52		2.5
7	7~56
7.5	8~60
8	8~64
8.5	9~68
9	9~72
9.5	10~76
10	10~80
10.5	11~84
11	11~88
11.5	12~92
12	12~96
12.5	13~100		3
13	13~104
13.5	14~108
14	14~112
14.5	15~116
15	15~120
15.5	16~124
16	16~128

The default resource request of a pod is 0.25 vCPUs and 0.5 GiB of memory.

If the request is not included in the preceding table, ACS automatically adjusts the resource request of a container. The adjustment does not change the value of the resources.requests parameter. However, the alibabacloud.com/pod-use-spec annotation is added to the pod configurations to indicate the adjustment. If the resource limit (resources.limits) of a container in a pod is greater than the resource request of the pod, ACS resets the resource limit of the container to the value of the resource request of the pod.

Note

If a pod requests 2 vCPUs and 3.5 GiB of memory, ACS adjusts the resource request to 2 vCPUs and 4 GiB of memory. The additional resources are allocated to the first container in the pod. The alibabacloud.com/pod-use-spec=2-4Gi annotation is added to the pod. In this case, if the resource limit of a container in the pod is 3 vCPUs and 5 GiB of memory, ACS resets the resource limit to 2 vCPUs and 4GiB of memory.

The following sample code provides an example on how to specify resource configurations:

apiVersion: apps/v1 
kind: Deployment
...
  template:
    metadata:
      labels:
        app: nginx
        alibabacloud.com/compute-class: general-purpose
        alibabacloud.com/compute-qos: default
    spec:
      containers:
      - name: nginx
        resources:
          requests:
            cpu: 2 # Request 2 vCPUs.
            memory: "4Gi" # Request 4 GiB of memory.
            ephemeral-storage: "30Gi" # Request 30 GiB of storage space.

GPU-accelerated compute class

GPU	vCPU	Memory (GiB)	Memory step size (GiB)	Maximum inbound and outbound bandwidth (Gbit/s)	Storage
1	2	2~16	1	2	30 GiB to 500 GiB. You can expand the storage space by mounting NAS volumes.
	4	4~32	1	4
	6	6~48	1	6
	8	8~64	1	8
	10	10~80	1	10
	12	12~96	1	12
	14	14~112	1	14
	16	16~128	1	16
2	16	16~128	1	16
2	32	32, 64, 128, and 230	N/A	32
4	32	32, 64, 128, and 256	N/A	32
4	64	64, 128, 256, and 460	N/A	64
8	64	64, 128, 256, and 512	N/A	64
8	128	128, 256, 512, and 920	N/A	100

The default resource request of a GPU-accelerated pod is 2 vCPUs, 2 GiB of memory, and 1 GPU.

Note

If a pod requests 2 vCPUs and 3.5 GiB of memory, ACS adjusts the resource request to 2 vCPUs and 4 GiB of memory. The additional resources are allocated to the first container in the pod. The alibabacloud.com/pod-use-spec=2-4Gi annotation is added to the pod. In this case, if the resource limit of a container in the pod is 3 vCPUs and 5 GiB of memory, ACS resets the resource limit to 2 vCPUs and 5GiB of memory.
If the GPU resource request of a pod is not included in the preceding table, the pod creation request cannot be submitted.

Port usage

The following table describes the ports used by ACS. Do not use the following ports for your applications.

Port	Description
111, 10250, and 10255	ACS clusters use the ports to perform the following operations: exec, logs, and metrics.