k9s

What it is and where it fits 🎯#

k9s is a full-screen terminal UI for browsing and operating a Kubernetes cluster — the tool you reach for once kubectx/kubens have you pointed at the right place and you need to actually look around: list pods, tail logs, describe a resource, jump into a shell, edit a manifest, or kill a stuck pod, all without retyping kubectl get/describe/logs/exec dozens of times with slightly different arguments each time. It's not a replacement for kubectl in scripts or CI — it's an interactive human tool, meant to be launched into a terminal pane and left running while you work. Where it differs from stern: stern is a single-purpose, non-interactive log multiplexer you'd wire into a pipeline or leave streaming in a pane; k9s is a general resource browser that happens to include a log view among many other resource-specific actions.

The three-layer navigation model#

This is the mental model that makes k9s fast: every screen is one keystroke from a resource-appropriate action, and esc always backs out one level rather than closing the whole app. Once this loop is muscle memory, most day-to-day debugging never touches kubectl directly again.

Installation#

brew install derailed/k9s/k9s               # macOS/Linux Homebrew (dedicated tap)
sudo apt-get install k9s                    # Debian/Ubuntu, if present in your repos

# or download the release binary directly (verified release: v0.51.0):
curl -sL -o k9s.tar.gz \
  https://github.com/derailed/k9s/releases/download/v0.51.0/k9s_Linux_amd64.tar.gz
tar -xzf k9s.tar.gz k9s && sudo mv k9s /usr/local/bin/

k9s version

Real captured k9s version output:

Launch flags#

Real k9s --help output (v0.51.0, trimmed to the flags a day-to-day user actually reaches for):

k9s                                          # launch scoped to the current kubeconfig context/namespace
k9s --context prod-cluster --namespace checkout   # launch directly scoped, skipping the manual :ctx / :ns step
k9s -A                                       # launch in all-namespaces mode from the start
k9s -c deploy                                # open straight into the Deployments view, skipping the pod table
k9s --readonly                               # disable every mutating action (delete, edit, scale) for this session
k9s -r 5                                     # slow the refresh rate to every 5s — kinder to a heavily-loaded API server

Command mode — the : prefix#

Press : to enter command mode, type a resource name (or its short alias), and hit enter to jump straight to that resource's table view — this is the primary way to move around k9s, faster than arrow-key menu navigation once memorized. Per the official docs, command mode supports filters and cross-context/namespace jumps inline:

Filters compose directly onto a resource command:

Keybindings — general navigation#

Keybindings — acting on a selected resource (pod-focused)#

Hotkeys — user-defined shortcuts (hotkeys.yaml)#

Beyond the built-in keybindings above, k9s supports fully custom shortcuts for resources/filters you jump to often, defined in $XDG_DATA_HOME/k9s/hotkeys.yaml (typically ~/.local/share/k9s/hotkeys.yaml on Linux) and hot-reloaded automatically — no restart needed after editing it:

# ~/.local/share/k9s/hotkeys.yaml
hotKeys:
  shift-0:
    shortCut: Shift-0
    description: View pods labeled app=kindnet
    command: pods app=kindnet
  shift-1:
    shortCut: Shift-1
    description: Jump straight to Deployments
    command: dp
  shift-2:
    shortCut: Shift-2
    description: XRay view of Deployments
    command: xray deploy

Defined hotkeys show up in the ? help screen automatically, so a team can standardize a shared hotkeys.yaml for the specific resources their on-call rotation checks most.

Aliases — custom short names for resources#

Separately from hotkeys, aliases.yaml (same $XDG_DATA_HOME/k9s/ directory) lets a team define its own short names usable in command mode, the same way po is already a built-in alias for pod:

# ~/.local/share/k9s/aliases.yaml
alias:
  cronjobs: cj
  mycrd: mycrd.example.com/v1

Config — config.yaml#

k9s's own behavior (refresh rate, default view, readOnly mode, logging level) lives in $XDG_CONFIG_HOME/k9s/config.yaml (typically ~/.config/k9s/config.yaml):

# ~/.config/k9s/config.yaml
k9s:
  refreshRate: 2
  maxConnRetry: 5
  readOnly: false
  noExitOnCtrlC: false
  ui:
    skin: dracula
    enableMouse: false
  logger:
    tail: 200
    buffer: 5000

Real-world scenario: triaging a CrashLoopBackOff during an incident#

An SRE gets paged for pods stuck in CrashLoopBackOff in checkout. The full k9s loop for this, from launch to root cause, is genuinely faster than the equivalent sequence of separate kubectl invocations:

Real-world scenario: safely handing a teammate temporary production access#

A platform engineer needs a teammate on another team to check something in a production namespace during an incident, without granting a permanent kubectl credential or risking an accidental mutation:

k9s --context prod-cluster --namespace checkout --readonly

Common pitfalls#

• Assuming l (logs) shows the crash, when the pod already restarted — the fresh container's logs are often empty or just starting up; p (previous logs) is what actually holds the crash's last output.
• Forgetting --readonly is per-launch, not a saved preference, unless it's also set in config.yaml's readOnly: true — a habit of always launching with the flag against production contexts is safer than relying on remembering to set it.
• Not realizing :pod @ctx1 exists and manually switching context via :ctx just to check one other cluster's pods, then switching back — the inline @context filter avoids the round trip entirely.
• Running k9s inside a CI job or a non-interactive script — it's a TUI that expects a real terminal; there is no headless/scriptable output mode suitable for pipeline automation. Reach for kubectl directly, or stern for log-specific automation, in anything non-interactive.

Exit codes#

k9s is an interactive application, not a scriptable CLI — exit status reflects whether the TUI launched and exited cleanly (0) versus a startup failure (bad kubeconfig, unreachable API, invalid flag combination), not the outcome of anything done inside the session.

When to reach for something else#

For a non-interactive, scriptable log tail across many pods/containers at once (a pipeline debugging job, a kubectl-adjacent one-shot log capture), reach for stern instead — k9s's log view is built for a human watching it live, not for piping/redirecting output. For pure context/namespace switching without launching a full TUI, kubectx/kubens remain the faster single-purpose tools; k9s's own :ctx/:ns command-mode views exist mainly so you don't have to leave k9s once you're already inside it.