# spekt8 draws your cluster as a graph you can zoom into

> spekt8 is a Kubernetes visualisation tool that builds a logical topology of pods, services and ingresses in real time, and offers the same cluster as a graph or a table. It suits an operations team that wants a live picture of what is running, and it reads only the default namespace, with no controller objects shown directly.

**spekt8/spekt8** — Visualize your Kubernetes cluster in real time

- Repository: https://github.com/spekt8/spekt8
- Stars: 739 · Forks: 104
- Language: JavaScript
- License: MIT
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/spekt8-spekt8

## A topology built from what is running, not from what you declared

spekt8 describes itself as a new visualisation tool for Kubernetes clusters that automatically builds logical topologies of your application and infrastructure, so that SRE and operations teams can intuitively understand, monitor and control a containerised microservices application. The word automatic is doing the work here. The topology is derived from the live objects in the cluster rather than from a chart you wrote, which means it reflects what is actually running, including the pods a deployment scaled to, and the service and ingress objects that route traffic between them. The deployment model follows from that. You deploy the containerised application directly into your Kubernetes cluster and it reads the cluster through the API, so there is no separate collector to run and no configuration file describing your workloads. The published image is multi-architecture, covering linux/amd64, linux/arm64 and linux/arm/v7, and it is rebuilt and pushed automatically on every commit to master, with tags including :latest and a per-commit :sha- form.

## What you can see, and what you cannot

The documentation is precise about the scope. The tool displays all the Pods, Services and Ingresses, with the ability to drill down. The information provided includes but is not limited to the status of pods, with blue for running and yellow for pending, the specific container images running within pods, and information on ingresses and services, covering NodePort, load balancer, cluster-ip, persistent volume claims and persistent volumes. There is one explicit gap. While the current app does not directly visualise any controllers, such as Deployments, Daemon Sets and Replication Controllers, it does indirectly visualise them through their pods, and the project says more support for additional Kubernetes objects is being built. Read that as a scope statement rather than a roadmap promise. If your mental model of a cluster is built from deployments and replica sets, the picture will be one level down from where you start.

## Graph and table, because the same question gets asked two ways

The same data is presented two ways, and the choice between them is the interesting part of the interface. Nodes can be presented either in graphical or in table mode. The graphical mode is described as practical for obtaining a quick visual overview of your app, its infrastructure and the connections between all of the nodes. The table mode presents nodes as a convenient list displaying the resources being consumed by processes, containers and hosts. That pairing is deliberate. A topology answer is spatial, a consumption answer is numeric, and an operations team asks both kinds of question during an incident. The other interaction details are short and worth knowing before you deploy it. Navigation uses the arrow keys for movement and the minus and plus keys for zoom. The legend has switch icons next to it for filtering based on object types. Clicking a pod, service or ingress shows more detailed information about the selected object. And the View dropdown toggles between the graph and table views.

## Deploying it takes two manifests and a port forward

The instructions presume you already have a Kubernetes cluster running. SPEKT8 needs read access to a few resources, pods, services, ingresses, deployments and daemonsets, in the default namespace, and the documentation is explicit that you should apply the RBAC manifest first to create a dedicated ServiceAccount with least-privilege read-only access, and then apply the Deployment:

```bash
* kubectl apply -f [spekt8-rbac.yaml](https://raw.githubusercontent.com/spekt8/spekt8/master/spekt8-rbac.yaml)
* kubectl apply -f [spekt8-deployment.yaml](https://raw.githubusercontent.com/spekt8/spekt8/master/spekt8-deployment.yaml)
* kubectl port-forward deployment/spekt8 3000:3000
```

Then you open a browser at http://localhost:3000. The port-forward rather than a Service or Ingress is a deliberate simplicity choice, and it is also the first thing to reconsider in a real deployment, because a port-forward to a local machine is not how a shared operations dashboard is normally reached. The two manifests are in the repository root as spekt8-rbac.yaml and spekt8-deployment.yaml, so you can read exactly what permissions the ServiceAccount gets before applying it. The repository also holds a Dockerfile that builds a Node 20 Alpine image with a builder stage running the production webpack build, a runtime stage that copies only the server sources and the built dist directory, a non-root node user, and port 3000 exposed.

