Set Up Kubernetes Monitoring in 5 Minutes (No Cloud Account)

Most Kubernetes monitoring solutions require you to create a cloud account, install agents into your cluster, configure exporters, and wait for data to start flowing through someone else's infrastructure. That's a lot of setup for something that should be simple: seeing what's happening in your cluster right now. CPI-Control takes a different approach. It runs entirely on your machine, connects directly to your cluster via your existing kubeconfig, and gives you full visibility in about five minutes. No sign-ups, no cloud dependencies, no credit card.

Prerequisites

Before you start, make sure you have three things ready. First, a running Kubernetes cluster — this can be a production cluster on any cloud provider, a managed service like EKS, GKE, or AKS, or even a local cluster running via minikube, k3s, or Docker Desktop. Second, a kubeconfig file that grants access to that cluster. If you can run kubectl get pods successfully, your kubeconfig is working. Third, a Mac or Windows machine to run CPI-Control on. The app is a native desktop application built with Tauri, so it runs as a lightweight binary with minimal resource usage.

Step 1: Download CPI-Control (30 Seconds)

Head to the CPI-Control homepage and download the installer for your operating system. On macOS, you'll get a standard .dmg file — drag it to your Applications folder and open it. On Windows, run the .msiinstaller. The entire application is under 30 MB because it doesn't bundle a browser engine or a JVM. Once installed, launch CPI-Control. You'll see an empty dashboard with a prompt to connect your first integration.

Step 2: Upload Your Kubeconfig (30 Seconds)

Navigate to Settings → Integrations → Kubernetes and click Add Cluster. You can either browse for your kubeconfig file (typically located at ~/.kube/config) or drag and drop it directly into the upload area. Give your cluster a descriptive name — something like "production-eu" or "staging-us-east" — so you can identify it later if you add more clusters.

CPI-Control reads the kubeconfig locally and never sends it to any external server. The file stays on your machine, and all API calls go directly from your desktop to the Kubernetes API server. This is a fundamental architectural decision: your credentials never leave your device.

Step 3: Auto-Discovery (2 Minutes)

After uploading your kubeconfig, CPI-Control immediately starts scanning your cluster. The SyncScheduler iterates through all namespaces, discovers Deployments and Services, and cross-references Ingress resources to determine which services are publicly accessible and which are internal. Each discovered workload is automatically registered as a service in CPI-Control with the correct type: "Public" for services with an Ingress, "Private" for everything else.

The discovery process also resolves infrastructure bindings using the namespace/deployment-nameformat as external identifiers. This means CPI-Control knows exactly which Kubernetes resources belong to which logical service, even when deployment names differ from service names. The entire scan typically takes under two minutes, even for clusters with hundreds of workloads. You'll see services appearing on your dashboard in real time as they're discovered.

Step 4: See Everything (1 Minute)

Once discovery completes, your dashboard transforms into a complete overview of your cluster. Every service shows its current health status — healthy, degraded, or down — based on pod readiness. Click on any service to see detailed information: the number of running pods, their individual statuses, recent Kubernetes events (like OOMKilled restarts or failed scheduling), and current resource usage for CPU and memory.

The service list is sortable and filterable. You can group services by namespace, filter by health status to quickly find problematic workloads, or search by name. Each service card shows the provider logo (in this case, the Kubernetes icon) so you can instantly distinguish K8s services from those managed by other providers like Vercel or GitHub.

Step 5: Enable Health Monitoring

For services that expose HTTP endpoints, you can add URL-based health checks for more granular monitoring. Open any service, go to the Monitoringtab, and add the URL you want to check. CPI-Control will periodically send HTTP requests to that endpoint and track response codes and latency. A 200 response marks the service as healthy. A 404 is also treated as healthy — it means the server is responding, just not at that specific path. Only connection failures and 5xx errors trigger a degraded or down status.

You can configure check intervals and set thresholds for response time. If a service consistently responds in over 2 seconds, for example, you might want to flag it as degraded even though it's technically up. These thresholds are fully customizable per service, because a 500ms response time means very different things for a user-facing API versus an internal batch processor.

What You Get Immediately

Without any additional configuration beyond the kubeconfig upload, CPI-Control gives you several capabilities that typically require separate tools or paid services. Pod metrics including CPU and memory usage are pulled directly from the Kubernetes metrics API — no Prometheus installation required. Kubernetes events are collected and displayed per service, so you can see OOMKills, failed probes, image pull errors, and scheduling failures without running kubectl describe in a terminal.

Live logs are collected using stern under the hood, which means you get aggregated logs from all pods in a deployment, with color coding per pod. The logs are streamed in real time via SSE (Server-Sent Events) and stored in an in-memory ring buffer, so there's no disk usage and no external log storage needed. You can open a floating log window that stays visible while you navigate the rest of the dashboard — perfect for tailing logs while investigating an issue.

Terminal access lets you exec into any running pod directly from the dashboard, without switching to a terminal and remembering the exact pod name and namespace. This is especially useful during incident response when you need to quickly inspect a container's filesystem or run diagnostic commands.

Next Steps

Once your Kubernetes monitoring is running, consider connecting additional providers to build a more complete picture of your infrastructure. Add a GitHub token to track deployments from GitHub Actions — every push, every CI run, every release will appear alongside your Kubernetes data. Add a Vercel API token to monitor your frontend deployments. CPI-Control correlates deployments across providers, so you can see which commit triggered which deployment and trace issues back to specific changes.

You can also enable push notifications to get alerted when services go down or deployments fail. Notifications are delivered via the operating system's native notification system and in-app toasts, so you don't need to configure a separate alerting tool or set up email integrations. Everything stays local, everything stays fast, and you maintain full control over your monitoring data.