Why Knative? Simplifying Serverless on Kubernetes with ASK Integration

Why use Knative

Kubernetes (K8s) provides core cloud‑native APIs (Service, Ingress, Pod, Deployment) and standard interfaces (CNI, CRI, CRD). Directly using these APIs for application delivery, gray releases, and autoscaling is complex and often leads to resource inefficiency. Knative abstracts these patterns, offering a simpler on‑demand model that reduces operational overhead and cost.

What is Knative

Knative is a Kubernetes‑based serverless orchestration platform that aims to become a cross‑platform standard for cloud‑native workloads. It integrates container image building, workload management, and event‑driven processing. The project is driven by contributors such as Google, Pivotal, IBM, Red Hat, and other PaaS vendors.

Knative consists of two core modules:

Eventing – event‑driven messaging framework.

Serving – workload management and traffic routing.

Traffic‑Based Gray Release

Kubernetes approach: Implementing a gray release requires separate Service, Deployment, HorizontalPodAutoscaler (HPA) resources and an Ingress rule that splits traffic between versioned Deployments (e.g., v1 and v2).

Knative approach: Create a single Knative Service. Each code change generates a new immutable Revision (Revision‑1, Revision‑2, …). Knative automatically creates the underlying Route, Configuration, and Revision objects and handles traffic splitting and autoscaling without additional user‑managed resources.

Knative Serving Architecture

A Knative Service abstracts the full serverless stack and is composed of:

Service – top‑level object that owns the lifecycle of the application.

Route – defines how incoming requests are directed to specific Revisions; supports weighted traffic splitting.

Configuration – stores the desired state (container image, env, resources). Updating the Service creates a new Configuration snapshot.

Revision – immutable snapshot of a Configuration; each Revision represents a version that can be routed to.

In essence, Knative Service ≈ Ingress + Service + Deployment + HPA.

Elastic Scaling Strategies in Knative

Traffic‑based autoscaling (KPA – Knative Pod Autoscaler).

CPU/Memory‑based autoscaling via standard HPA.

Scheduled scaling combined with HPA.

Event‑driven scaling through Knative Eventing.

Integration with Alibaba Cloud Serverless Kubernetes (ASK)

ASK provides a fully managed, serverless K8s experience that eliminates the need for pre‑provisioned Elastic Compute Instances (ECI). Users deploy containers without managing nodes, benefiting from:

No‑ops – no node provisioning or maintenance.

Extreme elasticity – pods can scale to 500 within 30 seconds.

Cost efficiency – on‑demand pod creation, Spot support, and reserved‑instance coupons.

K8s compatibility – supports Deployment, StatefulSet, Job, Service, Ingress, CRD, etc.

Storage integration – cloud disks, NAS, OSS.

Knative on ASK – traffic‑driven autoscaling with zero‑to‑one cold‑start avoidance.

Operational Complexity of Knative

Running Knative introduces three main operational concerns:

Gateway component (exposed entry point).

Control‑plane components – Activator, Autoscaler, Controller.

Cold‑start latency when the first pod is created.

ASK Solutions for Knative Operations

Replace the Knative Gateway with Alibaba Cloud SLB, reducing component count, cost, and improving stability.

Managed control‑plane: ASK provides a ready‑to‑use serverless framework, eliminating the need for users to install or maintain Knative control‑plane components.

Low‑ops deployment: Knative components are fused with the underlying K8s cluster, removing extra resource overhead.

High‑control upgrades: All components run in the managed control plane, simplifying version upgrades.

Graceful Reserved Instances

ASK offers reserved instances that remain at a low‑spec size when scaling to zero, effectively eliminating cold‑start delays while keeping costs low (up to 40 % cheaper than standard instances, with further savings when combined with Spot).

Hands‑On Demo Overview

The demo uses a coffee‑shop example to illustrate the following workflow:

Install Knative on an ASK cluster.

Deploy a coffee service as a Knative Service.

Access the service via its generated URL.

Enable a reserved instance to avoid cold starts for subsequent scaling events.

Demo video URL: https://developer.aliyun.com/live/246126