Deploy Serverless Apps with Knative on Alibaba ASK: Zero‑Cost Gateway & Reserved Instances

Why Knative and ASK?

The CNCF 2019 Serverless survey shows that 41% of respondents already use Serverless and 34% prefer Knative, making it the most popular open‑source Serverless project. Knative runs on top of Kubernetes and provides a higher‑level application model that requires only containerized workloads.

From Physical Machines to Serverless

Historically, applications were deployed on rented physical servers, leading to poor resource utilization and management challenges such as port conflicts, isolation, and dependency issues. Virtual machines solved many of these problems, and containers further reduced overhead by offering lightweight isolation and reproducible images. Kubernetes then abstracted IaaS resource allocation, allowing developers to focus on code rather than infrastructure.

Knative vs. Traditional Kubernetes Deployment

In a standard Kubernetes setup, users must manage an Ingress controller, maintain Service‑Ingress relationships, and perform multi‑deployment rollouts for gray‑release testing. With Knative, a single Knative Service resource replaces all of these, automatically handling traffic routing, gray releases, and autoscaling.

Kubernetes decouples IaaS and applications, focusing on resource orchestration, while Knative adds application‑level elasticity on top of that foundation.

ASK – Serverless Kubernetes

ASK (Serverless Kubernetes) eliminates the need to pre‑provision nodes. Users can create a Kubernetes cluster on demand, and the platform automatically allocates Elastic Container Instances (ECI) based on the CPU and memory requests of each Knative workload, charging only for actual usage.

Key Features

SLB‑Based Gateway : Alibaba Cloud SLB provides a highly available gateway without any resident instances, cutting IaaS costs.

Low‑Cost Reserved Instances : ASK introduces reserved burstable‑performance instances that stay running during traffic valleys, reducing cold‑start latency and saving up to 46% compared with standard compute instances.

Autoscaling : Knative’s KPA automatically scales pods based on request concurrency (default target = 10 requests per pod).

Demo Walkthrough

The following steps demonstrate a complete Knative workflow on ASK.

1. Deploy a simple coffee service

# cat coffee.yaml
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: coffee
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/target: "10"
    spec:
      containers:
      - image: registry.cn-hangzhou.aliyuncs.com/knative-sample/helloworld-go:160e4dc8
        env:
        - name: TARGET
          value: "coffee"

Apply the manifest: kubectl apply -f coffee.yaml Verify the service and obtain its unique sub‑domain:

# kubectl -n knative-serving get svc
NAME            TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
ingress-gateway LoadBalancer 172.19.8.35    47.102.220.35 80:30695/TCP 26h

Access the service via the SLB IP:

curl -H "Host: coffee.default.example.com" http://47.102.220.35

Response:

Hello coffee!

2. Observe automatic scaling

Check the initial pod count:

# kubectl get pod
NAME                                 READY   STATUS    RESTARTS   AGE
coffee-bwl9z-deployment-765d98766b-nvwmw   2/2     Running   0          42s

Run a load test with hey (30 s, 90 concurrent requests):

hey -z 30s -c 90 --host "coffee.default.example.com" "http://47.100.6.39/?sleep=100"

During the test Knative scales the pod count up; after the test it scales back down automatically.

3. Use a reserved burstable instance

Specify a reserved instance spec via annotation:

# cat coffee-set-reserve.yaml
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: coffee
spec:
  template:
    metadata:
      annotations:
        knative.aliyun.com/reserve-instance-eci-use-specs: "ecs.t5-c1m2.large"
        autoscaling.knative.dev/target: "10"
    spec:
      containers:
      - image: registry.cn-hangzhou.aliyuncs.com/knative-sample/helloworld-go:160e4dc8
        env:
        - name: TARGET
          value: "coffee-set-reserve"

Apply the manifest and verify the pod now runs on the reserved 2 CPU / 4 GB instance.

# kubectl get pod -o yaml | grep -i eci-instance-spec
k8s.aliyun.com/eci-instance-spec: ecs.t5-c1m2.large

4. Upgrade the service without downtime

Create a new revision with a different environment variable:

# cat coffee-v1.yaml
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: coffee
spec:
  template:
    metadata:
      name: coffee-v1
      annotations:
        autoscaling.knative.dev/target: "10"
    spec:
      containers:
      - image: registry.cn-hangzhou.aliyuncs.com/knative-sample/helloworld-go:160e4dc8
        env:
        - name: TARGET
          value: "coffee-v1"

Deploy the new revision: kubectl apply -f coffee-v1.yaml Verify the response changes to Hello coffee‑v1! while Knative seamlessly routes traffic from the old revision to the new one.

Conclusion

Knative is the most popular Serverless orchestration framework in the Kubernetes ecosystem, but the upstream project requires always‑on controllers and gateways, incurring extra IaaS costs. Alibaba’s ASK fully manages Knative Serving, providing a zero‑cost, SLB‑backed gateway and optional burstable‑performance reserved instances that dramatically reduce expenses during low‑traffic periods while preserving instant scalability for traffic spikes.

For deeper details, refer to the official Knative documentation, sample repositories, autoscaler configuration guides, and the ASK whitepaper "Serverless Kubernetes – Vision, Reality, and Future".