What is Mirops
Mirops = mirror + ops (operations).
See what breaks before it does. Mirops keeps a live logical mirror of your Kubernetes cluster — every workload, service, volume and add-on, and what depends on what — so when something fails, or before you change something, you already know its blast radius.
Instead of discovering dependencies during an incident, you reason and decide against the mirror: a model of the cluster that is stable, inspectable, and safe to analyze. What you do with it is operations — see where risk sits, trace what a failure takes down, check a change before it lands.
Most teams learn what depends on what in the middle of an outage. Mirops keeps that map live, so the blast radius is never a surprise. See Why Mirops.
This static illustration provides a quick visual summary of the same flow:
The name & the logo
The logo tells the same story as the name. On the left is the live environment — what's running in production, solid and dense. On the right is its mirror — lighter and clearer, the logical model you reason over. And in the middle stands the DevOps engineer, between the two worlds. Together the three strokes form an M — for Mirops.
Why mirror first
A live cluster is a moving target: pods restart, nodes drain, versions drift. Deciding against it directly means deciding against noise. The mirror gives you:
- A stable snapshot — one consistent picture to reason over.
- Relationships, not just objects — which workloads depend on which node, add-on, or volume.
- Propagated risk — a failing component raises the risk of everything that depends on it.
- Determinism — the same mirror always yields the same answer.
The core: the ClusterMirror
Mirops rebuilds the mirror continuously and publishes the cluster's current state:
- What is at risk — components down, pending or lost.
- The blast radius — everything that depends on each of them.
- Where risk sits — per namespace, worst first.
You read it every day — in the Web UI, from kubectl, or from a pipeline.
Operations on the mirror
- Deploy impact — the manifests or Terraform plan you're about to apply, checked against the mirror in the
impactstage of your pipeline. With--enforcethe CLI blocks the deploy only when the change would break something running. - Upgrade analysis (opt-in) — when an upgrade is coming, turn it on and Mirops reads the same mirror against the next Kubernetes version: add-on compatibility, removed APIs, drain blockers, a 0–100 health score, and a deterministic
SAFE,WARNINGorCRITICALverdict with every blocker listed. See readiness and decision.
The pieces
Mirops ships as a small ecosystem — one engine, several ways to consume it:
| Piece | What it is |
|---|---|
| Operator | A Kubernetes operator that keeps the mirror up to date — and computes the upgrade verdict when upgrade analysis is on. The engine. |
| Helm chart | Installs the operator into a cluster. |
| Web UI | A Headlamp plugin that shows the Cluster Mirror — namespace risk, at-risk components, the dependency graph — and the upgrade analyses. |
| CLI | Reads the mirror in a pipeline — checks the impact of a deploy, shows a namespace's state, and gates the upgrade on its verdict. |
| Reports | JSON .mirops files — the mirror's and each upgrade analysis's — written to a file, S3, Azure Blob, or a PVC. |
| Compatibility matrix | A vendor-verified add-on ↔ Kubernetes compatibility source, used by upgrade analysis. |
Where to go next
- New here? Read the architecture overview, then set up your first mirror and analysis.
- Want the concept? Start with the logical mirror.
- Ready to install? Follow Deploy with Helm.