Rollback & traffic split
Shift serving traffic to a prior Knative Revision by patching the NextApp CR.
Every kn-next deploy produces a new Knative Revision — an immutable snapshot of the pod
template. Knative keeps prior revisions around, so rolling back is never a rebuild: it is purely a
traffic decision. knext exposes that decision as a CR patch.
The CLI never touches the Knative Service, Route, or kn directly. kn-next rollback issues
exactly one cluster write — a merge-patch of the NextApp CR's spec.traffic — and the operator
renders that into the Knative Service's traffic targets.
kn-next rollback → kubectl patch nextapp … spec.traffic
operator → renders ksvc.spec.traffic
Knative Route → shifts revision trafficThe command
# Revert to the latest-ready revision (clear any pin)
kn-next rollback storefront
# Pin 100% of traffic to a specific prior revision
kn-next rollback storefront --to storefront-00002
# Canary: send 20% to latest-ready, 80% to the pinned revision
kn-next rollback storefront --to storefront-00002 --canary 20| Flag | Notes |
|---|---|
<app> | Positional, optional. Defaults to name from your kn-next.config. |
--to <revision> | Pin to a named Knative Revision (e.g. storefront-00002). Omit to revert to latest-ready. |
--canary <n> | Integer 0–100. Percentage sent to latest-ready; the remainder goes to the pinned revision. Rejected outside 0–100. |
-n, --namespace | Target namespace (default default). |
What gets patched
The TrafficSpec on the CR has two fields — revisionName and canaryPercent:
# kn-next rollback storefront --to storefront-00002
spec:
traffic:
revisionName: storefront-00002# kn-next rollback storefront --to storefront-00002 --canary 20
spec:
traffic:
revisionName: storefront-00002
canaryPercent: 20# kn-next rollback storefront (no --to)
spec:
traffic: null # cleared → operator emits no spec.traffic → 100% latest-readyHow the operator renders it
The operator maps spec.traffic to Knative traffic targets:
spec.traffic | Rendered ksvc.spec.traffic |
|---|---|
nil or empty revisionName | No traffic block — Knative serves 100% of latest-ready (pre-rollback default). |
revisionName set, canaryPercent is 0 (or ≥100) | One target: 100% to the pinned revision. |
revisionName set, canaryPercent in 1–99 | Two targets: (100−p)% to the pinned revision, p% to latest-ready. |
Observing the live split
The operator mirrors the Knative Service's observed traffic back into
NextApp.status.currentTraffic, so the live split is readable straight off the CR:
kubectl get nextapp storefront -o jsonpath='{.status.currentTraffic}'Each entry carries revisionName, percent, and latestRevision.
A pinned or canaried revision still serves its own static assets — knext never prunes the assets of a revision in the live traffic set. That is what makes a rollback safe for clients that already loaded the older build. See Skew protection.
Related
- Operator & the NextApp CRD — the
trafficspec field andcurrentTrafficstatus field. - Scale to zero — how revisions scale independently.
- Skew protection — why a rolled-back build keeps working.