Batch jobs and fault-tolerant workloads can be expensive to run continuously on on-demand instances. Preemptible instances let you run these workloads on Elastic Container Instance (ECI)-based Pods at significantly lower cost, with the Kubernetes Job controller automatically replacing any Pod that is reclaimed before the job completes.
Suitable workloads
Use preemptible instances for workloads that can tolerate interruption:
| Suitable | Not suitable |
|---|---|
| Batch jobs and one-off tasks | Stateful applications |
| Stateless, fault-tolerant applications such as scalable web services | Long-running services that cannot handle mid-task interruption |
| Short-lived compute tasks where restarts are acceptable | Workloads whose startup or shutdown time exceeds the 5-minute pre-release window |
How it works
When you create a preemptible instance, you specify a bid policy. The instance is created when your bid price exceeds the real-time market price and the resource inventory for that instance type is sufficient.
Protection period: After creation, the instance runs for a 1-hour protection period (default), billed at the market price at the time of purchase.
After the protection period: The system checks the market price and inventory every 5 minutes. If the market price exceeds your bid price, or inventory runs out, the instance is released. A SpotToBeReleased event is sent to the Kubernetes event list approximately 5 minutes before release — use this window to stop inbound traffic or checkpoint your workload.
Job continuity: When a Pod is released before the job completes, the Kubernetes Job controller automatically creates a new Pod to continue the job. The original Pod is retained with a BidFailed status.
Limitations
-
By default, the protection period is 1 hour.
-
After the protection period, instance availability depends on market price and resource inventory — there is no uptime guarantee.
-
The
SpotToBeReleasedevent arrives approximately 5 minutes before release. If your workload takes more than 5 minutes to shut down cleanly, preemptible instances may not be suitable.
Prerequisites
Before you begin, ensure that you have:
-
An ACK Serverless cluster
-
kubectlconfigured to connect to the cluster
Run a job on a preemptible instance
Step 1: Create the job manifest
Create a file named spot_job.yaml with the following content:
apiVersion: batch/v1
kind: Job
metadata:
name: pi
spec:
template:
metadata:
annotations:
k8s.aliyun.com/eci-use-specs: ecs.c5.large,2-4Gi # Multiple instance types improve creation success rate
k8s.aliyun.com/eci-spot-strategy: SpotAsPriceGo # Use the real-time market price as the bid price
spec:
containers:
- name: pi
image: registry-vpc.cn-beijing.aliyuncs.com/ostest/perl
command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"]
restartPolicy: Never
The k8s.aliyun.com/eci-spot-strategy annotation sets the bid policy:
| Value | Description |
|---|---|
SpotAsPriceGo |
Automatically uses the market price at the time of purchase as the bid price. |
SpotWithPriceLimit |
Uses a maximum hourly price that you set. Add the k8s.aliyun.com/eci-spot-price-limit annotation to specify the price. |
The k8s.aliyun.com/eci-use-specs annotation lists multiple instance types. Specifying multiple types improves the chance that a preemptible instance is created when inventory for one type is low.
Step 2: Create the job
kubectl create -f spot_job.yaml
Step 3: Monitor the Pod status
kubectl get pod
The Pod transitions through the following statuses:
Running — the job is in progress:
NAME READY STATUS RESTARTS AGE
pi-frmr8 1/1 Running 0 35s
Completed — the job finished successfully:
NAME READY STATUS RESTARTS AGE
pi-frmr8 0/1 Completed 0 2h
BidFailed — the Pod was released before the job completed. The Job controller has already created a new Pod (pi-kp5zx) to continue:
NAME READY STATUS RESTARTS AGE
pi-frmr8 1/1 BidFailed 0 4h53m
pi-kp5zx 1/1 Running 0 3h45m
A SpotToBeReleased event is emitted approximately 5 minutes before a Pod enters BidFailed. To view the event, run kubectl get events. For details on handling pre-release events, see Release of preemptible instances.
What's next
-
Create a preemptible elastic container instance — configure advanced bid policies and instance type selection strategies.