Overview of BestEffort computing

BestEffort instances run on the BestEffort Quality of Service (QoS) class in Alibaba Cloud Container Compute Service (ACS). Use them to reduce compute costs for short-term jobs and stateless workloads that are highly scalable and fault-tolerant.

Use cases

BestEffort instances work best for workloads that are stateless, elastic, highly distributed, and not latency-sensitive:

Scalable web services
Image rendering
Video and audio transcoding
Big data analytics
Large-scale parallel computing

Important

BestEffort instances have fluctuating performance and are preemptible and evictable. Avoid running stateful applications on them unless the application supports quick restart and uses an HA architecture. For stateful applications that require data security and business continuity, use instances with deterministic resources instead.

Note

GPU-HPN does not support BestEffort pods. For details, see What is ACS container compute power?

Prerequisites

Before you begin, ensure that you have:

An ACS cluster

Create a BestEffort instance

Log on to the ACS console. In the left-side navigation pane, click Clusters.
On the Clusters page, find the cluster you want to manage and click its ID. In the left-side navigation pane, choose Workloads > Deployments.
On the Deployments tab, click Create from Image.
On the Create page, specify Name, Replicas, Type, Label (optional), and Annotations (optional).
Set Instance Type to General-purpose and QoS Class to best-effort.

Note

For the remaining configuration steps, see Create a stateless application by using a Deployment.

Instance release

When a BestEffort instance runs out of resources, ACS releases it. Use the following methods to detect and respond to a release.

SpotToBeReleased event

ACS generates a BestEffortToBeReleased Kubernetes event 5 minutes before releasing a BestEffort instance.

To monitor this event, configure alert rules in the Simple Log Service console. For details, see Create and use an event center.

After receiving a BestEffortToBeReleased notification:

Check the scope of business impact.
Migrate important workloads to other instances.
Take disaster recovery or restoration measures to maintain business continuity.

To view the event in the pod details, run:

kubectl describe pod nginx-best-effort

The BestEffortToBeReleased event appears in the Events section of the output:

Events:
  Type     Reason                  Age    From     Message
  ----     ------                  ----   ----     -------
  Warning  BestEffortToBeReleased  3m32s  kubelet  Best Effort Instance will be released

To filter events by this reason, run:

kubectl get events --field-selector=reason=BestEffortToBeReleased

Output:

LAST SEEN   TYPE      REASON                  OBJECT        MESSAGE
3m39s       Warning   BestEffortToBeReleased  pod/pi-frmr8  Best Effort Instance will be released

Pod status after release

After ACS releases a BestEffort instance, it retains the instance information. The pod status changes to Failed with the reason Preempted.

Run the following command to view the pod status:

kubectl get pod nginx-best-effort

Output:

NAME                READY   STATUS      RESTARTS   AGE
nginx-best-effort   0/0     Preempted   0          3h5m

For more details, run:

kubectl describe pod nginx-best-effort

Output:

Status:   Failed
Reason:   Preempted
Message:  The pod is best-effort instance, and have been released at 2024-04-08T12:36Z

Best practices

BestEffort instances draw from a dynamic resource pool. In production, prioritize BestEffort instances and automatically fall back to the default QoS class when they are out of stock. Use a ResourcePolicy to configure this behavior.

The following example shows how to set up priority-based scheduling with automatic fallback for a Job.

Step 1: Create the Job.

The app: stress label associates the Job pods with the ResourcePolicy defined in the next step.

apiVersion: batch/v1
kind: Job
metadata:
  name: demo-job
  namespace: default
spec:
  parallelism: 3
  template:
    metadata:
      labels:
        app: stress # Associate the spec.selector configuration in the ResourcePolicy.
    spec:
      containers:
      - name: demo-job
        image: registry.cn-hangzhou.aliyuncs.com/acs/stress:v1.0.4
        args:
          - '30s'
        command:
          - sleep
        resources:
          requests:
            cpu: "1"
            memory: "1Gi"
          limits:
            cpu: "1"
            memory: "1Gi"
      restartPolicy: Never
  backoffLimit: 4

Step 2: Create a ResourcePolicy to prioritize BestEffort instances with fallback.

apiVersion: scheduling.alibabacloud.com/v1alpha1
kind: ResourcePolicy
metadata:
  name: rp-demo
  namespace: default
spec:
  # Pods that match the selector are scheduled based on this policy.
  selector:
    app: stress
  # The following configuration defines the priority order of resources.
  units:
  - resource: acs # Set the resource type to acs.
    podLabels: # First priority: general-purpose + best-effort resources.
      alibabacloud.com/compute-class: general-purpose
      alibabacloud.com/compute-qos: best-effort
  - resource: acs # Fallback: general-purpose + default resources when best-effort is out of stock.
    podLabels:
      alibabacloud.com/compute-class: general-purpose
      alibabacloud.com/compute-qos: default

The units field defines an ordered list of resource priorities:

The first entry targets general-purpose + best-effort instances.
The second entry targets general-purpose + default instances, used automatically when BestEffort capacity is exhausted.

For more scheduling options, see Custom resource scheduling policies.

Use cases

Prerequisites

Create a BestEffort instance

Instance release

SpotToBeReleased event

Pod status after release

Best practices

What's next