k9s

Every question kubectl answers, it answers once — you type a command, the server replies, the terminal goes still, and if you want to know whether anything changed you type the same command again. k9s exists to remove that gap. It's a terminal UI that opens a live, continuously-refreshing table onto whatever resource you're looking at, lets you jump between resource types by typing a couple of characters instead of a full command line, and turns describe/logs/exec/edit/delete — the five things you do to a Pod fifty times a day — into single keystrokes fired at whatever row your cursor is sitting on. It is not a separate control plane, a caching proxy, or a privilege of its own: underneath, it opens the identical watch connections and issues the identical authenticated requests kubectl would, against the same kube-apiserver, subject to the same RBAC. This page covers how it's built, the screen you're looking at, the config files you'll actually hand-edit, the keybindings worth committing to muscle memory, where it bites, and how it stacks up against Lens and the Kubernetes Dashboard.

What k9s actually is: a watch, not a shortcut around anything

☺ Like you're 10: It's not a secret back door into the cluster — it's the same front door kubectl uses, just left open on your screen instead of closed after every question.

The Kubernetes API & the controller pattern already established that every built-in controller works the same way: open a long-lived GET ?watch=true connection against the objects it cares about, keep a local cache in sync as events stream in, and act on the diff. k9s runs the identical pattern, just in service of a human instead of a reconcile loop — it opens watches (via client-go, the same Go library controllers are built on) against whatever resource list is on screen, and every row updates the instant the API server emits an event for it, with no polling loop and no re-typing kubectl get. That's the entire trick behind "live" — it isn't refreshing faster, it's being told the moment something changes, the same signal a controller reconciles on.

Two consequences follow directly from that, and both matter more than they sound like they should. First, k9s needs nothing installed in the cluster — no Deployment, no Service, no extra attack surface running alongside your workloads, unlike the Kubernetes Dashboard covered later on this page. It reads your kubeconfig exactly like kubectl does and talks straight to kube-apiserver from your own machine. Second, every action you trigger from a row — e to edit, Ctrl-D to delete, s to shell in — becomes a perfectly normal, individually authenticated API request, evaluated against RBAC and admission control exactly like a kubectl invocation would be. k9s has no elevated identity of its own to fall back on; if your RoleBinding doesn't grant delete on Pods, pressing Ctrl-D in k9s fails the exact same way kubectl delete pod would, just inside a UI instead of a shell prompt.

The screen, oriented

☺ Like you're 10: Four zones, always in the same place — where you are, what's in front of you, what you typed, and what your fingers can do about it right now.

Launch k9s with no arguments and it opens on the Pod list for your kubeconfig's current context and namespace — the same defaults a bare kubectl get pods would use. From there, every view on screen is built from the same four regions:

• The header (top) — current context, cluster, user, and a small CPU/memory gauge for the cluster as a whole, so you know which cluster you're looking at before you do anything else to it.
• The crumb trail (just under the header) — a breadcrumb of how you got to the current view (Pods(checkout), then drill into one and it becomes Pods(checkout)›containers), so backing out with Esc retraces exactly where you came from.
• The resource table (the bulk of the screen) — every row live, every column sortable, filterable with / the moment you start typing.
• The command line and hotkey footer (bottom) — : opens the command line for typing a resource name to jump to; the footer beneath it lists exactly the keys that do something for the resource type currently on screen — a Pod's footer offers l logs and s shell, a Node's footer doesn't, because neither action means anything for a Node.

That last point is worth sitting with: k9s's keybindings are context-sensitive by design, not one universal cheat sheet. Press ? from any view and it prints the exact, current keybinding list for that resource type — the single most reliable reference, because it can't drift out of date the way a memorized list can once you customize hotkeys.yaml (below) or upgrade versions.

Command mode: how you actually move around

☺ Like you're 10: Instead of clicking through menus, you type a short word and hit Enter — like a search bar that teleports you.

Press :, type a resource name or its short alias, hit Enter, and you're looking at that resource type across the current namespace — no re-running a whole kubectl get line, no re-typing a namespace flag you already set. k9s discovers these names from the same API server discovery endpoint kubectl's own short names come from, so most of what you already type after kubectl get works unmodified after :.

:po            jump to Pods              :svc          jump to Services
:deploy        jump to Deployments       :ns           jump to Namespaces (pick one to switch into)
:cm            jump to ConfigMaps        :ctx          jump to Contexts (pick one to switch into)
:sa            jump to ServiceAccounts   :events        cluster events, newest first
:role          Roles in this namespace   :clusterrole  cluster-scoped Roles
:pulse         cluster health dashboard: resource counts, error rates, sparklines
:xray deploy   ownership tree for every Deployment — Deployment → ReplicaSet → Pods, live
:alias         list every resource alias k9s currently knows, including any you added

:xray is worth calling out on its own: it draws the same ownerReferences tree that kubectl's tree krew plugin prints as static text — except live, expandable, and colored by health, so a ReplicaSet stuck at zero-of-three ready Pods is visually obvious rather than something you have to notice in a column of numbers. Once you're inside any list, / opens an inline filter (substring or regex) that narrows the visible rows without leaving the view, Esc clears the filter or steps back one level of the crumb trail, and Enter drills into whatever's selected — Enter on a Deployment shows its Pods, Enter on a Pod shows its containers, one level at a time, exactly mirroring the ownership hierarchy the object model page describes.

Config you actually write

☺ Like you're 10: k9s reads its own small stack of YAML files the way the cluster reads yours — a handful of settings files that shape how the tool behaves, sitting in a folder on your own machine.

