KubeView: reading a Kubernetes cluster as a live graph

A graph instead of a wall of YAML

KubeView is a Kubernetes cluster visualisation tool. It draws the resources in a cluster and the relationships between them as a logical graph, and the stated purpose is to help you understand the structure and dependencies of your resources so that managing and troubleshooting the cluster becomes easier. The upstream description calls it lightweight, easy to use, and real time.

The word relationships is the one that distinguishes it from a resource list. A pod tied to a deployment, a service pointing at a selector, an ingress in front of a service, a config map or secret referenced by a workload: the graph is the point, and the nodes are colour coded red, green or grey according to status and health so that a broken thing is visible without reading a status field.

Around the graph sit the tools you would expect from a debugging view. A side panel gives further detail on a selected resource, including common properties, labels and annotations. Namespace events are displayed and updated in real time. Pod logs can be drilled into for troubleshooting. Resources can be filtered by type to cut clutter, and a search box finds and filters resources by name.

This is a v2, and the documentation is explicit that it is a complete rewrite of the original KubeView project, with a section devoted to the differences and the reasons the rewrite happened. That matters for anyone arriving from older articles, since the routes and behaviour in those write-ups belong to a different codebase.

Go backend, static frontend, one SSE stream

The architecture is a split stack, and both halves are deliberately plain. The backend is written in Go and exposes a REST API that supplies the data for the frontend while also serving the static HTML and JavaScript. The frontend is a static web application built with HTML, CSS and plain modern JavaScript, ES6, with no build-heavy framework in the runtime path. Graph rendering uses G6, client-side interactivity uses Alpine.js, and styling uses Bulma.

The data flow is short. The Go client for Kubernetes retrieves resource information and, importantly, sets up watchers for real-time updates, which are streamed to the browser with Server-Sent Events. The backend processes the watched data and sends it as JSON, and the frontend uses that JSON to render the graph and update the interface.

The Go module pins this stack explicitly: Go 1.27.0, chi v5 for routing, k8s.io/api, k8s.io/apimachinery and k8s.io/client-go at v0.37.0, and a small helper library, benc-uk/go-rest-api, for the REST layer. The repository layout reflects the same split, with a server/ directory for the Go side and a frontend/ directory alongside it, and frontend-fs.go sitting at the root to embed the static files.

For a tool whose job is observation, the choice of a streaming transport rather than polling is what keeps the graph honest, since a resource that fails while you are looking at it changes on screen rather than on the next manual refresh.

clientID keeps the update stream targeted

One design detail in the architecture section is worth pulling out, because it is the sort of thing that only matters once several people are looking at the same cluster.

A clientID identifies the browser session. The frontend JavaScript generates a unique clientID when it first starts, stores it in local storage, and sends it in every subsequent request to the backend. That lets the backend send real-time updates to the client that is interested in the resource rather than broadcasting to every connected client. When a namespace is fetched, the resource list comes back with that identifier attached through the request itself.

The route list shows the shape of this. /api/namespaces returns the namespaces in the cluster, and /api/fetch/{namespace}?clientID={clientID} returns the resources in a given namespace for that client. /updates?clientID={clientID} establishes the SSE connection.

