Skip to main content

Upgrade analysis

Upgrade analysis is an operation on the Cluster Mirror, and it's opt-in: the operator runs it only with upgrade.enabled=true in Helm. Turn it on when an upgrade is coming; the mirror itself keeps running either way.

The ClusterMirror knows what is running and at risk right now — what is down, pending or lost, and its blast radius. It has no target version. An UpgradeAnalysis names one, reads the same mirror against it, and adds what only an upgrade needs:

  • Add-on compatibility with the target version, from a vendor-verified matrix.
  • Removed APIs — the API versions the target version drops.
  • Drain blockers — a PodDisruptionBudget that would stall a node drain.
  • A readiness score (0–100) — a gauge, never a gate.
  • A deterministic verdict — SAFE, WARNING or CRITICAL, with every blocker listed.

This static illustration provides a quick visual summary of the same flow:

A static view of the upgrade analysis path from mirror and target version to the CLI gate.

Its report is an <name>.mirops file like the mirror's, and the CLI gates a pipeline on its verdict.

Risk on the same graph​

Upgrade analysis reuses the mirror's risk propagation, with one addition: now there is a target version, add-ons get a risk of their own.

Add-on against the target versionBase risk
Incompatible90 (Critical)
Compatibility unknown40
Compatible0

That risk flows to everything that depends on the add-on, decaying × 0.6 per hop like any other — so an incompatible ingress controller shows its whole blast radius: the Ingresses on it, the Services they route to, the workloads behind them.

Propagated risk still only shows where the upgrade would hurt. What stops it is the verdict: an incompatible add-on is a deterministic blocker that makes it CRITICAL, and the readiness score is a gauge that never blocks.

In this section​

To run one, see Create an UpgradeAnalysis.