Detail pages, events and describe

Every detail page has the same shape: a header naming the object, over a row of tabs in groups a thin divider sets apart.

The header

The kind, the name, a status badge and a line of facts such as the namespace and age. On the right are the actions:

• Copy link copies a link to the page and tab you are on; see links.
• Refresh re-reads what the page shows. ⌘R or Ctrl+R does the same.
• Edit opens the Manifest tab in edit mode. See manifests.
• Delete asks first, naming the object, and takes you back to the list once it is gone. A Node, Namespace, CRD, PersistentVolume, StorageClass, ClusterRole or ClusterRoleBinding asks you to type its name, because deleting one takes far more with it. See writing to the cluster.

Some kinds add their own, such as Evict on a pod, Restart on a workload or View instances on a CRD. On a window too narrow for them beside the name, the actions move to a row of their own under it. A custom-resource instance has no Delete, and a Helm release has its own actions in place of all three; see Helm releases.

While the object loads, the page shows its outline. If the read fails, the page says why, the way a list does, with the cluster’s own reason under it when that says more, and offers Retry and Back to list:

• Access denied: you don’t have permission to view this object.
• Not authenticated: the cluster rejected your credentials.
• Cluster unreachable: the cluster’s API server did not answer.
• Cluster timed out: the cluster took too long to return the object. The page links to Settings › Cluster data, where the read timeout can be raised.
• Kubeconfig not loaded: no cluster can be asked; the top bar offers the fixes.

Anything else reads “Failed to load” with the reason under it. If the object is not there, the page says so and names the namespace it looked in, for a namespaced kind; that includes a custom resource or Helm release that has been deleted, which has nothing to retry.

A tab that reads something of its own — Related, Describe, Rollout, a controller’s Pods, a release’s Resources — says it is reading while it waits, and when that read fails it gives the same reason in the same words, with Retry, rather than showing an empty tab.

The tabs

The tabs run in one row under the header, in groups a thin divider sets apart: what the object is doing first (Overview, Events and what the kind has to watch), then what it is (Manifest, Labels and the like), then Shell on a pod, with a group of the kind’s own between them on the kinds that need one — finding your way around lists which. The arrow keys move between tabs once one has focus.

When the row is wider than the window it scrolls sideways rather than wrapping. The edge with more tabs past it fades under an arrow that scrolls the row toward it, and the open tab is always scrolled into view, also when the window narrows under it.

The page remembers its tab. A reload stays on it, and when you leave the object and come back with Back, it opens on the tab you left, so opening a pod’s Logs, following it to its node and pressing Back lands on Logs again. Moving between tabs adds nothing to the history: one Back leaves the object, however many tabs you looked at. The breadcrumb ends with the tab’s name, and the first tab has none, so the object’s plain address opens there.

Links

Copy link, the first of the header’s actions, puts a link like this on the clipboard:

kubermeister://open/https%3A%2F%2FABC123.gr7.eu-west-1.eks.amazonaws.com/workloads/pods/default/web-1/logs

It names the cluster by its API server address, the server your kubeconfig gives the current context’s cluster, and the page and tab you are looking at. A context name would not do: the same cluster is Development in one kubeconfig and AppDevelopment in another, while its address is the same for everybody whose kubeconfig came from the cloud provider’s CLI or from a shared file. Anybody whose kubeconfig reaches that address can click the link, in a chat or a browser’s address bar, and land on the same page, whatever their context for it is called. A link to the Shell tab is copied as a link to the pod’s first tab, because opening a shell runs a command in the pod and a click on a link is not a decision to do that.

Opening a link only ever opens a page:

• When the context you are on reaches that cluster, the page opens straight away.
• When another context in your kubeconfig reaches it, Kubermeister asks first, naming the cluster’s address, that context and the one you are on, and switches only when you choose Switch and open. When several contexts reach it, which usually means they sign in as different users, you pick one in the dialog. Switching ends your port forwards, shells and log follows, as any context switch does. Stay leaves everything as it was.
• When no context reaches it, Kubermeister says so, naming the address, and switches nothing.
• A link to an object in a namespace other than the one selected selects the object’s namespace as it opens, once any context switch is done. Under All namespaces the selection stays, since the object is already in it.
• A link naming a page this version does not have, or one that is not a Kubermeister link at all, opens nothing and says why.