The rest of the surface is small and readable. /api/logs/{namespace}/{podname} fetches logs for a specific pod, /api/status returns the server status including version and build information, /health is a simple liveness check, /public/* serves the static assets, and / serves the main HTML page that loads the application.

There is a practical consequence to a local storage clientID. Clearing the browser's site data resets it, and a client that reconnects with a stale identifier simply stops receiving updates for the views it had open, which usually shows up as a graph that has quietly stopped changing.

Three ways to run it, one of them recommended

The quick start offers a binary and a container, and the documentation names a third option as the recommended one for real use.

The binary is described as the easiest starting point, because you do not deploy anything into Kubernetes and you do not need Docker or Podman installed. The install script does the work:

curl -sL https://raw.githubusercontent.com/benc-uk/kubeview/main/scripts/install.sh | sh

If you cannot write to /usr/local/bin, or want it elsewhere, the script takes a directory from the KUBEVIEW_INSTALL_DIR environment variable, for example setting it to $HOME/.local/bin. Manual downloads from the releases page work too, and then you start it with:

./kubeview

The container route mounts your Kubernetes configuration into the runtime, so the tool can reach the cluster with the same credentials you use:

docker run --rm -it --volume "$HOME/.kube:/root/.kube" \
 --port 8000:8000 ghcr.io/benc-uk/kubeview:latest

The application is then at http://localhost:8000, and if your config file lives somewhere other than $HOME/.kube you adjust the volume mount accordingly. The container image is published on GitHub Container Registry, and Podman works in the same way as Docker.

The third option is running inside the cluster, where the service account attached to the pod is used to authenticate. The documentation calls that the recommended way to run KubeView, and the Helm chart takes care of the service account and role bindings for you.

Authentication is delegated to the API server

The security model has two halves and they work differently depending on where the tool runs.

Outside a cluster, the backend locates your local Kubernetes configuration file, usually at $HOME/.kube/config, and uses it to authenticate against the cluster. That is the arrangement the binary and container paths rely on, and it means the effective permissions of KubeView are exactly the permissions of your kubeconfig context, which in a working cluster is often cluster-admin.

Inside a cluster, KubeView authenticates with the service account associated with the pod. The documentation says that service account should be assigned a role granting read-only access to the resources you want to visualise, and the Helm chart sets up the service account and role bindings for you. This is the safer of the two arrangements, and the reason the documentation recommends the in-cluster deployment.

The last piece is the one to plan for. The application itself does not enforce any authentication or authorization, it relies on the Kubernetes API server. In other words, the browser talking to KubeView is trusted, and whatever the API server is willing to show is what the UI shows. On the binary path that means the listening interface is whatever it binds to, and on the container path the port mapping publishes it. If you put KubeView on a shared network, the responsibility for access control sits in front of it, not inside it.

A read-only view, with a v2 rewrite behind it

The scope of what KubeView does is worth being precise about, because the name invites more expectations than the feature list delivers. The graph is a secure read-only view. There is no editing, no apply, no rollout restart, no port forwarding and no secret editing. The supported resource types are the common and core ones, with Pods, Deployments, Services, ConfigMaps, Secrets and Ingresses named as examples.

That is a sensible design for a diagnostic tool, and it is also the boundary that makes it safe to hand to someone who should not be able to change the cluster. The read-only service account route in the Helm chart is only meaningful because the tool never offers a write path in the first place.

The maintenance picture is uneven in a way worth noting. The repository is not archived and the last push was on 2026-09-15. The release history shows v2.1.1 on 2025-07-14, a large update for 2026 in v2.2.0 on 2026-02-22, and a maintenance update v2.2.1 on 2026-09-14. So the gaps between releases are measured in months, and the most recent one is labelled maintenance rather than feature work, which tells you the pace of the current line.

The licence is MIT, the homepage is kubeview.benco.io, and the code is a Go module named github.com/benc-uk/kubeview with a Makefile, a deploy/ directory for the Helm chart, a scripts/ directory and a docs/ directory. Compared with the general-purpose dashboards, the difference in approach is that KubeView is a single binary with one job, draws relationships rather than tables, and has no write path at all, which is a smaller tool with a narrower surface and fewer ways to get into trouble.

Editorial conclusion

Adopt KubeView when you need to explain a cluster's shape to a colleague or find the odd relationship by looking rather than reading YAML, and when you can run it locally against a kubeconfig or deploy it with a read-only service account. Do not adopt it as an operations console, because it makes no changes to the cluster and enforces no authentication of its own, and do not expose it to an untrusted network without a proxy in front. Before you start, decide which of the three deployment shapes fits, work out how access will be controlled in front of it, and remember that the current line is a full v2 rewrite, so guides written for the original project will not match the routes and behaviour you get today.

Frequently asked questions

Official sources

1. benc-uk/kubeview on GitHub
2. License: MIT
3. Project website
4. README
5. Releases