The Serverless Promise

• No server management or provisioning
• Automatic scaling -- including to zero
• Event-driven execution model
• Pay-per-use billing model

The Serverless Landscape

Cloud providers each built their own serverless:

But what if you want serverless without vendor lock-in?

The Lock-In Problem

• Proprietary APIs and event formats
• Vendor-specific deployment tooling
• Limited local development experience
• Hard to test, hard to move

What if serverless ran on standard Kubernetes?

What is Knative?

An open-source platform that brings serverless capabilities to Kubernetes.

• Originally created by Google, with contributions from IBM, Red Hat, VMware, and others
• Now a CNCF Incubating project
• Runs on any Kubernetes cluster -- AKS, EKS, GKE, on-prem
• Uses standard containers -- no proprietary runtime

Knative vs. Lambda vs. Azure Functions

Knowledge Check

Knative Components

Knative is made up of two main components:

Knative Architecture

         Developer
            |
      [kubectl / kn CLI]
            |
  +---------+---------+
  |                   |
  v                   v
Knative Serving   Knative Eventing
  |                   |
  v                   v
Activator         Broker/Trigger
Queue-Proxy       Sources/Sinks
Autoscaler        Channels
  |                   |
  +------- K8s -------+
  |   Networking Layer  |
  |  (Kourier / Istio)  |
  +---------------------+
    

Networking Layer

Knative needs a networking layer for traffic routing:

• Kourier -- Lightweight, Knative-specific ingress (recommended for simplicity)
• Istio -- Full service mesh with mTLS, observability
• Contour -- Envoy-based ingress controller

For AKS, Kourier is the simplest starting point. Upgrade to Istio when you need mTLS or advanced traffic policies.

Prerequisites for AKS

Before installing Knative on AKS, you need:

• An AKS cluster (Kubernetes 1.26+)
• kubectl configured to access the cluster
• kn CLI (optional but recommended)
• A container registry (ACR recommended)

# Verify cluster access
kubectl cluster-info
kubectl get nodes

# Install kn CLI
brew install knative/client/kn   # macOS
  

Installing Knative on AKS

Step 1: Install Knative Serving

# Install Knative Serving CRDs
kubectl apply -f https://github.com/knative/serving/releases/download/knative-v1.14.0/serving-crds.yaml

# Install Knative Serving core components
kubectl apply -f https://github.com/knative/serving/releases/download/knative-v1.14.0/serving-core.yaml

# Install Kourier networking layer
kubectl apply -f https://github.com/knative/net-kourier/releases/download/knative-v1.14.0/kourier.yaml

# Configure Knative to use Kourier
kubectl patch configmap/config-network \
  --namespace knative-serving \
  --type merge \
  --patch '{"data":{"ingress-class":"kourier.ingress.networking.knative.dev"}}'
  

Installing Knative on AKS

Step 2: Install Knative Eventing

# Install Knative Eventing CRDs
kubectl apply -f https://github.com/knative/eventing/releases/download/knative-v1.14.0/eventing-crds.yaml

# Install Knative Eventing core
kubectl apply -f https://github.com/knative/eventing/releases/download/knative-v1.14.0/eventing-core.yaml

# Install In-Memory Channel (for dev/testing)
kubectl apply -f https://github.com/knative/eventing/releases/download/knative-v1.14.0/in-memory-channel.yaml

# Install MT-Channel-Based Broker
kubectl apply -f https://github.com/knative/eventing/releases/download/knative-v1.14.0/mt-channel-broker.yaml
  

Verify the Installation

# Check Serving components
kubectl get pods -n knative-serving
NAME                                      READY   STATUS
activator-abcdef1234-xxxxx                1/1     Running
autoscaler-abcdef1234-xxxxx               1/1     Running
controller-abcdef1234-xxxxx               1/1     Running
webhook-abcdef1234-xxxxx                  1/1     Running

# Check Eventing components
kubectl get pods -n knative-eventing
NAME                                      READY   STATUS
eventing-controller-abcdef1234-xxxxx      1/1     Running
eventing-webhook-abcdef1234-xxxxx         1/1     Running

# Check Kourier
kubectl get pods -n kourier-system
  

Knowledge Check

Your First Knative Service

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: hello-world
  namespace: default
spec:
  template:
    spec:
      containers:
        - image: gcr.io/knative-samples/helloworld-go
          ports:
            - containerPort: 8080
          env:
            - name: TARGET
              value: "World"
  

Deploy and Access

# Deploy the service
kubectl apply -f hello-world.yaml

