By default, the open source version of Knative scales the number of instances to zero during off-peak hours to reduce the costs. However, a cold start with a latency occurs the next time you start an application. To avoid the cold start latency, we recommend that you use the reserved instance feature provided by ACK Serverless Knative to reserve a low-specification burstable instance. This helps you balance the costs and efficiency.
Why use the reserved instance
How open source Knative works
By default, the open source version of Knative scales the number of instances to zero if no request needs to be processed to reduce the costs of instances. When the next request arrives, the application is allocated to a new instance. The system must first allocate infrastructure resources by using the Kubernetes scheduler, then pull the application image and start up the application. The image size of an application and the time required to start up an application vary based on the requirements of services. Container Service for Kubernetes (ACK) does not have control over the image size and startup time. Although this approach reduces costs, it results in a cold start with latency when the application starts.
How ACK Serverless Knative works
If you want to reduce costs by using Knative and avoid cold starts at the same time, we recommend that you use the reserved instance feature provided by ACK Serverless Knative to balance costs and cold start latency. Unlike open source Knative, ACK Serverless Knative does not scale the number of instances to zero during off-peak hours. Instead, it reserves a low-specification and low-cost instance.
You can use the reserved instance to replace compute-optimized instances during off-peak hours. When the reserved instance receives a request, it processes the request and starts to create compute-optimized instances. After the compute-optimized instances are created, all new requests are forwarded to these instances. The reserved instance is released after it processes all requests that are sent to it. This seamless switchover mechanism better balances the cost, efficiency, and cold start latency.
Why use a burstable instance as the reserved instance
Alibaba Cloud Elastic Container Instance provides Burstable Instances. Burstable Instances use CPU credits to ensure computing performance. The instances apply to scenarios where the CPU usage is low but bursts in CPU usage occur on occasion. A burstable instance keeps accumulating CPU credits upon creation and consumes these credits to improve computing performance when it fails to handle a heavy workload. This mechanism does not affect the environment or applications running on the instance. Compared with other types of instances, a burstable instance provides a more flexible and cost-effective way to use CPU resources.
The cost-effectiveness and CPU credit features make burstable instances appropriate reserved instances for ACK Serverless Knative. The default types of reserved instances include ecs.t6-c1m1.large, ecs.t5-lc1m2.small, ecs.s6-c1m2.small, ecs.t6-c1m2.large, and ecs.n1.small. They are the lowest-priced instance types among all instance types that have at least 1 CPU core and 2 GB of memory. For more information about the elastic container instance types and prices, see Elastic Container Instance price calculator.
You can configure up to five instance types for an elastic container instance.
Configure a reserved instance
You can manually configure the type of the reserved instance using the annotation, including specifying the type of elastic container instance and specifying CPU cores and memory.
knative.aliyun.com/reserve-instance: Set toenableto indicate that the reserved instance feature is enabled.knative.aliyun.com/reserve-instance-eci-use-specs: Configure the specifications of the reserved instance.
Specify the type of elastic container instance
In the following example, ecs.t6-c1m1.large and ecs.t5-lc1m2.small are specified.
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
name: hello-spec-1
spec:
template:
metadata:
annotations:
knative.aliyun.com/reserve-instance: enable
knative.aliyun.com/reserve-instance-eci-use-specs: "ecs.t6-c1m1.large,ecs.t5-lc1m2.small"
spec:
containers:
- image: registry.cn-hangzhou.aliyuncs.com/knative-sample/helloworld-go:160e4dc8Specify CPU cores and memory
ACK Serverless Knative automatically searches for instance types that meet the requirements and uses the five lowest-priced instance types to create instances. In the following example, 1 CPU core and 2 GB of memory are specified.
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
name: hello-spec-2
spec:
template:
metadata:
annotations:
knative.aliyun.com/reserve-instance: enable
knative.aliyun.com/reserve-instance-eci-use-specs: "1-2Gi"
spec:
containers:
- image: registry.cn-hangzhou.aliyuncs.com/knative-sample/helloworld-go:160e4dc8References
For more information about basic concepts and usage instructions of burstable instances, see Overview.
You can use preemptible instances in Knative for cost efficiency. For more information, see Use Knative with preemptible instances.
You can implement auto scaling for workloads in Knative. For more information, see Use HPA in Knative, Enable auto scaling to withstand traffic fluctuations, and Use Knative and AHPA to implement RPS-based scheduled scaling.