Feature | Description |
Security isolation | Elastic Container Instance provides a secure and reliable serverless runtime environment. Elastic container instances do not affect each other because the underlying computing resources of each elastic container instance are isolated by lightweight virtual sandboxes. Elastic container instances can be scheduled to run on different physical machines. This ensures high availability. |
Specify CPU and memory resources and instance specifications | Request and bill CPU and memory resources Configuration method: Specify CPU and memory resources for containers or pods Specify CPU and memory resources for containers: In the ACK console, you can specify CPU and memory resources for a container by setting resources.limit. If you do not set resource requests or limits, 2 vCPUs and 4 GiB of memory are allocated to each container. The amount of resources that are required by an elastic container instance refers to the total amount of resources that are required by all containers on the elastic container instance.
Important ACK will automatically change the specification of the elastic container instance if the specification cannot meet the resource demand. For example, if all containers on the elastic container instance request a total amount of 2 vCPUs and 3 GiB of memory, ACK changes the specification of the elastic container instance to 2 vCPUs and 4 GiB of memory. If the amount of memory requested by all containers exceeds 4 GiB, ACK will not change the specification of the elastic container instance. Specify CPU and memory resources for pods: You can specify CPU and memory resources for a pod by adding annotations. In this case, the CPU and memory resources required by an elastic container instance are not equal to the total amount of resources required by all containers on the instance. The elastic container instance is created and billed based on the specified amount of resources. If you use this method to specify CPU and memory resources, you do not need to set the resource request and resource limit for the containers in the pod. The containers can use computing resources to the maximum extent.
If the number of vCPUs or memory size that you specify is invalid when you create an elastic container instance, the system adjusts the number or size based on the specifications supported by Elastic Container Instance. When the system adjusts the number or size, the system selects the most similar specifications supported by Elastic Container Instance to create an elastic container instance, and the specifications selected by the system are higher than or equal to the specifications that you specified for the elastic container instance. For example, if you specify 7 vCPUs and 13 GiB of memory to create an elastic container instance, but these specifications are invalid, the system adjusts the number of vCPUs and memory size and selects 8 vCPUs and 16 GiB of memory that are supported by Elastic Container Instance to create an elastic container instance. CPU and memory specifications supported by Elastic Container Instance-based pods
Note Each elastic container instance support only one elastic network interface (ENI). If you do not specify the number of vCPUs and memory size, the system uses 2 vCPUs and 4 GiB of memory to create an elastic container instance by default.
Number of vCPUs | Memory size (GiB) | emptyDir volume (GiB) | Bandwidth (bidirectional, Gbit/s, theoretical upper limit) | Packet forwarding rate (bidirectional, Kpps, theoretical upper limit) | Number of ENI queues | 0.25 | 0.5 and 1 | 30 | 0.08 | 40 | 1 | 0.5 | 1 and 2 | 30 | 0.08 | 50 | 1 | 1 | 2, 4, and 8 | 30 | 0.1 | 50 | 1 | 2 | 1, 2, 4, 8, and 16 | 30 | 1 | 300 | 2 | 4 | 2, 4, 8, 16, and 32 | 30 | 1.5 | 500 | 2 | 8 | 4, 8, 16, 32, and 64 | 30 | 2 | 800 | 4 | 12 | 12, 24, 48, and 96 | 30 | 2.5 | 900 | 4 | 16 | 16, 32, 64, and 128 | 30 | 3 | 1000 | 4 | 24 | 24, 48, 96, and 192 | 30 | 4.5 | 1500 | 6 | 32 | 32, 64, 128, and 256 | 30 | 6 | 2000 | 8 | 52 | 96, 192, and 384 | 30 | 12.5 | 3000 | 32 | 56 | 224 | 30 | 10 | 4500 | 14 | 64 | 128, 256, and 512 | 30 | 20 | 4000 | 16 |
Billing methods and calculation formula Billing methods The billing of an Elastic Container Instance-based pod starts at the time when an external storage system is mounted to the elastic container instance or a container image is downloaded and ends at the time when the elastic container instance stops running (in the Succeeded or Failed state). Calculation formula Elastic Container Instance-based pod fee = (Number of vCPUs × vCPU unit price + Memory size of the elastic container instance × Memory unit price) × Uptime of the elastic container instance. The elastic container instance is billed on a per-second basis. Pricing
|
Specify ECS instance types for pods Configuration methods You can specify Elastic Compute Service (ECS) instance types to create elastic container instances with specific capabilities. For example, you can use the ecs.sn1ne instance family to create elastic container instances with enhanced network performance. For more information, see Overview of instance families and Pricing. Supported ECS instance families When you specify an ECS instance type to create an elastic container instance, the prices of the computing resources that the elastic container instance uses are calculated based on the specified ECS instance type. The following ECS instance families can be used to create elastic container instances: General-purpose instance families: g6e, g6, g5, and sn2ne Compute-optimized instance families: c6e, c6a, c6, c5, and sn1ne Memory-optimized instance families: r6e, r6, r5, se1ne, and se1 Compute-intensive instance family: ic5 Compute-optimized instance families with high clock speeds: hfc6 and hfc5 General-purpose instance families with high clock speeds: hfg6 and hfg5 GPU-accelerated compute optimized instance families: gn6i, gn6v, gn5i, and gn5 Big data instance family with enhanced network performance: d1ne Instance families with local SSDs: i2 and i2g Burstable instance families: t6 and t5 Shared performance instance families: s6, xn4, n4, mn4, and e4
Billing methods and calculation formula Billing methods When you specify an ECS instance type for an Elastic Container Instance-based pod, you can use a reserved instance to deduct the elastic container instance fee. For more information, see Overview. The elastic container instance fee after a reserved instance is applied is close to the fee of a subscription ECS instance. Calculation formula Elastic container instance fee = Unit price of the ECS instance type × Uptime of the elastic container instance. The elastic container instance is billed on a per-second basis.
|
Preemptible instances You can use preemptible instances by adding annotations. Using preemptible instances can significantly reduce the computing costs. For more information about preemptible instances, see Overview. For more information about the billing of preemptible instances, see Preemptible instances. |
Image pulling and image cache | Image pulling When an Elastic Container Instance-based pod starts, the containerd runtime of the pod pulls a container image from a remote image repository. To pull public images, you must configure a Network Address Translation (NAT) gateway for the virtual private cloud (VPC) where the Elastic Container Instance-based pod is deployed. You can also associate an elastic IP address (EIP) with the Elastic Container Instance-based pod. We recommend that you store container images in Container Registry to reduce the time that is required for pulling images through a VPC. In addition, you can pull private images from Container Registry without a password. This ensures high efficiency for image pulling. |
Image cache To accelerate the creation of elastic container instances, Elastic Container Instance provides the image cache feature. You can create a snapshot based on an image and then use the snapshot to create elastic container instances. This saves you the trouble of downloading images or reduces the image layers that you need to download, which accelerates the creation of instances. An image cache can be manually or automatically created. |
Storage | Elastic Container Instance supports the following storage methods: CSI: The Kubernetes community recommends the CSI plug-in. CSI consists of the following components: Network File System (NFS): For more information, see Example. Persistent volumes (PVs) and persistent volume claims (PVCs): For more information, see Example.
|
Networks | By default, Elastic Container Instance-based pods use the host network mode. Each pod is assigned an elastic network interface (ENI) by a vSwitch. In a Kubernetes cluster, you can use the following methods to enable an Elastic Container Instance-based pod to communicate with ECS instance-based pods. Attach Elastic Container Instance-based pods to LoadBalancer Services: You can attach both Elastic Container Instance-based pods and ECS instance-based pods to LoadBalancer Services. Access ClusterIP type Services: An Elastic Container Instance-based pod can access the IP address of a cluster. Associate EIPs with Elastic Container Instance-based pods: You can associate EIPs with Elastic Container Instance-based pods. You can enable an Elastic Container Instance-based pod to automatically create an EIP or associate an existing EIP with the Elastic Container Instance-based pod.
|
Log collection | You can set environment variables of an Elastic Container Instance-based pod to collect stdout files or log files and import them to Simple Log Service. In most cases, you do not need to deploy a sidecar container that works as Logtail. |
Annotation configurations | You can add annotations in the pod configurations to make full use of the features provided by Elastic Container Instance. For more information, see ECI Pod Annotation. |