KubeView

KubeView is a Kubernetes cluster visualization tool that provides a graphical representation of your cluster’s resources and their relationships. It helps you understand the structure and dependencies of your Kubernetes resources, making it easier to manage and troubleshoot your cluster. It is designed to be lightweight, easy to use, and provides a real-time view of your cluster’s resources.

Note: This is a v2 and complete rewrite the original KubeView project see below for some insight on the differences and why this was created.

CI Lint & Build GitHub last commit GitHub issues GitHub pull requests GitHub release (latest by date)

📜 Details

Features

🏗️ Architecture & Design

KubeView is built using Go for the backend, exposing a REST API that provides the data for the frontend, and serves static HTML/JS. The frontend is a static web application that uses HTML, CSS, and plain modern JavaScript (ES6) to render the user interface. It uses Cytoscape.js for graph visualization, Alpine.js for client-side interactivity, and Bulma for styling.

The backend uses the Go client for Kubernetes to retrieve resource information, including setting up watchers for real-time updates streamed using SSE. The data is then processed and sent to the frontend as JSON, which the frontend uses to render the graph and update the UI.

diagram of system

A clientID is used to identify the client and send updates for the resources they are interested in. The frontend JS generates a unique clientID when it first starts, stores it in local storage, and uses it in all subsequent requests to the backend. This allows the backend to send real-time updates only to the clients that are interested in those resources.

Routes & Endpoints

🔐 Security and Kubernetes API Authentication

The KubeView backend connects to the Kubernetes API via two methods, depending on where it is running:

The application itself does not enforce any authentication or authorization, it relies on the Kubernetes API server to handle access control. This means that the permissions granted to the service account or user in the Kubernetes cluster will determine what resources KubeView can access and display.

🚀 Running Locally & Quick Start

Pre-reqs:

Running it via Podman or Docker is the easiest way to get started. You can quickly run KubeView locally with the following command:

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

This mounts your local Kubernetes configuration directory $HOME/.kube into the container, allowing KubeView to access your cluster. The app will be accessible at http://localhost:8000. If your config file is located elsewhere, you’ll need to adjust the volume mount accordingly.

Configuration

The following environment variables are supported:

In addition the standard KUBE_CONFIG environment variable can be used to specify a custom path to the Kubernetes configuration file. If not set, it defaults to $HOME/.kube/config.

❇️ Deploying to Kubernetes

Use the provided Helm chart and GitHub published images to deploy KubeView to your Kubernetes cluster. The chart is designed to be simple and easy to use, with a range of configuration options.

🧑‍💻 Developer Guide

If you wish to contribute to this project, or make code changes, it is suggested to use the dev container provided in the repo. This will ensure you have all the dependencies installed and configured correctly.

The .dev folder

The .dev directory is an new attempt to reduce the number of files in the root directory. It contains configuration files for various development tools, air, golangci-lint, eslint, prettier, and more. This is to keep the root directory clean and focused on the main application code. The use of a separate tools.mod file keeps Go tool dependencies separate from the main go.mod file, which is a good practice for managing development dependencies.

The makefile provides a number of commands to help you get started:

help                 💬 This help message :)
lint                 🔍 Lint & format check only, use for CI
lint-fix             ✨ Lint & try to format & fix
run                  🏃 Run application, used for local development
build                🔨 Build application binary
clean                🧹 Clean up and reset
image                📦 Build container image from Dockerfile
helm-docs            📜 Update docs & readme for Helm chart
helm-package         🔠 Package Helm chart and update index

Project Structure

The project is structured as follows:

📂
 ├── deploy           # Dockerfile and Helm chart
 ├── docs
 ├── public           # Static files served by the web server
 │   ├── css          # Stylesheets
 │   ├── ext          # External libraries (e.g., Cytoscape.js, Alpine.js)
 │   ├── img          # Images and icons
 │   ├── js           # All client side JavaScript, see main.js for entry point
 │   └── fragments    # HTML fragments for Alpine.js components
 └── server           # Core backend API server
     └── services     # Services for handling Kubernetes resources and SSE

🤓 Why a v2 Rewrite?

The goal of this rewrite was to create a more maintainable codebase from the original KubeView. Some choices that have been made in this rewrite include:

The rewrite originally used HTMX for fetching data and HTML fragments from the server. This worked but ended up unnecessarily complicated with so many interactions between the frontend and backend, esp with Cytoscape. The resulting code was also hard to follow and understand. As a result the current rewrite is more of an iteration of v1, the Vue.js code has been removed and replaced with a simpler static HTML/JS app that uses Alpine.js for interactivity. The backend API has been clear separation of concerns and now dynamically handles updates using SSE.

Appendix A: Kubernetes Permissions

If you are not using the provided Helm chart, you will need to ensure that the service account or user that KubeView uses to connect to the Kubernetes API has the necessary API permissions.

For reference these permissions are get, list, watch for all of the following resources: