{"schemaVersion":"1.0","type":"TechArticle","types":["Article","TechArticle"],"slug":"deep-dive-testing-radar-ui-for-kubernetes-using-mcp-a-go-gui-and-an-autonomous-agent-9mgvd","url":"https://zyvop.com/deep-dive-testing-radar-ui-for-kubernetes-using-mcp-a-go-gui-and-an-autonomous-agent-9mgvd","title":"Deep Dive: Testing Radar UI for Kubernetes using MCP, a Go GUI, and an Autonomous Agent","subtitle":null,"tldr":"Hand-on test of radarhq.io K8S UI and dashboard on a macOS with Minikube and Podman Introduction Kubernetes dashboards are often either overloaded with unnecess...","keywords":["clusters","Agents","podman","Kubernetes"],"entities":["Alain Airom (Ayrom)","Build Engineer","clusters","Agents","podman","Kubernetes","ZyVOP"],"keyTakeaways":["| Technical Decision | Rationale | | ------------------------------------ | ------------------------------------------------------------ | | **Podman Driver + CRI-O** | Enables containerized Kubernetes testing on macOS without relying on Docker Desktop. MD | | **`kubectl port-forward` Tunneling** | Solves AppleHV VM network isolation by routing `localhost:30928` directly to Radar's container port. MD | | **Chart Tag Pinning (`1.7.0`)** | Prevents version mismatch crashes with Helm flags present in newer chart versions. MD | | **RBAC Supplemental Patch** | Adds missing `rbac.authorization.k8s.io` read permissions required for Radar's permission inspection panels to function properly. MD | | **Model Context Protocol (MCP)** | Decouples direct Kubernetes API access from monitoring tools, allowing lightweight agents and GUIs to consume structured cluster context safely. MD+ 1 | Enter fullscreen mode Exit fullscreen mode."],"headings":["Introduction","🏗️ System Architecture & Data Flow","Deploying the Sample Workload (hello-k8s)","Workload Manifest (k8s/hello-k8s.yaml)","Desktop Monitoring: Building a Fyne MCP GUI Client","MCP Transport Invocation (gui-client/main.go)","Decoupled Data Fetching Loop","Automated Diagnostics: The 7-Step ReAct Agent","Agent Investigation Data-Flow","Implementation of the ReAct Loop (agent/main.go)","🛠️ Running the Test Environment","Provision Cluster & Deploy Stack","Run the Autonomous Agent","Launch the Fyne Desktop GUI","Key Takeaways & Design Decisions","Conclusion","Links"],"outboundLinks":["https://radarhq.io/","https://github.com/skyhook-io/radar","https://github.com/aairom/radar-k8s-test","https://github.com/aairom/radar-k8s-test/tree/main/.bob/skills"],"contentText":"Hand-on test of radarhq.io K8S UI and dashboard on a macOS with Minikube and Podman Introduction Kubernetes dashboards are often either overloaded with unnecessary complexity or too minimalist to provide deep operational context during an outage. Radar (radarhq.io) takes a refreshingly modern approach. It not only delivers a clean visual cluster dashboard but also natively integrates a Model Context Protocol (MCP) server. By exposing cluster state — deployments, pods, topology, live operational issues, and logs — via MCP, Radar allows external clients, CLI tools, and AI agents to programmatically query and analyze Kubernetes workloads without direct, high-privilege access to the raw Kubernetes API. In this blog post, I explore an end-to-end testing environment for Radar. I tested the overall system architecture, set up a sample Go workload (hello-k8s), inspect a Fyne-based GUI desktop client, and run an autonomous 7-step ReAct agent that performs cluster diagnostics over MCP. I used IBM Bob SDLC for the implementation. 🏗️ System Architecture & Data Flow To test Radar locally on macOS without Docker Desktop, I leveraged Minikube powered by the Podman driver and CRI-O runtime. Because Minikube’s Podman driver places the VM inside an AppleHV VM whose internal IP (192.168.49.x) is not directly routed to the host machine, I implemented background kubectl port-forward tunnels to bridge the local host to the internal cluster services: localhost:30928 → Radar Pod (:9280) localhost:30800 → hello-k8s Pod (:8080) Deploying the Sample Workload (hello-k8s) To give Radar and our MCP clients a realistic workload to inspect, a a lightweight HTTP application written in Go is deploye. The application tracks request counts, renders pod metadata obtained via the Kubernetes Downward API, and exposes health probes at /healthz. Workload Manifest (k8s/hello-k8s.yaml) A 2-replica deployment is set-up, so that Radar can construct a multi-pod service topology graph: apiVersion: apps/v1kind: Deploymentmetadata:name: hello-k8snamespace: hello-k8slabels: app: hello-k8sspec:replicas: 2selector: matchLabels: app: hello-k8stemplate: metadata: labels: app: hello-k8s spec: containers: - name: hello-k8s image: hello-k8s:latest imagePullPolicy: Never ports: - name: http containerPort: 8080 env: - name: PORT value: \"8080\" - name: POD_NAME valueFrom: fieldRef: fieldPath: metadata.name - name: POD_NAMESPACE valueFrom: fieldRef: fieldPath: metadata.namespace readinessProbe: httpGet: path: /healthz port: 8080 initialDelaySeconds: 3 periodSeconds: 5 resources: requests: cpu: 10m memory: 16Mi limits: cpu: 100m memory: 64Mi---apiVersion: v1kind: Servicemetadata:name: hello-k8snamespace: hello-k8sspec:type: NodePortselector: app: hello-k8sports: - name: http port: 8080 targetPort: 8080 nodePort: 30800 Enter fullscreen mode Exit fullscreen mode Desktop Monitoring: Building a Fyne MCP GUI Client Rather than accessing raw Kubernetes endpoints directly, the custom GUI client communicates purely over HTTP JSON-RPC using the Model Context Protocol (MCP) endpoint provided by Radar at /mcp. The client uses the official @modelcontextprotocol/go-sdk to establish stateless HTTP transport sessions and execute tools like get_dashboard and issues. MCP Transport Invocation (gui-client/main.go) func (c *MCPClient) callTool(ctx context.Context, toolName string, args map[string]any) ([]byte, error) {client := mcp.NewClient(&mcp.Implementation{ Name: \"radar-mcp-gui\", Version: \"1.0.0\",}, nil)​transport := &mcp.StreamableClientTransport{ Endpoint: c.endpointURL,}​session, err := client.Connect(ctx, transport, nil)if err != nil { return nil, fmt.Errorf(\"connect to %s: %w\", c.endpointURL, err)}defer session.Close()​result, err := session.CallTool(ctx, &mcp.CallToolParams{ Name: toolName, Arguments: args,})if err != nil { return nil, fmt.Errorf(\"call %q: %w\", toolName, err)}​var combined []bytefor _, content := range result.Content { if tc, ok := content.(*mcp.TextContent); ok { combined = append(combined, []byte(tc.Text)...) }}return combined, nil} Enter fullscreen mode Exit fullscreen mode Decoupled Data Fetching Loop To keep the UI responsive, a background goroutine fetches data snapshots on every poll interval (e.g., 10s) and passes updates over a buffered channel to the main thread: // Background fetch loopsnapCh := make(chan ClusterSnapshot, 1)​go func() {ctx := context.Background()for { snap := fetchSnapshot(ctx, mcpClient) select { case snapCh <- snap: default: // Drop if UI thread is busy } time.Sleep(cfg.PollInterval)}}() Enter fullscreen mode Exit fullscreen mode Automated Diagnostics: The 7-Step ReAct Agent To automate workload inspection, a Go CLI agent (radar-agent) that acts as an autonomous operator is implemented. It runs a deterministic 7-step ReAct (Reason + Act) loop using Radar's MCP tool set. Agent Investigation Data-Flow Implementation of the ReAct Loop (agent/main.go) Here is an excerpt showing how the agent executes the observation phase and lists resources: func run() error {flag.Parse()client := newMCPClient()ctx := context.Background()​// Step 1: OBSERVE cluster healthstep(1, \"OBSERVE\", \"cluster overview via get_dashboard\")dash, err := stepObserve(ctx, client, *flagNamespace)if err != nil { return fmt.Errorf(\"observe: %w\", err)}​// Step 2: FOCUS on targeted podsstep(2, \"FOCUS\", fmt.Sprintf(\"list pods in namespace %q\", *flagNamespace))pods, err := stepListPods(ctx, client, *flagNamespace)if err != nil { fmt.Printf(\" Warning: %v\\n\", err)}​// Step 3: INSPECT Deployment spec/statusstep(3, \"INSPECT\", fmt.Sprintf(\"get_resource deployment/%s\", *flagWorkload))dep, _ := stepInspectDeployment(ctx, client, *flagNamespace, *flagWorkload)​// Step 4: TOPOLOGY graph analysisstep(4, \"TOPOLOGY\", fmt.Sprintf(\"get_topology namespace=%q\", *flagNamespace))topo, _ := stepTopology(ctx, client, *flagNamespace)​// Step 5: Live operational ISSUESstep(5, \"ISSUES\", fmt.Sprintf(\"issues namespace=%q\", *flagNamespace))issues, _ := stepIssues(ctx, client, *flagNamespace)​// Step 6: Sample LOGSstep(6, \"LOGS\", fmt.Sprintf(\"get_workload_logs deployment/%s\", *flagWorkload))logs, _ := stepLogs(ctx, client, *flagNamespace, *flagWorkload)​// Step 7: Print Final Summarystep(7, \"REPORT\", \"structured summary\")// ... renders formatted report to stdout ...return nil} Enter fullscreen mode Exit fullscreen mode 🛠️ Running the Test Environment To test the full stack on your local machine, follow these steps: Provision Cluster & Deploy Stack Run the setup script to initialize Minikube, deploy Radar via Helm, build hello-k8s, apply RBAC patches, and start port-forwarding: chmod +x scripts/*.sh ./scripts/deploy.sh Enter fullscreen mode Exit fullscreen mode Run the Autonomous Agent Execute the Go CLI agent to inspect the hello-k8s namespace: ./scripts/run-agent.sh --namespace hello-k8s --workload hello-k8s Enter fullscreen mode Exit fullscreen mode Sample agent output: ════════════════════════════════════════════════════════════ RADAR AGENT REPORT Goal : Investigate the hello-k8s workload and summarise its health Namespace : hello-k8s Workload : hello-k8s ════════════════════════════════════════════════════════════ ​ CLUSTER OVERVIEW Health: healthy (cluster: minikube v1.28.0) Pods: healthy=4 warning=0 error=0 Nodes: total=1 ready=1 notReady=0 Total problems: 0 ​ PODS IN NAMESPACE \"hello-k8s\" hello-k8s-74b884988f-2k9ll Running ready=1/1 node=minikube hello-k8s-74b884988f-b98x7 Running ready=1/1 node=minikube ​ DEPLOYMENT: hello-k8s Replicas: 2 desired / 2 ready / 2 available Container: hello-k8s → hello-k8s:latest ​ TOPOLOGY (namespace \"hello-k8s\") 3 nodes, 2 edges ​ LIVE ISSUES No issues found — workload looks healthy. ════════════════════════════════════════════════════════════ Enter fullscreen mode Exit fullscreen mode Launch the Fyne Desktop GUI Start the desktop monitoring application: ./scripts/start.sh Enter fullscreen mode Exit fullscreen mode Key Takeaways & Design Decisions | Technical Decision | Rationale | | ------------------------------------ | ------------------------------------------------------------ | | **Podman Driver + CRI-O** | Enables containerized Kubernetes testing on macOS without relying on Docker Desktop. MD | | **`kubectl port-forward` Tunneling** | Solves AppleHV VM network isolation by routing `localhost:30928` directly to Radar's container port. MD | | **Chart Tag Pinning (`1.7.0`)** | Prevents version mismatch crashes with Helm flags present in newer chart versions. MD | | **RBAC Supplemental Patch** | Adds missing `rbac.authorization.k8s.io` read permissions required for Radar's permission inspection panels to function properly. MD | | **Model Context Protocol (MCP)** | Decouples direct Kubernetes API access from monitoring tools, allowing lightweight agents and GUIs to consume structured cluster context safely. MD+ 1 | Enter fullscreen mode Exit fullscreen mode Conclusion By exposing cluster telemetry and operational controls through the Model Context Protocol, Radar transforms Kubernetes monitoring from a manual dashboard-checking task into a programmatic foundation for automation. Whether powering custom desktop GUIs like Fyne or enabling autonomous ReAct agents to run multi-step diagnostic workflows, MCP bridges the gap between raw cluster metrics and intelligent operational tools. As container environments continue to grow in complexity, decoupling cluster context from high-privilege API access via MCP offers a cleaner, safer, and far more extensible approach to Kubernetes management. Thanks for reading 🍇 Links Radarhq.io: https://radarhq.io/ Radarhq Github Repository: https://github.com/skyhook-io/radar Sample implementation with specified skills for Podman and Minikube: https://github.com/aairom/radar-k8s-test Specific Skills for macOS / Minikube / Podman: https://github.com/aairom/radar-k8s-test/tree/main/.bob/skills","contentHash":"sha256:9c6c6e81715339d9f4b164d91a938c66f6fec5019cffc30e7d18eb12d4505194","authorName":"Alain Airom (Ayrom)","authorUrl":"https://zyvop.com/author/alain","authorSameAs":["https://github.com/aairom","https://www.linkedin.com/in/aairom/"],"category":null,"tags":["clusters","Agents","podman","Kubernetes"],"audience":"Senior software engineers, systems architects, and technical leads working with clusters","tone":"In-depth technical and architectural analysis","readingTimeMinutes":6,"wordCount":1300,"faqs":null,"primaryTopic":"clusters","publishedAt":"2026-08-31T05:47:46.518Z","updatedAt":"2026-08-31T13:40:24.909Z","canonicalUrl":"https://dev.to/aairom/deep-dive-testing-radar-ui-for-kubernetes-using-mcp-a-go-gui-and-an-autonomous-agent-4ioi"}