How to Set Up a Kubernetes Visual Management & AI Troubleshooting Workbench in 30 Minutes

How to Set Up a Kubernetes Visual Management & AI Troubleshooting Workbench in 30 Minutes

I. Sound Familiar?

Last week at 2 AM, a production Pod suddenly went into CrashLoopBackOff. I frantically jumped between terminal windows, running kubectl get, kubectl describe, and kubectl logs. By the time I finally tracked down the root cause—an ImagePullBackOff combined with a missing ConfigMap—an hour had already slipped away. If I had had an intuitive topology and event timeline view, I could have isolated the issue in seconds.

Later, I hit another common pain point: trying to get AI to analyze cluster state. I pasted the raw output of kubectl get all -A, and the LLM immediately blew past its context window, offering generic advice that missed the actual problem entirely.

This tutorial has one clear goal: walk you through setting up an out-of-the-box Kubernetes visual management tool called Radar on your local machine, run through a complete "cluster health troubleshooting" scenario, and finally connect its MCP server to an AI Agent so AI can read your cluster for you. The entire process requires zero installations inside your cluster and no account registration.

II. Prerequisites

• A computer (Mac / Linux / Windows) that can reach your K8s cluster, with kubectl properly configured and able to connect.
• A valid ~/.kube/config file—Radar reads it directly to communicate with your cluster.
• Basic familiarity with Pods, Deployments, and Services is enough. No expert-level ops skills required.
• To experience AI assistance, prepare an MCP-compatible AI client (Claude Desktop, Cursor, Windsurf, etc.). Configuration steps are covered later.

Why emphasize zero in-cluster installation?
Radar is a single-binary tool that leverages your existing kubeconfig to connect directly to the Kubernetes API. It doesn't deploy Sidecars, register CRDs, or generate cluster telemetry. This is crucial for production environments—you don't need approval from cluster admins to install it. Just download and run.

For air-gapped or internal network environments, Radar works seamlessly out of the box since it has zero external cloud dependencies. We'll cover how to handle private registries later.

III. Quick Install & Launch

Step 1: Install Radar

The recommended approach is the official one-liner script:

curl -fsSL https://get.radarhq.io | sh

What does this command do? It fetches the correct OS-specific binary from GitHub Releases and places it into your local $PATH. macOS users can also install it via Homebrew:

brew install skyhook-io/tap/radar

Step 2: Launch

kubectl radar