## A React and Express tool with a dated dependency set

The stack is a familiar one and the versions tell you how long the project has been standing. The built-with list names React, Redux, React-Graph-Vis for the graph rendering and Jest for the tests, and the package.json confirms it, with react and react-dom at 16.6, redux at 4.0.1, react-redux at 5.1.0, react-router at 4.3.1 and react-graph-vis at 1.0.2. The server side is Express with body-parser, and the Kubernetes access goes through the official @kubernetes/client-node at 0.7.1. The build is webpack with a production and a development watch mode, the dev server is nodemon against src/server/server.js, and the test script runs Jest with coverage and a text summary reporter, with enzyme and enzyme-to-json for the snapshot serialiser. The top level of the repository also holds src/, dist/, a Dockerfile, a webpack.config.js, an aws-auth-cm.yaml for Amazon EKS authentication, and two directories named k8sed and k8sgrider whose purpose is not explained in the documentation available here. A RECOVERY.md file sits at the root as well, which suggests the project has been through a period where recovery mattered.

## Where it fits, and where it does not

The honest limitations are the ones the documentation already names, and they are worth weighing against the appeal of the live graph. The tool reads the default namespace, so a cluster where your workloads live elsewhere needs either a namespace change or a second instance, and the RBAC manifest as written grants access to that one namespace. Controllers are not shown directly, so a Deployment that exists but is scaled to zero is invisible in the graph. The interface is also keyboard-first in a specific way, with arrow keys and the plus and minus keys doing the movement and zoom, and there is no mention of touch input, which matters if the dashboard is going on a wall display. Against that, the alternative approaches are narrow. kubectl describe and kubectl get give you facts without relationships, a metrics stack gives you numbers without topology, and a general purpose dashboard plugin gives you charts that you still have to interpret yourself. spekt8 occupies the middle, where the question is not how many pods are running but what is connected to what.

## Conclusion

Adopt spekt8 when your operations team needs a shared, live picture of the pod, service and ingress layer of a cluster, especially for people who do not live in kubectl. Do not adopt it as a full cluster dashboard, since the documentation says controllers are not visualised directly and only the default namespace is read. Verify first that the resource kinds you care about are among the ones the tool reads, that the read-only ServiceAccount the RBAC manifest creates is enough for your namespace, and that the port-forward workflow in the instructions matches how your team reaches cluster services.

## FAQ

### How do I deploy spekt8 into a Kubernetes cluster?

Apply the RBAC manifest first to create a dedicated ServiceAccount with least-privilege read-only access, then apply the Deployment manifest, then run kubectl port-forward deployment/spekt8 3000:3000 and open http://localhost:3000. The instructions presume you already have a cluster running.

### What Kubernetes objects does spekt8 visualise?

Pods, Services and Ingresses, with pod status shown as blue for running and yellow for pending, the container images inside pods, and details on ingresses and services including NodePort, load balancer, cluster-ip, persistent volume claims and persistent volumes. Controllers such as Deployments and Daemon Sets are not visualised directly, only indirectly through their pods.

### What permissions does spekt8 need in the cluster?

Read access to a few resource kinds, pods, services, ingresses, deployments and daemonsets, in the default namespace, granted through a dedicated ServiceAccount created by the spekt8-rbac.yaml manifest with least-privilege read-only access.

### How do I navigate the spekt8 graph and switch views?

Use the arrow keys for movement and the minus and plus keys for zoom, the switch icons next to the legend to filter by object type, and click a pod, service or ingress for more detail. The View dropdown toggles between Graph and Table views, where the table lists the resources consumed by processes, containers and hosts.

## Sources

- [Issues](https://github.com/spekt8/spekt8/issues)
- [License: MIT](https://github.com/spekt8/spekt8/blob/master/LICENSE)
- [README](https://github.com/spekt8/spekt8/blob/master/README.md)
- [Releases](https://github.com/spekt8/spekt8/releases)
- [spekt8/spekt8 on GitHub](https://github.com/spekt8/spekt8)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/spekt8-spekt8