Container Service for Kubernetes:Configure reserved instances for Knative Services to reduce cold start latency

How it works

When a Knative Service scales to zero, the first incoming request triggers a cold start: resource scheduling, image pulling, and application startup must all complete before the request is served.

Reserved instances change this behavior by keeping one or more low-specification pods running during idle periods:

1. Scale-in with a safety net. When traffic ceases, the Service scales in, but at least one reserved instance stays online to handle potential new requests.

2. Parallel response and scale-out. When a request arrives, two things happen simultaneously:

   • The request is routed to the active reserved instance for immediate processing -- no cold start.

   • Knative creates standard-specification instances to handle ongoing traffic.

3. Traffic handover. Once the first standard instance is ready, all subsequent traffic is routed to it.

4. Cleanup. After the reserved instance finishes processing its initial request, it is automatically terminated.

Prerequisites

Before you begin, make sure that you have:

• Knative deployed in your ACK cluster.

• ACK Virtual Node installed (required for ECI and ACS reserved instances; not required for ECS). For more information, see Components.

Annotation reference

Enable reserved instances by adding annotations to your Knative Service manifest. The following table lists all supported annotations.

Configure a reserved instance pool

To handle high burst traffic, expand a single reserved instance into a resource pool by specifying the number of replicas with the knative.aliyun.com/reserve-instance-replicas annotation.

The following example creates a reserved pool of 3 low-specification instances:

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: hello-reserve-pool
spec:
  template:
    metadata:
      annotations:
        knative.aliyun.com/reserve-instance: enable
        knative.aliyun.com/reserve-instance-replicas: "3"
        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:160e4dc8

Verify the configuration

After applying the Service manifest, verify that the reserved instance is running:

# Check if the reserved instance pod is running
kubectl get pods -l serving.knative.dev/service=<your-service-name>

# View the annotations on the Knative Service
kubectl get ksvc <your-service-name> -o yaml | grep reserve-instance

A successfully configured reserved instance remains in Running state even when no traffic is being served.

Apply in production

• Choose the right specification. Select the lowest-cost instance type for your reserved instance that can reliably run your application and serve at least one request.

• Use a reserved pool for high bursts. If your service is likely to experience sudden, high-traffic events, configure a reserved instance pool to better absorb the initial load.

Billing

Reserved instances run continuously and incur charges. See the following for details:

• Elastic Container Instance billing

• ACS billing

• ECS billing

• GPU billing

References

• Use cost-effective spot instances in Knative

• To implement automatic workload scaling in Knative, see Use HPA in Knative, Automatically scale Services based on the number of traffic requests, and Use AHPA to implement scheduled auto scaling.