Knative Serving extends Kubernetes with a higher-level way to deploy containers and manage traffic between application versions. A Knative Service creates and manages underlying Kubernetes resources, tracks changes as revisions, and lets multiple versions run at once. Its autoscaler can adjust capacity with demand, including scaling to zero. section 8.2 section 8.2.1
The immediate problem is release risk. Kubernetes Deployments, Services, and Ingresses can expose an application, but implementing traffic-aware release strategies with those resources requires manual, error-prone work. Knative Serving gives teams traffic controls they can use to try a new version before sending every request to it. section 8.0 section 8.1.4
Listing 8.1 Knative Service definition
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
name: notifications-service #1
spec:
template:
spec:
containers:
- image: salaboy/notifications-service:v1.0.0 #2
Env: #3
- name: KAFKA_URL
value: <URL>
A Knative Service definition names the service and specifies its container image and environment configuration. This is the starting point for deploying the Conference application's notifications service without maintaining separate resource definitions for its basic lifecycle. section 8.2.1
Traffic rules turn revisions into release options:
- For a canary-style rollout, assign percentages to an existing revision and the latest revision. The notifications-service example sends 50% to each; repeated requests can return either version. section 8.2.2
- For A/B testing, tag a revision to give it a version-specific URL while the original service URL continues serving the established version. Experimental tag-header-based routing can instead direct a request by HTTP header after an administrator enables the feature. section 8.2.2
- For blue/green deployment, keep the new revision at 0% of ordinary traffic under a tag, then change the declared percentages to move traffic to it. section 8.2.2
Check which revision answered
After deploying notifications-service, request its `/service/info` endpoint with `curl`. The response identifies the running version; with a 50/50 traffic rule, repeated requests show responses from both v1.0.0 and v1.1.0. This checks the routing behavior rather than merely confirming that the new revision exists. section 8.2.1 section 8.2.2
These controls reduce the resource and traffic-switching work needed for canary releases, blue/green deployments, and A/B testing. They are not the same as automated validation of a release: Argo Rollouts provides AnalysisTemplates for that purpose. Platform teams still need to choose which release mechanisms fit their workflows. section 8.4 section 8.5
