Kubeside for App-First Kubernetes Debugging
Most Kubernetes tools mirror the API: pick a context, pick a resource type, inspect objects, then stitch the story together. That works for cluster operators, but it is slow when the question is simpler: is my app healthy in qa, staging, and production?
Kubeside takes the opposite view. It reads the kubeconfig already on your machine, loads reachable contexts, and builds an app-centered screen from Kubernetes data your clusters already keep.
What Is Kubeside?
Kubeside is an open source Kubernetes client written in Go with an embedded UI. It runs locally on 127.0.0.1, talks to clusters from the local process, and does not install an agent, database, cache, or controller.
The tool focuses on four operational questions:
- Is this app up?
- What changed, and when?
- What do logs say across all pods?
- What configuration did the container actually receive?
That narrow scope is the point. Kubeside reduces the time between "prod looks wrong" and "this rollout, config value, pod state, or environment drift explains it."
Key Features
- App grouping across contexts: workloads are grouped into apps, so qa, staging, and prod can be compared side by side.
- Timeline reconstruction: ReplicaSets, ControllerRevisions, Helm release secrets, pod termination states, and events are used to explain what changed.
- Whole-workload logs: operators can inspect logs across every pod in an app without hopping through tabs and selectors.
- Resolved configuration: environment variables,
envFrom, ConfigMaps, Secrets, downward API values, and mounted volumes are attributed to their sources. - Explicit permission gaps: missing reads or refused actions are labelled instead of being rendered as quiet empty states.
Installation
On macOS, install with Homebrew:
brew install dynaum/tap/kubeside
kubeside
Linux and Windows builds are available from the releases page. Until a tagged release is available, the project documents a source build:
git clone https://github.com/dynaum/kubeside
cd kubeside
npm --prefix web ci
npm --prefix web run build
go build ./cmd/kubeside
./kubeside
If kubectl works, Kubeside should be able to use the same kubeconfig and exec credential plugins.
Operational Usage
Start with the terminal check before opening the UI:
kubeside --print
This prints reachable contexts, grouped apps, readiness, object counts, and the grouping rule used. During incident response, a context that cannot be reached gets its own row instead of silently disappearing.
For production, review the write guardrails before giving broad access. Kubeside supports port-forward, exec, restart, and pod delete flows, but each action is checked against Kubernetes RBAC and an environment write policy. Prod can require typed confirmation or a break-glass reason.
Security Notes
Kubeside keeps credentials on the local machine. The browser talks to 127.0.0.1; the local process talks to the apiserver. Secret values are masked by default, and reveal actions are checked with Kubernetes authorization before use.
For strict namespace boundaries, the important design choice is that controls are disabled and labelled when RBAC denies them. That gives engineers a concrete request like create on pods/exec instead of a missing button.
Conclusion
Kubeside is worth watching because it solves a real debugging shape: app-first Kubernetes operations across environments. It will not replace observability, policy, or cluster administration tools, but it can shorten the path from alert to rollout context.
If your team wants AI-assisted incident workflows built on reliable Kubernetes context, Akmatori helps SRE teams investigate alerts, coordinate response, and automate safe infrastructure actions. Powered by Gcore for global infrastructure reliability.