Kubernetes Workspaces: Stop Rebuilding Your Dashboard View Every Time You Switch Context
Your cluster has 400 resources. You care about 12 of them right now. Tomorrow it'll be a different 12.
The tab-and-filter tax
You open your Kubernetes tool. You need to check the status of a specific set of workloads across two namespaces. So you filter. You hide columns you don't need. You get the view you want.
Then a Slack message comes in: "Can you check the Flux reconciliation on staging?" Different cluster, different resources, different filters. You switch context, and your previous view is gone. When you come back to the first task, you start over.
This happens five, ten, fifteen times a day. Every context switch costs you the setup time. Not because the data is hard to find, but because no tool remembers what you were looking at.
kubectl doesn't have this problem, technically. It doesn't have views at all. You type a command, get output, move on. But that's also why kubectl doesn't scale past a certain complexity. When you're managing multiple clusters with dozens of namespaces and hundreds of resources, you need persistent views. You need to be able to set up a perspective on your cluster and come back to it later.
What a workspace actually is
In Kunobi v0.1.0-beta.25, workspaces became a first-class concept. A workspace is a saved configuration of your filterbar state and column visibility. That's it. No magic, no abstraction layer on top of Kubernetes. Just a snapshot of how you were looking at your cluster.
You can create as many as you need. A few examples from how we use them internally:
"Prod incidents" filters to show only Pods in CrashLoopBackOff, Error, or Pending states across all production namespaces. When something breaks, this view is one click away.
"Flux sync status" groups resources by GitOps tool and shows reconciliation state. We ship a variant of this as a built-in GitOps workspace that auto-detects whether you're running Flux, Argo, or both.
"My team's services" filters to a specific label selector and hides infrastructure columns. The new engineer on your team can pin this on day one and immediately see only what matters to them.
Each workspace can be pinned to the sidebar for single-click access. Press Shift+P to pin or unpin.
Filter presets
Workspaces remember your full view state, but sometimes you want to save just a filter configuration and apply it across different pages. That's what filter presets do.
Save your current filterbar as a named preset. Restore it with one click. Rename it, delete it, or quick-save with a keyboard shortcut. The preset system is separate from workspaces on purpose: a preset is portable, a workspace is contextual.
The "General" vs "Advanced" split
Kubernetes has a lot of resource types. Most engineers work with a handful of them daily and touch the rest occasionally. Kunobi now lets you choose a default landing view:
General shows the common resources: Pods, Deployments, Services, ConfigMaps, Secrets, Ingresses. If you're doing day-to-day operations, this keeps the noise down.
Advanced shows extended resource types, including CRDs. If you're debugging a Flux HelmRelease or an Argo Application, you need the full picture.
You pick which one Kunobi opens to. You can switch between them at any time.
The GitOps workspace
This one deserves its own section because it solves a specific problem: GitOps resources are scattered across the standard Kubernetes resource list with no grouping.
When you install Flux or Argo CD, you get CRDs like HelmRelease, Kustomization, GitRepository, OCIRepository, Application, and others. In kubectl, these are just more entries in kubectl get all. In most GUIs, they show up in a flat list mixed in with everything else.
The GitOps workspace in Kunobi auto-detects which GitOps controllers are installed in your cluster and groups their resources together. You see your Flux sources, your kustomizations, and your releases in one view without manually setting up filters.
This works because Kunobi reads the installed CRDs at connect time. If you're running Flux, you get Flux groupings. Argo, you get Argo groupings. Both, you get both. No configuration needed.
Keyboard-driven view switching
We added a unified view mode selector that lets you switch between layout options, visualization styles, or event types for each page. The shortcut is Cmd+Shift+V on Mac, Ctrl+Shift+V on Windows and Linux. Your selection is remembered per page.
The right sidebar also got full keyboard navigation in this release:
Alt+Arrowkeys to focus and unfocus the sidebarCtrl+D/Ctrl+Ufor half-page scrolling (same as Vim)J/Kor arrow keys to move between elements
We keep adding keyboard shortcuts because Kunobi is built for engineers who think in keystrokes. If your hands leave the keyboard to click a filter dropdown, we consider that a bug in our design.
Why this matters for multi-cluster setups
The workspace concept becomes more valuable as your cluster count grows. A platform team managing 10+ clusters typically has recurring views they need:
The "all staging clusters" view. The "production Flux status" view. The "this specific microservice across all environments" view.
Without saved workspaces, each of these views is rebuilt from scratch on every session. With them, your morning standup starts with two clicks: open Kunobi, click the pinned workspace. The view you set up last week is exactly as you left it.
Try it
Workspaces ship in Kunobi v0.1.0-beta.25. Download the update, connect to a cluster, and set up your first workspace. Pin it. Switch to something else. Come back.
Your view will still be there.
Kunobi v0.1.0-beta.25 introduces workspaces, filter presets, the GitOps workspace, and keyboard-driven view switching. Full changelog · Download