Prerequisites

Using the traffic: block

The service was originally created without a traffic: block, which means that
it will automatically deploy the latest updates as they become ready. To split
traffic between multiple Revisions, we will start to use a customized traffic:
block. The traffic: block enables users to split traffic over any number of
fixed Revisions, or the floating “latest revision” for the Service. It also
enables users to name the specific sub-routes, so that they can be directly
addressed for qualification or debugging.

The first thing we will do is look at the traffic block that was defaulted for
us in the previous sample:

Fetch the state of the Service, and note the traffic: block that will run
the latest ready revision, each time we update our template. Also note that
under status: we see a specific revisionName: here, which is what it has
resolved to (in this case the name we asked for).

The release_sample.yaml in this directory overwrites the defaulted traffic
block with a block that fixes traffic to the revision
stock-service-example-first, while keeping the latest ready revision
available via the sub-route “latest”.

The spec of the Service should now show our traffic block with the
Revision name we specified above.

kubectl get ksvc stock-service-example --output yaml

Updating the Service

This section describes how to create a new Revision by updating your Service.

A new Revision is created every time a value in the template section of the
Service spec is updated. The updated_sample.yaml in this folder changes the
environment variable RESOURCE from stock to share. Applying this change
will result in a new Revision.

For comparison, you can diff the release_sample.yaml with the
updated_sample.yaml.

With our traffic block, traffic will not shift to the new Revision
automatically. However, it will be available via the URL associated with our
latest sub-route. This can be verified through the Service status, by
finding the entry of status.traffic for latest:

kubectl get ksvc stock-service-example --output yaml

The readiness of the Service can be verified through the Service Conditions.
When the Service conditions report it is ready again, you can access the new
Revision using the same method as found in the
previous sample using the
Service hostname found above.