Resource map

Resource map

The resource map answers two questions a table cannot: what uses this object, and what breaks if I delete it. Every object's details have a Related tab, and the Map page draws a whole namespace with the links between its objects.

Both are read-only: nothing is deleted or changed from them. Delete stays the usual action with its confirmation.

Contents: What is related to what · The Related tab · If it is deleted · The Map page · What it does not see

What is related to what

From	To	Shown as
Any object	its owner (owner references)	Owned by / Owns
Service, Network Policy, Pod Disruption Budget	the pods their selector picks	Selects / Selected by
Endpoint Slice	its Service and the pods listed in it	Endpoints of, Endpoint pods
Ingress, HTTP/GRPC/TLS/TCP/UDP Route	the Services they send traffic to	Sends traffic to / Receives traffic from
Route	the Gateway it is attached to	Attached to / Attached routes
Ingress, Gateway	the Secrets of their TLS certificates	TLS certificates / TLS certificate of
Pod (and a workload's pod template)	ConfigMaps, Secrets and claims it mounts; ConfigMaps and Secrets it reads environment variables from; image pull secrets; its service account; its node	Mounts, Environment from, Image pull secrets, Service account, Runs on
Persistent Volume Claim → Persistent Volume → Storage Class	binding and class	Bound to, Storage class
Horizontal Pod Autoscaler	the workload it scales	Scales / Scaled by
Ingress, Gateway	their Ingress Class or Gateway Class	Class / Objects of this class

Selectors are read the way the API server reads them: a Service without a selector selects nothing (its endpoints are managed by hand), a Network Policy with an empty pod selector applies to every pod of its namespace, and a Pod Disruption Budget with an empty selector covers every pod of its namespace. References marked optional (an optional ConfigMap) are shown as optional.

The Related tab

Open any object and choose the Related tab:

1. If it is deleted: what would happen, in plain sentences (see below).
2. Related objects: one hop both ways, grouped ("Mounted by", "Owns", "Selects", …), each object coloured by its health and opening its details on a click. The chevron next to an object shows its relations in place, so you can follow a chain hop by hop: Ingress → Service → pods → ConfigMap.

For a Service, Gateway API routes in other namespaces that send traffic to it are found too, the same way the Gateway API section finds them.

If it is deleted

Sextant counts the consequences from the objects it sees, for example:

• "Deleting it also deletes 4 objects it owns (ReplicaSet, Pod)." — only objects that name it as their owner, and only those with no other owner left: Kubernetes keeps an object while any of its owners exists.
• "ReplicaSet web-7d4b9c6f5 will create it again." — for a pod of a ReplicaSet, Stateful Set or Daemon Set, a running Job's pod, or a Deployment's current ReplicaSet. A Cron Job never recreates a deleted Job.
• "3 pods mount it: restarted or new ones will fail to start." — a ConfigMap or Secret mounted or read for environment variables (optional references are not counted).
• "2 workloads name it in their pod templates: their new pods will fail to start."
• "1 route sends traffic to it: that traffic will fail.", "2 objects use it as a TLS certificate: HTTPS there will fail."
• "1 pod uses this claim: the deletion waits until it stops (pvc-protection)." — and the same for a volume bound by a claim (pv-protection).
• "5 pods lose this disruption budget: a drain may evict all of them at once.", "5 pods are no longer restricted by this network policy."

"Nothing among the watched objects depends on it" means exactly that: see What it does not see.

The Map page

Cluster → Map draws the objects of the namespaces chosen in the namespace filter (at most the first 3; with All namespaces the page asks you to pick) in columns, from the way in to what is used:

routes and Ingresses → Services and policies → workloads → ReplicaSets and Jobs → pods → configuration and claims → cluster objects (nodes, volumes, classes)

• Colours come from the same rules as the Problems and notifications page: Has problems, Waiting (a problem still in its grace period), Healthy, Not judged (a kind without rules, such as a Service), Not found (named but missing), Not watched. A red pod here is red there too.
• Groups: the pods (or ReplicaSets, Jobs) of one owner become one box such as "42 pods" when there are more than 5, and a kind with more than 30 boxes in a namespace becomes one box per kind; the group shows how many have problems. Click a group to expand it (up to 100 members), Collapse groups to fold them again.
• Kinds: hide or show kinds with the checkboxes; cluster objects and Endpoint Slices start hidden. At most 400 boxes are drawn; the page says how many more there are.
• Click any object to open its details.

What it does not see

• The relations are found among the objects Sextant watches for the view: the namespace of the object (or of the map), and for a cluster object only what can name it (the pods of a node, the volumes of a storage class, the objects of a class). The Related tab opens at most 4 namespaces at once while you expand objects of other namespaces.
• Kinds the cluster does not serve or that you may not list are left out; the tab names lists it could not read.
• Custom resources are related only through their owner references.
• Controllers may act after a deletion in ways no object declares (an operator recreating what it manages).

The watches are shared between the tab and the map and closed a few seconds after you leave them.

Next: Using Sextant.