Knative Serving — Serverless and Event-Driven Workloads on Kubernetes

What it is

Knative Serving is the serverless sub-project of Knative, a CNCF incubating project started at Google. It layers request-driven autoscaling and traffic-splitting on top of Kubernetes, so teams can focus on container images instead of wiring Deployments, HPAs, Services, and Ingresses together.

Knative introduces a simple Service CRD that owns Configurations, Revisions, and Routes. It scales workloads from zero to thousands of pods based on concurrency or requests per second.

How it saves time or tokens

Knative Serving removes the boilerplate of configuring Kubernetes Deployments, HorizontalPodAutoscalers, Services, and Ingresses for each workload. A single Service CRD replaces all four resources. Scale-to-zero means idle workloads consume no resources, reducing infrastructure costs. Traffic splitting across revisions enables canary and blue/green deployments without a separate tool.

How to use

1. Install Knative Serving on an existing cluster:

kubectl apply -f https://github.com/knative/serving/releases/latest/download/serving-crds.yaml
kubectl apply -f https://github.com/knative/serving/releases/latest/download/serving-core.yaml
kubectl apply -f https://github.com/knative/net-kourier/releases/latest/download/kourier.yaml
kubectl patch configmap/config-network -n knative-serving \
  --type merge -p '{"data":{"ingress-class":"kourier.ingress.networking.knative.dev"}}'

1. Deploy a service:

kn service create hello \
  --image=ghcr.io/knative/helloworld-go:latest \
  --port=8080
kn service list

1. Split traffic between revisions for canary deployments:

kn service update hello --traffic hello-00001=80 --traffic hello-00002=20

Example

A Knative Service manifest with concurrency-based autoscaling:

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: api-backend
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/target: '100'
        autoscaling.knative.dev/minScale: '0'
        autoscaling.knative.dev/maxScale: '50'
    spec:
      containers:
        - image: myregistry/api-backend:v2
          ports:
            - containerPort: 8080
          resources:
            requests:
              cpu: 200m
              memory: 256Mi

Related on TokRepo

• DevOps tools — More Kubernetes and deployment tools on TokRepo.
• Featured workflows — Discover curated infrastructure tools.

Common pitfalls

• Cold start latency when scaling from zero can be problematic for latency-sensitive APIs. Set minScale to 1 for critical services.
• Not configuring the networking layer (Kourier, Istio, or Contour) correctly causes service URLs to be unreachable. Verify the ingress configuration after installation.
• Knative's default concurrency target of 100 may not suit all workloads. Profile your application and adjust the autoscaling target accordingly.