ku: Fast Keyboard-Driven Kubernetes TUI Released on GitHub

GitHub trending project ku delivers a fast TUI for Kubernetes allowing resource browsing, object editing, log following and pod shell access.

ku: Fast Keyboard-Driven Kubernetes TUI Released on GitHub

News Summary

is a new terminal user interface for Kubernetes written in Go. It provides keyboard-driven navigation across cluster resources, in-place editing, log streaming, and direct pod shells. The project appeared on GitHub trending this week. It targets users who already work inside the terminal and want to avoid switching to browser-based dashboards or heavier desktop clients.

Core Capabilities and Workflow

ku starts against the current kubeconfig context and keeps the last used namespace in a small state file. From the main view you can filter any resource type, jump to a specific kind with a command palette, or open the editor for the selected object. Changes written back to the cluster use the same kubectl-style patch mechanism.

Log following works without spawning extra processes; the TUI streams events directly and supports regex filtering on the fly. Shell access reuses the standard exec protocol so existing RBAC rules apply unchanged. The rendering layer is built on Bubble Tea, which keeps input latency low even when watching high-volume log streams from multiple pods.

Compared with k9s, ku exposes fewer built-in plugins but adds a simpler command palette and explicit CRD registration. Resource lists update through the standard watch API rather than polling, which reduces both CPU usage on the client and etcd load on the control plane.

Installation Options

Three installation paths are documented. The curl installer downloads a prebuilt binary for common platforms. Go users can run go install github.com/bjarneo/ku@latest. Building from source requires Go 1.21 or newer and produces a static binary that can be dropped into any PATH directory.

Once installed, the binary reads an optional YAML file at ~/.config/ku/config.yaml. A single command seeds the defaults so users only need to append custom resources under the sidebar sections they want. Resources that do not exist in the cluster are silently dropped at startup, keeping the navigation tree clean.

Extending the Sidebar with CRDs

Custom resources must be declared with either their plural name or the fully qualified form plural.group. This avoids collisions when multiple API groups register similar short names. After editing the config file, a restart is enough; ku does not watch the config for changes at runtime.

State such as last selected namespace and expanded sections is written to state.json in the same directory. Deleting that file resets the session without touching cluster objects. No telemetry or external calls are performed beyond the Kubernetes API server address already present in kubeconfig.

Limitations Observed So Far

The project is still young. RBAC errors surface only when an action is attempted rather than being hidden up front. Multi-cluster switching is not implemented; users must maintain separate contexts or run separate ku instances. Theme support exists but is limited to a handful of color schemes bundled at compile time.

FAQs

Does ku require any cluster-side components? No. It uses only the standard Kubernetes client-go libraries and the same permissions already granted to your kubeconfig user.

Can I use ku inside a CI job or headless environment? It is a TUI application and expects a terminal. Headless execution is not supported.

How does ku handle large numbers of resources? It relies on the watch API and client-side caching. Performance depends on the size of the cluster and available memory on the workstation running the TUI.

---

๐Ÿ“– Related articles

Need a consultation?

I help companies and startups build software, automate workflows, and integrate AI. Let's talk.

Get in touch
โ† Back to blog