# Or use the kn CLI
kn service create hello-world \
  --image gcr.io/knative-samples/helloworld-go \
  --env TARGET=World

# Check the service
kn service list
NAME          URL                                        READY
hello-world   http://hello-world.default.example.com     True

# Access the service
curl -H "Host: hello-world.default.example.com" \
  http://$(kubectl get svc kourier -n kourier-system \
    -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
  

Watch It Scale to Zero

# Watch pods in real-time
kubectl get pods -w

NAME                                          READY   STATUS
hello-world-00001-deployment-abc123-xyz       2/2     Running

# ... 60 seconds of no traffic later ...
hello-world-00001-deployment-abc123-xyz       2/2     Terminating
hello-world-00001-deployment-abc123-xyz       0/2     Terminating

# Zero pods! Zero cost!

# Send another request...
curl http://hello-world.default.example.com
# Pod spins up automatically!
hello-world-00001-deployment-abc123-new       0/2     Pending
hello-world-00001-deployment-abc123-new       2/2     Running
  

How Scale-to-Zero Works

Request arrives at Kourier
        |
  [Is there a running pod?]
     /         \
   Yes          No
    |            |
  Route to   Route to Activator
   Pod        (holds request)
    |            |
  Response    Activator tells
              Autoscaler to
              scale up from 0
                 |
              Pod starts (cold start)
                 |
              Request forwarded to pod
                 |
              Response
    

The kn CLI

A developer-friendly CLI for Knative operations:

# Create a service
kn service create hello --image myregistry/hello:v1

# Update a service
kn service update hello --env TARGET=Knative

# List services
kn service list

# Describe a service
kn service describe hello

# Delete a service
kn service delete hello

# List revisions
kn revision list

# Show traffic routes
kn route list
  

Revisions: Snapshots of Your App

• Each Revision is an immutable snapshot of your code + config
• Named automatically: hello-world-00001, hello-world-00002, etc.
• Old revisions are kept (can be scaled to zero)
• Traffic can be split across revisions

Creating Revisions

# Update the service -- creates a new revision automatically
kn service update hello-world --env TARGET=Knative

# Check revisions
kn revision list
NAME                  SERVICE       TRAFFIC   READY
hello-world-00002     hello-world   100%      True
hello-world-00001     hello-world             True

# Each update = new revision
kn service update hello-world --env TARGET=Universe
kn revision list
NAME                  SERVICE       TRAFFIC   READY
hello-world-00003     hello-world   100%      True
hello-world-00002     hello-world             True
hello-world-00001     hello-world             True
  

Knowledge Check

Traffic Management Basics

Knative lets you split traffic between revisions:

# Send 80% to latest, 20% to previous revision
kn service update hello-world \
  --traffic hello-world-00003=80 \
  --traffic hello-world-00002=20

# Tag a revision for direct access
kn service update hello-world \
  --tag hello-world-00002=staging

# Access tagged revision directly:
# http://staging-hello-world.default.example.com
  

Traffic Splitting in YAML

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: hello-world
spec:
  template:
    spec:
      containers:
        - image: myregistry/hello:v3
  traffic:
    - latestRevision: true
      percent: 80
    - revisionName: hello-world-00002
      percent: 20
    - revisionName: hello-world-00001
      percent: 0
      tag: legacy
  

Tagged revisions get their own URLs even with 0% traffic -- great for testing!

Common Traffic Patterns

Knative Service Lifecycle

    Developer updates Service
            |
    Controller creates new Revision
            |
    Route updated with traffic rules
            |
    Pods created for new Revision
            |
    Health check passes
            |
    Traffic shifts to new Revision
            |
    Old Revision pods scale to zero
            |
    (Old Revision still exists for rollback)
    

Knative vs. Standard K8s Deployments

What's Coming Next

In the next module, we'll take a deep dive into Knative Serving:

• Service anatomy -- Configuration, Revision, Route
• Autoscaling deep dive -- KPA, concurrency, burst capacity
• Traffic splitting patterns -- canary, blue/green
• Custom domains and TLS
• Private services and container configuration

Module 2: Knative Serving Deep Dive

Key Takeaways

• Knative brings serverless to Kubernetes without vendor lock-in
• Two components: Serving (HTTP workloads) and Eventing (async events)
• Automatic scale-to-zero saves resources and costs
• Revisions give you immutable snapshots and easy rollbacks
• Traffic management is built-in -- canary and blue/green for free
• One YAML replaces Deployment + Service + Ingress

Your containers now have superpowers.