K9s

Last reviewed Aug 26, 2026 · 757 words

K9s cut the number of times I type kubectl get pods -n something -o wide | grep to zero. It is a terminal UI over your existing kubeconfig that shows pods, deployments, logs and events live, and lets you shell into a container or delete a stuck pod with one keystroke. If you run k3s or Talos at home, install it today: it is a single Go binary, needs nothing on the cluster, and idles at a few tens of MB on the laptop, not the nodes.

Install and the first 60 seconds

brew install k9s on macOS or Linux, or download the release tarball and put k9s on your PATH. Run k9s and it opens the current kubeconfig context in the default namespace, showing pods. Type :ns and pick a namespace, :deploy to see deployments, :svc for services, :ctx to switch clusters. Any resource kind you can name works after the colon, including custom resources. Type / and a string to filter the current view; type ? when lost. That is the entire onboarding, which is why the catalogue rates it Easy despite the "shortcut learning curve" con: the curve is real but it is a day long.

13 keystrokes carry 90% of the work

Logs deserve a note: l then 0 shows the last lines, 1 through 5 change the tail window, s toggles autoscroll, and w wraps. For a home cluster where the question is usually "why is this pod restarting", l on the pod followed by p for previous-container logs answers it faster than any dashboard.

Read-only for the cluster you care about

k9s --readonly disables every mutating action for that session, and readOnly: true under k9s: in ~/.config/k9s/config.yaml makes it the default. I run it that way against anything holding data I would miss, and drop the flag on purpose when I mean to change something. It is a cheap guard against ctrl-d on the wrong row at 23:00. Per-cluster settings, including skins so production is visibly a different colour, live in the same directory.

Plugins fill the gaps

Anything you find yourself doing by dropping to kubectl can become a keystroke. Plugins are a YAML map in ~/.config/k9s/plugins.yaml; the one I use most restarts a deployment:

plugins:
  restart:
    shortCut: Shift-R
    description: Rollout restart
    scopes:
      - deploy
    command: kubectl
    args:
      - rollout
      - restart
      - deploy/$NAME
      - -n
      - $NAMESPACE
      - --context
      - $CONTEXT

The $NAME, $NAMESPACE and $CONTEXT variables come from the selected row. Other popular ones open a debug shell on a node, decode a secret, or run a Helm rollback. The community plugin repository has a few dozen ready to paste.

K9s beside Headlamp, Lens and Portainer

They are not really rivals. K9s is for the person who is already in a terminal and wants speed; it has no mouse, no charts, no web login, and cannot be handed to a colleague who does not know Kubernetes. Headlamp is the self-hosted web dashboard that colleague can use, with OIDC login and a plugin system. Lens is a desktop app with resource graphs and a commercial licence for business use, which is why people who left it landed on K9s or Headlamp. Portainer covers Docker hosts and Kubernetes from one web UI and suits a lab that is mostly compose with one small cluster. GitOps tools such as Argo CD are a layer above all of these: they decide what should be running, and K9s is how you look at what actually is. Most people who run Kubernetes at home end up with K9s for operating and one web UI for showing.

What I'd do

Install K9s on every machine you administer from, set readOnly: true globally, and create a second context alias without it for planned changes. Add the rollout-restart plugin. Learn :ns, /, l, s, d and ctrl-d in the first week and stop there; the rest arrives on its own. Pair it with Headlamp if anyone else needs to see the cluster.