kubectx

Last reviewed Aug 26, 2026 · 676 words

kubectx prod instead of kubectl config use-context prod-cluster-eu-west-1, and kubens monitoring instead of appending -n monitoring to every command for the next hour. That is the whole product, and it earns its 19,960 stars because the alternative is muscle memory that eventually types kubectl delete into the wrong cluster. If you run a home k3s cluster and touch a work cluster from the same laptop, install it today; it takes about 30 seconds and uses 32 MB of RAM, which is to say none.

One install command on every platform

Pick the line for your machine:

brew install kubectx                    # macOS and Linuxbrew
sudo apt install kubectx                # Debian and Ubuntu
sudo pacman -S kubectx                  # Arch
kubectl krew install ctx ns             # as kubectl plugins: kubectl ctx, kubectl ns

Or drop the release binaries from GitHub into your PATH. The tools were rewritten from shell scripts into Go some years ago, so the binaries are static and identical in behaviour on Linux, macOS and Windows. Shell completion for bash, zsh and fish ships in the repository's completion/ directory, and the brew and apt packages wire it up for you.

The 8 commands you will actually use

kubectx                  # list contexts, current one highlighted
kubectx homelab          # switch to it
kubectx -                # back to the previous one
kubectx -c               # print the current context (for scripts and prompts)
kubectx lab=homelab-k3s  # rename a context
kubectx -d old-cluster   # delete a context
kubens                   # list namespaces in the current cluster
kubens -                 # back to the previous namespace

kubectx - is the one that changes how you work. Bouncing between a staging and a production context becomes a reflex, the same as cd -, and kubens - does the same for the namespace you were just in.

fzf turns both into a picker

Install fzf and run kubectx or kubens with no arguments: you get an interactive fuzzy finder instead of a list, which matters once a kubeconfig accumulates 15 contexts whose names differ by one region. This is the "interactive mode needs fzf" caveat in the catalogue, and it is a soft dependency. Without fzf you get the plain list, and KUBECTX_IGNORE_FZF=1 restores the plain list if you have fzf installed but want scripting-friendly output.

It edits your kubeconfig, so every terminal follows

Both tools work by rewriting current-context (and the context's namespace field) in ~/.kube/config or whatever KUBECONFIG points at. That is global state. Switch to prod in one tab and the other tab you forgot about is now on prod too. Two habits cover it. First, put the current context and namespace in your shell prompt; kube-ps1 is the usual choice, and kubectx -c gives you the raw value if you roll your own. Second, never rely on the current context in anything automated. Scripts, cron jobs and pipelines should pass --context and --namespace explicitly, and the runners in your CI/CD setup should get their own kubeconfig with exactly one context in it, so there is nothing to switch.

Narrow by design, and that is fine

The tools do nothing else. No cluster dashboard, no resource browsing, no merging of kubeconfigs (that is KUBECONFIG=a:b kubectl config view --flatten). For browsing the cluster the usual companion is k9s, a terminal UI that reads the same kubeconfig and respects whatever kubectx last selected. Together they are the standard pair in most of the dev-tools stacks I have seen, and the fact that neither tries to be the other is why both are still around nearly a decade on. The Apache-2.0 licence and the 32 MB footprint mean there is no cost to putting them on every machine you own, including the jump host.

What I'd do

Install via brew or krew, install fzf alongside, rename contexts to short memorable names (lab, work), put kube-ps1 in the prompt, and give every script and runner an explicit --context. Then forget the tool exists, which is the highest compliment a CLI utility gets.