Configuring gradual rollout of traffic to Revisions

This might make the request queue too long, either at the QP or Activator, and cause the requests to expire or be rejected by the QP.

Knative provides a parameter, which can be used to gradually shift traffic to the latest Revision, preventing requests from being queued or rejected. Affected Configuration targets are rolled out to 1% of traffic first, and then in equal incremental steps for the rest of the assigned traffic.

Note

rollout-duration is time-based, and does not interact with the autoscaling subsystem.

You can configure the rollout-duration parameter by modifying the config-network ConfigMap, or by using the Operator.

ConfigMap configuration

Operator configuration

apiVersion: operator.knative.dev/v1alpha1
kind: KnativeServing
metadata:
  name: knative-serving
spec:
  config:
    network:
       rollout-duration: "380s"

During a rollout, the system updates the Route and Knative Service status conditions. Both the and conditions status parameters are affected.

Initially 1% of the traffic is rolled out to the Revisions:

kind: Service
metadata:
...
spec:
...
  traffic:
  - percent: 54
    revisionName: config-00008
  - percent: 1
  - percent: 45

Then the rest of the traffic is rolled out in increments of 18%:

The rollout continues until the target traffic configuration is reached:

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
...
spec:
...
  traffic:
  - percent: 55
    revisionName: config-00009
    revisionName: config-00005 # Pinned to a specific Revision.

During the rollout, the Route and Knative Service status conditions are as follows: