The Problem
Kubernetes operators spend a disproportionate amount of time switching between kubectl invocations, editors, and browser-based dashboards to inspect resources, follow ownership chains, and debug workloads. The context-switching cost is real: each command requires recalling API groups, resource names, and output flags. LFK addresses this by putting the cluster state into a keyboard-driven, three-column terminal UI where navigation follows the owner hierarchy (Cluster → Resource Types → Resources → Owned Resources → Containers) rather than forcing users to construct queries manually.
What This Does
LFK is a Go-based TUI (154 Go files) that renders a Miller-columns layout inspired by the yazi file manager. The core application logic lives in internal/app/, with app.go as the entry point. The command system is split across commands.go, commandsbuiltin.go, commandsexec.go, commandslogs.go, commandsportforward.go, and commandsgitops.go, giving it a broad surface: logs, exec, port-forward, scale, delete, describe, edit, and ArgoCD/Helm integrations.
The repo also ships several non-core features that indicate maturity: an API explorer (updateoverlaysevents.go), a RBAC "can-i" browser (updatecani.go), a YAML editor (updateyaml.go), and a configurable theming system (cmd/themegen/main.go). Multi-cluster support is handled via merged kubeconfig loading, and tabs allow side-by-side views. The docs/ folder (18 files) includes keybinding and config references, which is a good sign for usability.
How To Use It
Setup: Build from source with Go modules (go.mod present) or use the provided Dockerfile. There is no Makefile target for installation, so the build path is go build ./cmd/lfk (the main binary entry point is not explicitly named in the file listing, but cmd/ contains themegen only — the main binary likely lives at the repo root or is built via go build .). The Makefile exists but its targets are not documented in the README excerpt.
Configuration: LFK reads a YAML config file (see docs/config-example.yaml). Key options include pinnedgroups for CRD ordering and per-context settings. Keybindings are fully customizable via the same config. No environment variables are documented in the excerpt.
Running it: After building, invoke the binary. The README does not list explicit run commands, so the exact invocation is not verifiable from the provided files.
Build from source
go build -o lfk .
Run
./lfk
Real-World Use
A platform engineer debugging a failing pod in a staging cluster: launch LFK, navigate to the Workloads group, select the Deployment, drill into the owned ReplicaSet, then the Pod, then the container. From there, open logs, exec into the shell, or port-forward — all without leaving the TUI. The ArgoCD integration lets you check sync status and trigger syncs from the same interface, which collapses what would normally be three separate tools (kubectl, ArgoCD UI, log viewer) into one session.
Code Health & Issues
Med - Large internal/app monolith: 152 files in one package suggests weak separation of concerns. Files like updatekeys.go, updatekeysactions.go, and updatenavigation.go are all in the same package, which will make testing and refactoring harder as the codebase grows. Low - Unverified build path: The cmd/ directory only contains themegen. The main binary entry point is not clearly identified, which could confuse first-time contributors. Low - No explicit go.mod version pinning info: The go.mod exists, but the Go version and dependency versions are not visible in the provided data. Dependency hygiene cannot be fully assessed. Positive: 93 test files indicate a serious testing culture. CI is configured (.github/workflows/ci.yml), plus release, stale, and PR validation workflows. SonarCloud, Go Report Card, and Codecov badges are present. A LICENSE file exists. No obvious secrets or config-in-repo issues.
The Bottom Line
LFK is a well-tested, feature-rich terminal UI for Kubernetes that could genuinely replace kubectl + browser dashboards for daily operations. The owner-based navigation and GitOps integrations are the standout differentiators. It is best suited for operators who live in the terminal and manage multiple clusters; teams that prefer GUI dashboards will not find it compelling. The main risk is the monolith package structure, which may slow future maintenance, but the current test coverage mitigates that.