Creating and using Subroutes

Subroutes are most effective when used with multiple revisions. When defining a Knative service/route, the traffic section of the spec can split between the different revisions. For example:

  1. traffic:
  2. - percent: 0
  3.   revisionName: foo
  4. - percent: 40
  5.   revisionName: bar
  6. - percent: 60
  7.   revisionName: baz

This allows anyone targeting the main route to have a 0% chance of hitting revision foo, 40% chance of hitting revision bar and 60% chance of hitting revision baz.

Using tags to create target URLs

The spec defines an attribute called tag. When a tag is applied to a route, an address for the specific traffic target is created.

  1. traffic:
  2. - percent: 0
  3.   revisionName: foo
  4.   tag: staging
  5. - percent: 40
  6.   revisionName: bar
  7. - percent: 60
  8.   revisionName: baz

In the above example, you can access the staging target by accessing staging-<route name>.<namespace>.<domain>. The targets for bar and baz can only be accessed using the main route, <route name>.<namespace>.<domain>.

When a traffic target gets tagged, a new Kubernetes service is created for it so that other services can also access it within the cluster. From the above example, a new Kubernetes service called staging-<route name> will be created in the same namespace. This service has the ability to override the visibility of this specific route by applying the label networking.knative.dev/visibility with value cluster-local. See cluster local routes for more information about how to restrict visibility on the specific route.

Feedback

Was this page helpful?

Glad to hear it! Please tell us how we can improve.

Sorry to hear that. Please tell us how we can improve.