Addresses are compared as your kubeconfig writes them, after ignoring letter case, the default port and a trailing slash. Nothing asks the cluster, so opening a link works while a cluster is down. If you reach a cluster through a different address from your colleague’s (a local tunnel, another DNS name for the same API server), the link finds no context for it. A link carries the API server’s address, so it tells whoever reads it where your cluster’s API server is, though nothing that would let them sign in.

The namespace in the link is the object’s own, so the namespace selector keeps whatever you had chosen. A link never deletes, restarts, forwards a port or downloads anything, and a link to the Shell tab opens the pod’s first tab instead.

If Kubermeister is not running, the link starts it and opens the page once it is connected. If it is, the running window comes forward; a second copy never starts.

Linux

The .deb and the .rpm register Kubermeister for kubermeister:// links when it installs. An AppImage registers nothing until you integrate it with your desktop (with AppImageLauncher or your desktop’s own integration), so until then a link does not open it.

Overview

The properties that matter for that kind, as labelled pairs, with any usage figures beside them. Pods, nodes and deployments carry usage charts here; see metrics.

Events

Events for this object, newest first, re-read at the refresh interval. They come from a field-selected query on the object’s kind and name rather than a scan of every event. Custom-resource instances and Helm releases have no Events tab.

Overview › Events stream lists the events of the active namespace, or of every namespace, in one table: Time, Type, Reason, Object, Namespace and Message, newest first. It reads at most 500 events and is polled rather than watched. Its rows do not open a detail page; go to the object for that.

Warnings carry their own badge, so they stand out in a stream of Normal events.

Labels and annotations

The Labels tab shows the labels and annotations as two cards, with the label count on its tab.

Every built-in kind adds an Object card here with the parts of metadata no view model carries: the Owner reference, the Created time, and the Finalizers, marked “holding deletion” when they are what keeps a deleted object alive. Custom-resource instances and Helm releases do not have it.

Describe

Pods and nodes have a Describe tab. Everything else has its manifest, which says the same thing in YAML.

Copy and Download render the same sections you are reading to text.

Describe answers a structured document — sections of labelled rows, with blocks for the parts that repeat — rather than pre-rendered text. The screen lays it out, and Copy and Download (as <name>-describe.txt) render the very same document to text, so what you paste is what you read.

Related objects

A pod’s Related tab answers what else it is tied to, grouped into Traffic, Configuration, Storage and Access, and every link says why:

• A Service whose selector covers the pod’s labels (“selects these pods”), and a NetworkPolicy whose pod selector selects the pod, its matchExpressions included, or selects every pod with an empty podSelector (“applies to these pods”).
• ConfigMaps and Secrets “mounted as volume”, “projected into” a volume, read through “envFrom in” a container or as “env NAME in” one, and Secrets used as an “image pull secret”.
• PersistentVolumeClaims “mounted as volume”.
• The ServiceAccount it “runs as”.

Each link says why the pod and that object belong together.

A relation that cannot be explained is a guess, so everything comes from the pod’s own spec or from a selector that actually covers its labels — never from names that merely look alike. A pod nothing else names reads “Nothing else names this object.” Only pods have this tab.

Ownership

Ownership is resolved through the API’s own owner references, never label selectors. A selector says which pods a controller would adopt; the references say which it has, and two workloads can share labels but never a reference.

A pod walks up through the one intermediary its kind allows — a ReplicaSet to its Deployment, a Job to its CronJob — and stops. A link is only a link when there is a screen for that kind, matched on the owner’s API group as well as its kind, so a Volcano Job is named but not linked to the Jobs screen; a broken link higher up ends the chain rather than failing the whole card.