After execution, the terminal will print a brief log and automatically open your default browser (usually http://127.0.0.1:9280). If you're running this over an SSH tunnel or a browser doesn't launch automatically, add --no-browser to skip auto-opening and access it manually.

Note: kubectl radar runs as a kubectl plugin. It functions identically to running radar directly. The install script automatically registers this alias.

Step 3: Verify Connection

Once the browser opens, you'll land on Radar's dashboard. If the connection succeeds, the homepage will display your cluster name, node count, and a resource overview. If it fails, check the terminal output. The most common issue is selecting the wrong kubeconfig context—verify it with kubectl config current-context.

At this point, your workbench is ready. Next, let's explore the most practical views.

IV. Core Views Quick Start

Radar's UI features several navigation views on the left. Here they are, ranked by troubleshooting frequency:

1. Issues View – "What's broken in my cluster?"

The Issues panel on the homepage aggregates abnormal resources across the cluster: CrashLoopBackOff, ImagePullBackOff, failed scheduling (Pending), and more. This should always be your first stop. Click any entry to view details directly without digging through YAML.

2. Event Timeline – "What just happened?"

Press g l to open the Timeline. This view displays cluster events chronologically, including Pod scheduling, rolling updates, health check failures, and more. You can filter to show only Warning events or view resource change diffs (e.g., who changed replicas from 3 to 1).

Why is this view valuable? Native kubectl get events just flattens events by creation time, offering no diffs or causal context. Radar packages events and config changes onto a single timeline, letting you instantly trace chains like: replicas decreased → insufficient Pods → traffic routed to other nodes.

3. Topology View – "How are these services connected?"

Press g t. Radar automatically generates a resource relationship graph: Services pointing to Pods, Deployments managing ReplicaSets, Ingress routing to Services. It supports grouping by Namespace or App Label.

The topology uses ELK.js for automatic layout, supporting zoom, pan, and node-click details. If you work with microservices, this saves you from manually drawing architecture diagrams.

4. Cluster Audit – "Do I have any security risks?"

Press g u, then select Audit. It includes 31 built-in checks covering security (privileged containers, sensitive volume mounts), reliability (missing probes, single-replica deployments, deprecated API versions), and efficiency (missing resource requests/limits). Each check highlights affected resources and provides remediation steps.

V. Practical Scenario: Complete Cluster Troubleshooting

Let's tie it together with a realistic scenario: A production Deployment has been restarting frequently. How do we use Radar to pinpoint the cause?

Scenario Setup: Assume you have a payment-service Deployment where 1 out of 3 replicas keeps restarting.

Step 1: Open Radar and check the Issues panel on the homepage. You'll see a red alert for payment-service-xxx in CrashLoopBackOff state. Click it.

Step 2: The resource detail page automatically shows Container status, recent events, and log snippets. If the cause isn't obvious, switch to the Timeline view (g l) and search for payment-service. You'll see a chronological event chain—perhaps a ConfigMap update triggered, followed by a Pod restart.

Step 3: Navigate to the Pod details and open the Image Filesystem Viewer tab. If you suspect a missing config file or dependency in the container image, you can browse the filesystem directly here—no docker pull or kubectl exec required. You can search and download files instantly.

Step 4: If you suspect an OOMKilled due to resource constraints, open the Deployment's Metrics tab (requires a Prometheus backend). Review historical CPU, memory, and throttling curves.

The entire workflow happens in your browser without context-switching to the terminal. This is what efficient troubleshooting should feel like.

VI. Let AI Analyze Your Cluster (MCP Integration)

This is the section I consider most worth your time.

Radar includes a built-in MCP (Model Context Protocol) Server, enabled by default. It allows AI clients like Claude Desktop, Cursor, and others to connect directly to Radar, letting AI read and analyze your cluster state.

Why use MCP instead of pasting kubectl output?

• Raw kubectl get all outputs verbose YAML that quickly burns through an LLM's context window.
• Radar feeds AI pre-processed, token-optimized data: topology maps, health assessments, deduplicated events, and filtered logs.
• Write operations (restart, scale, rollback) require explicit client confirmation and are strictly governed by K8s RBAC.

Configuration Steps

Radar runs in stdio mode by default. Here's how to set it up with Cursor:

1. Open Cursor Settings → MCP Servers → Add a new server.
2. Set Command to radar (ensure it's in your $PATH).
3. Optionally add --mcp-catalog-stdio to enable catalog self-check.
4. Save, then ask in Cursor's AI chat: "Check my cluster for CrashLoopBackOff Pods and suggest fixes."

For Claude Desktop, add the following to your claude_desktop_config.json:

{
  "mcpServers": {
    "radar": {
      "command": "radar",
      "args": []
    }
  }
}

Once configured, you can prompt AI to run tools like get_cluster_audit, diagnose (network path diagnostics), or manage_gitops (GitOps sync operations). The AI will fetch cluster data from Radar, analyze it, and return actionable conclusions.

Security Note: MCP diagnostic tools are read-only by default. Write operations require manual confirmation and respect your kubeconfig's RBAC permissions. To disable MCP entirely, start Radar with --no-mcp.

VII. In-Cluster Deployment (Team Sharing)

The steps above cover the "local machine connecting to a cluster" workflow. If your team needs a shared Radar instance, deploy it into the cluster using Helm:

helm repo add skyhook https://skyhook-io.github.io/helm-charts
helm install radar skyhook/radar -n radar --create-namespace

Once deployed, expose it via Ingress and configure OIDC or proxy authentication for user isolation. For detailed auth and RBAC setup, refer to the Authentication Guide.

VIII. Common Issues & Pitfalls

1. Port Conflicts: Radar defaults to port 9280. If occupied, start with --port 9281.
2. SSH Tunnels / High-Latency Clusters: The default 30s connection timeout may be insufficient for jump hosts or cross-region access. Increase timeouts via:
   bash 复制代码

   kubectl radar \
     --context-switch-timeout=120s \
     --first-paint-backstop=10m \
     --namespace-list-timeout=30s \
     --max-scope-candidates=200

   These can also be set via environment variables (RADAR_CONTEXT_SWITCH_TIMEOUT=120s, etc.) for better flexibility.
3. Private Registries (Air-Gapped): In isolated environments, the default debug image busybox:latest may fail to pull. Use --debug-image=your-registry/busybox:latest to specify your internal registry.
4. Large Cluster Sync Lag: If managing >50k Pods/ReplicaSets, add --list-page-size=2000 to enable paginated initial sync and prevent LIST timeouts.
5. Wrong Browser Opening: Force a specific browser with --browser firefox or --browser "Google Chrome".

IX. Summary & Next Steps

Today we walked through a complete path with Radar:

1. Single-binary install with zero cluster modifications.
2. One-command startup, direct K8s resource management in-browser.
3. Daily troubleshooting covered via Issues, Timeline, Topology, and Audit views.
4. MCP integration enabling AI Agents to automatically analyze clusters, replacing manual YAML parsing.

Recommended Next Steps:

• Try the GitOps view (g o) if you use FluxCD or ArgoCD. It automatically scans for drift and sync status.
• Before upgrading your K8s version, run the Upgrade Impact view (g u → Upgrade Impact) for a compatibility scan to avoid post-upgrade failures.
• Explore the Helm Management view: view release history, diff revisions, and roll back directly from the UI.

Tools are just a means to an end. The real value here is aggregating information scattered across seven different terminal commands into a single interface, letting you focus purely on solving problems. Spend half an hour this weekend setting it up, and you'll thank yourself during Monday's troubleshooting.