Re-Engineering Kubernetes Dashboard with a Graph Brain: How We Integrated FalkorDB

01 Where We Started: The Disconnected Dashboard Problem

The official Kubernetes Dashboard has been the standard web UI for clusters for nearly a decade. But after years of serving the ecosystem, it was officially archived. More fundamentally, its architectural assumptions dated back to the early days of Kubernetes: it organized the cluster into disconnected inventory tables.

Pods sit on one tab, Services on another, ConfigMaps on a third, and RBAC bindings on a fourth. When production goes down at 2 AM, resources don't fail in isolation:

• An Ingress routes to a Service that changed its port mapping.
• A Deployment rolls out a pod that mounts a Secret that doesn't exist.
• An unprivileged ServiceAccount inherits cluster-admin permissions through a transitive rolebinding chain.

In a standard dashboard, an engineer must manually hop through 10 different pages to piece together the incident.

Kubernetes is fundamentally a graph. Pods run on Nodes, Services select Pods, Ingresses route to Services, and ServiceAccounts bind to Roles. To solve cluster troubleshooting, our AI agent needed to see the graph.

02 The Core Integration: Embedding FalkorDB as the Nervous System

Instead of building an external toy script, we forked the Go + Angular Kubernetes Dashboard repository and embedded FalkorDB directly into the control loop.

FalkorDB is an ultra-low latency, in-memory graph database running on the Redis protocol using openCypher. We chose it because Kubernetes state changes constantly; we needed sub-millisecond multi-hop graph traversals without the operational overhead of heavy Java-based graph engines.

03 Code Tour: What Part of the Codebase We Engineered

To keep the platform enterprise-grade, we maintained the existing authentication, RBAC, and client-go mechanics, and built four specialized modules on top:

Core Cypher Queries Driving the Agent

The agent does not guess. It executes exact openCypher queries against FalkorDB:

// What breaks downstream if this workload goes down? (1 to 4 hops)
MATCH (n:Service {name: $name, namespace: $namespace})<-[*1..4]-(dependent)
RETURN DISTINCT dependent.name, dependent.namespace, labels(dependent), dependent.status;

// What prerequisites does this workload need upstream? (1 to 4 hops)
MATCH (n:Service {name: $name, namespace: $namespace})-[*1..4]->(dependency)
RETURN DISTINCT dependency.name, dependency.namespace, labels(dependency), dependency.status;

// Trace indirect privilege escalation chains through rolebindings
MATCH (sa:ServiceAccount {namespace: $namespace})-[:BOUND_BY]->(b)-[:GRANTS]->(r)
WHERE (r:Role OR r:ClusterRole) AND r.sensitive = 'true'
RETURN sa.name AS serviceAccount, b.name AS binding, r.name AS role, labels(r)[0] AS roleKind;

04 Why FalkorDB is Critical (The Rule 3 Test)

Hackathon Rule 3 mandates that the graph must do real work: "if the product still works once FalkorDB is taken out, the graph is decoration rather than the thing the product runs on."

In Pilot Kubernetes, FalkorDB is the engine:

05 How to Run It: Complete Installation Guide

We made deploying Pilot Kubernetes as simple as the standard Kubernetes Dashboard. Everything—including FalkorDB—is pre-configured.

Step 1: Deploy with Helm (Recommended)

Run this single command from the root of the repository:

# Deploy Pilot Kubernetes with embedded FalkorDB
helm upgrade --install pilot-dashboard ./charts/kubernetes-dashboard \
  --namespace kubernetes-dashboard \
  --create-namespace \
  --set falkordb.enabled=true \
  --set falkordb.persistence.enabled=true

# Wait for all pods to be healthy (1/1 Running)
kubectl get pods -n kubernetes-dashboard

Step 2: Access the Dashboard in Your Browser

Forward local traffic to the web service or Kong API gateway:

kubectl port-forward -n kubernetes-dashboard \
  svc/pilot-dashboard-kubernetes-dashboard-web 8080:8000

Open http://localhost:8080 in your browser.

kubectl port-forward -n kubernetes-dashboard \
  svc/pilot-dashboard-kong-proxy 8443:443

Open https://localhost:8443 *(accept the self-signed TLS cert)*.

Step 3: Building Locally with Docker (For Developers)

If you make changes to the Go or Angular source code, build and update the containers:

# 1. Build Go API backend
docker build -t pilot-dashboard-api:latest -f modules/api/Dockerfile .

# 2. Build Angular frontend
docker build -t pilot-dashboard-web:latest -f modules/web/Dockerfile .

# 3. Restart deployments to pick up new images
kubectl rollout restart deployment/pilot-dashboard-kubernetes-dashboard-api -n kubernetes-dashboard
kubectl rollout restart deployment/pilot-dashboard-kubernetes-dashboard-web -n kubernetes-dashboard

Step 4: Verify FalkorDB & API Sync

Test that FalkorDB is active and storing cluster topology:

# Check graph connection and node/edge count
curl -s http://localhost:8080/api/v1/graph/status
# Expected response: {"connected":true,"graphName":"kubepilot","nodeCount":142,"edgeCount":318}