Elastic Container Instance (ECI) provides basic container runtimes for Kubernetes clusters. Each elastic container instance is a pod. ECI connects to Kubernetes clusters through virtual nodes built on Virtual Kubelet technology from the Kubernetes community.
Use cases
Burst workloads: Scale container workloads on demand without pre-provisioning node pools.
AI and ML jobs: Run GPU-accelerated training or inference tasks by specifying GPU-enabled ECS instance types.
Batch processing: Run stateless, fault-tolerant jobs using preemptible instances to reduce costs.
Microservices and APIs: Deploy containerized services with isolated networking and flexible storage options.
Pod configuration
Each pod has four core configuration areas:
Specifications
Define computing performance by specifying vCPU count and memory size. To use GPUs, local disks, or other hardware capabilities, specify an ECS instance type instead (for example, ecs.gn6i-c4g1.xlarge for GPU-accelerated workloads).
Container images
A pod supports up to 20 containers. To reduce pod startup time, use the image cache feature to avoid pulling images from the registry on every launch.
Networks
Each pod uses one elastic network interface (ENI) from a vSwitch in its virtual private cloud (VPC) and is assigned an internal IP address by default. To enable internet access—for example, to pull public images—associate an elastic IP address (EIP) with the pod or configure a NAT gateway on the VPC.
Storage
Each pod provides 30 GiB of temporary storage by default. To persist files beyond the pod lifecycle, mount external volumes such as File Storage NAS (NAS) file systems, Object Storage Service (OSS) buckets, or cloud disks.
Create a pod
Choose a creation method
Select a method based on your hardware requirements and billing preference:
| Method | Billed by | When to use |
|---|---|---|
| Specify vCPU count and memory size | vCPU and memory specifications | General-purpose workloads; the system selects a compatible instance type automatically |
| Specify an ECS instance type | The specified ECS instance type | Workloads that require specific hardware—GPUs, local disks, ARM, or x86 |
| Specify vCPU and memory with instance family filters | Actually used ECS instance type | Balance between flexible sizing and instance family constraints |
For the first method, if the exact vCPU and memory combination is unavailable, the system adjusts the specifications and bills based on the adjusted values. To control which instance families the system selects from, use the third method.
Pods default to the x86 architecture. To use ARM-based hardware, schedule pods to an ARM-based virtual node.
For detailed steps for each method, see the references in What's next.
Reduce costs
Combine pay-as-you-go instances with the following options to lower your bill:
Preemptible instances: Best for stateless and fault-tolerant workloads.
General-purpose savings plans: Apply to pods billed by vCPU and memory, as well as pods billed by ECS instance type.
ECS compute savings plans and reserved instances: Apply only to pods billed by ECS instance type. Use for long-running, stable workloads.
Handle resource unavailability
When creating large numbers of pods, resources in a single zone may be insufficient. To improve availability:
Specify multiple vSwitches across different zones.
Define multiple pod specifications so the system can fall back to an available configuration.
Pod lifecycle
Pods transition through different statuses during their lifecycle. ECI pod statuses map directly to Kubernetes pod statuses. For the full status reference, see Lifecycle of a pod.