liveBook · Manning

Knative Revision

As explained in Platform Engineering on Kubernetes

A Knative Revision is an immutable version of a Knative Service configuration to which traffic can be routed.

A Knative Revision is an immutable version of a Knative Service configuration. Knative creates revisions from service changes and lets traffic route to a specific revision. section 8.2.1 section 8.2.2

Use revisions to control how application versions receive requests:

  • Route 100% of traffic to the latest revision by default. section 8.2.2
  • Split traffic across multiple revisions for canary releases, requiring percentages to total 100%. section 8.2.2
  • Assign tags to revisions for named routes, A/B testing, header-based routing, or blue/green deployment. section 8.2.2
  • Let Knative create and manage the underlying deployments, services, and pods instead of modifying them manually. section 8.2.1

Canary traffic split

Configure notifications-service with 50% routed to revision notifications-service-00001 and 50% routed to the latest revision; repeated curl requests can reach either running version. section 8.2.2

Listing 8.4 Changing our Knative Service
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: notifications-service 
spec:
  template:
    spec:
      containers:
        - image: salaboy/image: salaboy/notifications-service-0e27884e01429ab7e350cb5dff61b525:v1.1.0 #1
          env:
name: KAFKA_URLvalue: <URL>
  traffic:                                                                                            #2
  - percent: 50
    revisionName: notifications-service-00001
  - latestRevision: true
    percent: 50

Shows a Knative Service definition that sends half of the traffic to a named revision and half to the latest revision. section 8.2.2

How Platform Engineering on Kubernetes covers it

How deep it goes
Explains revision pointers, percentage rules, tags, headers, and rollback, but defers revision internals.
Examples
Demonstrates notifications-service revisions, curl responses, percentage splits, tags, and declarative blue/green switching.
What it assumes
Assumes a running Knative Serving installation, Kubernetes access through kubectl, and a deployed Knative Service.
What you can do after
Operate/configure controlled rollouts by editing Knative Service traffic rules and validating versions with curl.
How it connects
Connects Knative Service, traffic splitting, canary release, A/B testing, blue/green deployment, and Kubernetes resources.

Also explained in

Compare how 2 books explain Knative Revision →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Platform Engineering on Kubernetes. The section links point to the parts of the book it draws on.