Upgrade Readiness
The Upgrade Readiness tab answers one question: if I take this cluster to the next minor, what breaks?
The layout is a ledger. A verdict strip and a six-gate strip stay pinned at the top; everything else lives behind five sub-tabs — Overview, What breaks, Plan, Findings, Add-ons — so the page stays about one screen tall instead of a long scroll of cards.
The six gates
Section titled “The six gates”Findings are grouped by failure mode, not by severity, because failure mode is what you plan around.
| Gate | What lands here |
|---|---|
| Add-ons | Installed add-ons whose version has no support statement for the target minor. These break first, and they break hard. |
| Nodes & skew | Nodes and node components that would fall more than one minor behind the control plane after this hop, plus kubelet and container-runtime changes. |
| APIs & CRDs | Removed or deprecated API versions, CRDs and volume plugins that something in the cluster still submits. |
| Config & gates | Component flags, config-file fields and feature gates the target release removes. The API keeps working; the process does not start. |
| Dashboards | Metric and label renames in the path. Nothing crashes, but your dashboards and alert rules go quiet. |
| Workload hygiene | Workload-level hygiene, manifest-validation changes, and the remaining upgrade advisories. |
The partition is total: every finding lands in exactly one gate, and the gate counts
always sum back to the finding count. Workload hygiene is a deliberate catch-all rather
than an “other” bucket, so a newly published rule shows up somewhere instead of disappearing.
Cross-axis: security overlap
Section titled “Cross-axis: security overlap”A seventh grouping appears when the two risk axes intersect: workloads that both block this upgrade and carry unresolved CVEs. Fix or replace them once, not twice. This is the “fix-first” list, and it is the reason the two axes are scored on the same workload identity.
Add-ons
Section titled “Add-ons”Add-ons are tracked against their own compatibility catalogs, separately from core Kubernetes API deprecations — an add-on can be perfectly valid against the API and still have no supported release for your target minor.
From the CLI
Section titled “From the CLI”rtz risk # includes upgrade-axis findingsrtz risk --fail-on high # exits 4 at or above the threshold