knext

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 traffic

The 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
FlagNotes
<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, --namespaceTarget 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-ready

How the operator renders it

The operator maps spec.traffic to Knative traffic targets:

spec.trafficRendered ksvc.spec.traffic
nil or empty revisionNameNo 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–99Two 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.

On this page