Use ECS instances during off-peak hours and use elastic container instances to handle traffic spikes in Knative - Container Service for Kubernetes

When you use Knative to deploy an application, you can configure Knative to deploy pods on existing Elastic Compute Service (ECS) instances during off-peak hours and automatically create elastic container instances to handle traffic spikes. To do this, you can create a ResourcePolicy to specify the priorities of ECS instances and elastic container instances for scale-out activities. When scale-in activities are performed, ECS instances or elastic container instances are released based on the priorities specified by the ResourcePolicy in reverse order. In this case, elastic container instances are preferably released.

Knative is deployed in your cluster. For more information, see Deploy Knative in an ACK cluster or Deploy Knative in an ACK Serverless cluster.
The version of the kube-scheduler component in your cluster matches the following mappings.
Kubernetes version
kube-scheduler version
1.20
1.20.4-ack-7.0 or later
1.22
1.22.15-ack-2.0 or later
1.24
1.24.3-ack-2.0 or later
1.26
1.26.3-ack-4.0 or later
1.26 or later
All versions
The ack-virtual-node component is deployed. This component is required when you use elastic container instances. For more information, see Deploy ack-virtual-node in the cluster.
The kubeconfig file of the cluster is obtained and kubectl is used to connect to the cluster.

Limits

Priority-based resource scheduling is mutually exclusive with the pod deletion cost feature. For more information about the pod deletion cost feature, see Pod deletion cost.
You cannot use priority-based resource scheduling and Elastic Container Instance-based scheduling at the same time. For more information about Elastic Container Instance-based scheduling, see Use Elastic Container Instance-based scheduling.
This feature uses the BestEffort policy and does not ensure that pods are removed from nodes based on the priorities of the nodes in ascending order when the system scales in pods for an application.
The max parameter is available only when your cluster runs Kubernetes 1.22 or later and the version of the scheduler installed in your cluster is 5.0 or later.
If you use this feature together with elastic node pools, invalid nodes may be added to the elastic node pools. Make sure that the elastic node pools are included in units. Do not specify the max parameter for the units.
If you use a scheduler version earlier than 5.0 or the Kubernetes version of your cluster is 1.20 or earlier, pods that already exist before the ResourcePolicy is created are prioritized during a scale-in activity.
If you use a scheduler version earlier than 6.1 or the Kubernetes version of your cluster is 1.20 or earlier, do not modify the ResourcePolicy before all pods selected by the ResourcePolicy are deleted.

Procedure

Create a ResourcePolicy to specify the priorities of different elastic resources. In this example, ECS instances have a higher priority than elastic container instances. When ECS instances are insufficient or the number of pods deployed on ECS instances reaches the upper limit, elastic container instances are created to host pods. When the application is scaled in, elastic container instances are preferably released.

Create a Knative Service.

The following sample code is used as an example:

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: helloworld-go
spec:
  template:
    spec:
      containers:
      - image: registry-vpc.cn-beijing.aliyuncs.com/knative-sample/helloworld-go:73fbdd56
        env:
        - name: TARGET
          value: "Knative"

Create a ResourcePolicy and specify the max and nodeSelector parameters for each node resource. The max parameter specifies the maximum number of pods that can be deployed on the current elastic resource.
The following sample code is used as an example. The following sample describes how ECS instances are prioritized for pod scheduling. When the number of pods deployed on ECS instances reaches the upper limit specified by max or ECS instances are insufficient, elastic container instances are automatically created to host pods.
```
apiVersion: scheduling.alibabacloud.com/v1alpha1
kind: ResourcePolicy
metadata:
  name: xxx
  namespace: xxx
spec:
  selector:
    serving.knative.dev/service: helloworld-go # Specify the name of the Knative Service.
  strategy: prefer
  units: 
  - resource: ecs
    max: 10
    nodeSelector:
      key2: value2
  - resource: ecs
    nodeSelector:
      key3: value3
  - resource: eci
```

References

For more information about how to specify the priorities of elastic resources, see Configure priority-based resource scheduling.

Kubernetes version	kube-scheduler version
1.20	1.20.4-ack-7.0 or later
1.22	1.22.15-ack-2.0 or later
1.24	1.24.3-ack-2.0 or later
1.26	1.26.3-ack-4.0 or later
1.26 or later	All versions