k9s keeps its configuration under $XDG_CONFIG_HOME/k9s/ (typically ~/.config/k9s/ on macOS and Linux; older versions used ~/.k9s/ directly). Five files there do almost all of the customizing you'll ever want:

# ~/.config/k9s/config.yaml — top-level behavior
k9s:
  refreshRate: 2          # seconds between UI refresh ticks (not the watch itself — that's already live)
  readOnly: false         # true disables edit/delete/scale/kill actions cluster-wide, client-side
  noExitOnCtrlC: true     # require :quit or q, so a stray Ctrl-C doesn't drop you out mid-session
  ui:
    enableMouse: false
    skin: dracula          # references a file under skins/dracula.yaml
  logger:
    tail: 200
    sinceSeconds: 300
    fullScreenLogs: false

# ~/.config/k9s/plugins.yaml — shell out to any command, bound to a key, scoped to a resource type
plugins:
  all-logs:
    shortCut: Shift-L
    description: "Logs, all containers, follow"
    scopes: ["pods"]
    command: kubectl
    background: false
    args: ["logs", "-f", "$NAME", "-n", "$NAMESPACE", "--context", "$CONTEXT", "--all-containers"]

# ~/.config/k9s/hotkeys.yaml — jump straight to a saved view with one keystroke
hotKeys:
  shift-0:
    shortCut: Shift-0
    description: "Pods in kube-system"
    command: pods
    namespace: kube-system

# ~/.config/k9s/aliases.yaml — short names of your own, layered on top of the API server's own
alias:
  cko: apps/v1/deployments

Plugins are the one most worth adopting deliberately: a plugin's args gets $NAME, $NAMESPACE, and $CONTEXT substituted from whatever row is selected before the command runs, so a single keystroke can fire off a real, correctly-scoped kubectl invocation (or any other CLI — stern, a curl against a debug sidecar, your own script) without you ever typing the resource name and namespace by hand. It's the same idea as kubectl's own krew plugins, one layer up: instead of extending the CLI itself, you're binding the CLI's own commands to keys inside the UI that already knows which row you're pointing at.

Core keybindings for day-to-day work

☺ Like you're 10: A handful of single letters cover almost everything you'll do to a resource, all day, every day.

d         describe the selected resource                y        view its YAML (read-only)
e         edit it in $EDITOR, same as `kubectl edit`     l        tail logs (Pods/containers)
s         shell in (`exec -it`, Pods/containers)         Ctrl-D   delete, with a confirm prompt
Shift-F   port-forward from the selected Pod             Enter    drill into what's selected
/         filter the current view                        Esc      clear filter, or back one level
:         open the command line                           ?        context-sensitive help for this view
0-9       jump to a favorite/recent namespace              0        (on the namespace picker) all namespaces

# a realistic five minutes: chase down one Deployment's Pods, tail logs, shell in, back out
$ k9s -n checkout --context prod        # launch straight into the namespace and context you need
:deploy⏎                                 # jump to Deployments
/checkout-web⏎                           # filter to the one that matters
⏎                                        # drill in — now looking at that Deployment's Pods
l                                        # tail logs on the selected Pod
Esc  s                                   # back out of logs, shell into the same Pod
Esc  Esc                                 # back out to the Pod list, then the Deployment list
:xray deploy⏎                            # confirm the ReplicaSet and Pods actually match desired state

Gotchas and failure modes

☺ Like you're 10: Most k9s mistakes look like the tool being smart, when really it's just doing exactly what you told it, fast, in a namespace or cluster you didn't mean to touch.

Ctrl-D is one keystroke away from every row, all the time. The confirm prompt is real, but it's still one accidental keypress plus a reflexive "y" away from a delete — the same speed that makes k9s valuable for reads makes a mistaken write faster too. If you regularly work in k9s against a bastion box other people also use, set readOnly: true in config.yaml or launch with k9s --readonly; it's a client-side guard against your own fat-fingering, not a security boundary — the RBAC gate from earlier on this page is still the only thing that actually stops an unauthorized action, and someone with an unmodified config still deletes exactly what RBAC lets them delete.

Namespace scope hides as much as it shows. k9s opens on one namespace at a time by default, same as kubectl without -A. A cross-namespace problem — a NetworkPolicy blocking traffic between two namespaces, a ResourceQuota fight — can look like nothing's wrong from inside just one of them. Press 0 on the namespace picker (or launch with -A) before concluding a namespace is clean.

A live watch can still go stale. k9s reconnects its watches automatically far more often than a bare kubectl get -w left running would, but a real network partition or an API server restart mid-rolling-upgrade can still leave a view showing a connection-lost banner rather than silently going quiet — kubectl's own page covers the identical underlying watch-reconnection gap; the fix is the same instinct either way: trust a banner or an explicit reconnect over an assumption that "it would say something if it were stale."

Custom hotkeys and plugins can drift from what you remember. Once hotkeys.yaml or plugins.yaml has been edited — by you, six months ago, or by whoever set up the machine you're borrowing — the keybindings on screen are no longer the defaults documented anywhere online. ? from the current view is the one source of truth that can't be stale, because it's printing exactly what's configured on this machine right now.

k9s vs. the alternatives

☺ Like you're 10: Every other option here is a different window onto the same cluster — none of them replace kubectl, and none of them get you past a permission kubectl wouldn't already grant you.

The honest framing is the same one kubectl's own page lands on for Helm and Kustomize: this isn't "kubectl or k9s." k9s has no independent execution path — it is kubectl's own reach, wearing a faster interface, watching the same objects the observability page already told you to instrument, through the same RBAC gate the security page already told you not to trust a UI to bypass.