Architecture overview

Mirops runs as a Kubernetes operator that keeps a logical mirror of the cluster and runs operations on it. It has two kinds of input resource:

• ClusterMirror — always on. The operator rebuilds the mirror on an interval and publishes the cluster's current risk: what is down, pending or lost, and everything that depends on it.
• UpgradeAnalysis — opt-in. The operator evaluates whether the cluster is ready for a target Kubernetes version and returns a deterministic verdict.

Each one publishes a report. The CLI and the Web UI read them.

Reading the diagram

One mirror, several useful surfaces

The report is the handoff point: people investigate it in Headlamp, while automation reads the same facts through the CLI.

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

The flow

1. You create a ClusterMirror — a cluster-scoped resource naming the scope, how often to rebuild, and where to write the report. The chart creates none for you.
2. The operator rebuilds the mirror every refresh.interval: it collects a snapshot (workloads, nodes, storage, services, add-ons), builds the dependency graph, and propagates risk.
3. It publishes the mirror's counters to the CR status and the full report (<name>.mirops) to the configured destination. The same URL always holds the latest rebuild.
4. When upgrade analysis is on (Helm upgrade.enabled=true), each UpgradeAnalysis adds what depends on the target version — add-on compatibility, removed APIs, drain blockers — scores readiness, decides, and publishes <name>.mirops.
5. You consume it — visually in the Web UI, or in a pipeline with the CLI.

The mirror report also says whether upgrade analysis is on and indexes every UpgradeAnalysis, so a consumer learns both from the one report that always exists.

Components

Component	Role
Operator	One pod running both controllers: ClusterMirror always, UpgradeAnalysis when enabled. Installs its own CRDs at startup.
Report server	An in-cluster HTTP endpoint (mirops-reports) that serves both reports back, reading remote destinations on demand with the operator's own credentials.
Remediation manager	Executes approved RemediationPlans.
CLI	Reads the mirror report (namespaces' state) and the upgrade report (the gate).
Web UI	A Headlamp plugin: the Cluster Mirror page and the upgrade analyses.
Compatibility matrix	A vendor-verified add-on ↔ Kubernetes source, embedded in the operator and overridable via ConfigMap.

Cluster-scoped by design

ClusterMirror, UpgradeAnalysis and RemediationPlan are cluster-scoped — they model the whole cluster, so they have no namespace. The operator reads its own dependencies (AI Secret, compatibility ConfigMap, cloud credentials) from its own namespace.

Provider-agnostic concept

The mirror is provider-agnostic in concept — a model of infrastructure. Kubernetes is the first adapter; the always-on mirror and upgrade analysis are its first operations. See the logical mirror for the idea behind the implementation.

Next

• Check the prerequisites, then set up your first mirror and analysis.