Dependency graph

A ClusterMirror is not a flat list of objects — it's a graph, rebuilt on every refresh. Nodes are components (workloads, services, nodes, PVCs, add-ons); directed edges are dependencies. The graph makes the blast radius of anything that fails — or anything you're about to change — visible to everything built on top of it.

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

Read the relationships

Edges explain why a component is affected

Follow dependencies from a component to its dependents to understand which workloads or namespaces share the same underlying risk.

Node types

Every node carries a type (which shapes it in the UI) and a risk value (0–100):

Type	Examples
workload	Deployment, StatefulSet, DaemonSet, Job, bare Pod
network	Ingress, Service
storage	PersistentVolumeClaim
infra	Node
addon	cert-manager, ingress-nginx, Istio, Argo CD, …
config	ConfigMap / Secret references

Edge types

Edges describe how one component depends on another:

Edge	Meaning
routes-to	An Ingress routes to a Service
selects	A Service selects a workload's pods
uses-config	A workload mounts a ConfigMap/Secret
uses-storage	A workload uses a PVC
runs-on	A pod runs on a node
depends-on	A workload depends on an add-on

Why edges matter

A number alone ("risk: 90") doesn't tell you what else is affected. The graph does. If a node is NotReady, every workload with a runs-on edge to it inherits risk. If a PVC is Lost, the workload that uses it can't start again — the graph shows exactly which one.

This is how Mirops turns a pile of findings into a story:

• Right now — this deployment is down, this Service selects it and this Ingress routes to it, so that is what your users feel. The ClusterMirror publishes it on every refresh.
• Before a deploy — the impact check walks the same edges: deleting service/checkout is blocked because ingress/shop has a routes-to edge to it.
• Before an upgrade — upgrade analysis adds add-on compatibility: this add-on is incompatible with the target version, these workloads depend on it.

In the Web UI

The Web UI's Cluster Mirror page renders the graph interactively: nodes colored by risk (None → Critical), laid out left-to-right (failing workloads → what they depend on → add-ons), draggable to untangle. When nothing depends on the at-risk components, the graph shows a no dependency chains state instead of a lone node.

Next

• See how risk travels along these edges in risk propagation.
• See how a change is checked against them in the impact check.