Skip to main content
A view tells KubeStacks how to show a kind: which columns matter, how to tell whether an object is healthy, which facts to show, what it links to, and which changes people make to it. KubeStacks ships views for popular projects; see Built-in views. In your cluster, the views everyone sees go in the chart’s views value, one entry per file name:
values.yaml
Each entry is a file, named with .yaml or .yml at the end, with one or more views separated by ---, exactly as you’d write them for the desktop app. See Write a view and the view format.

​
How it works

  • The chart puts the files in a ConfigMap, and mounts it at /etc/kubestacks/views, where KubeStacks reads them (KUBESTACKS_VIEWS_DIR).
  • A view of a kind replaces KubeStacks’ own view of that kind.
  • A change to views rolls out a new pod, which reads them. That signs everyone out, as any restart does.
  • Views are the server’s, for everyone. People can’t add views of their own from a browser.

​
Check them

API resources (in the sidebar, or ⌘K, CtrlK on Windows and Linux) shows which view each kind uses, and lists anything wrong with the views. A view with a problem isn’t used at all, and the problem says where it is. Views are data only. They read fields with JSONPath, and change objects only with the patches they spell out. Their actions go through the same checks as KubeStacks’ own: the cluster is asked first whether the person may make the change, the equivalent kubectl command is shown, and a read-only KubeStacks stays read-only.

Write a view

A step-by-step guide, from columns to actions.

View format

Every field a view can have.