You’re bouncing between a dev cluster and a prod cluster, your app lives in a namespace with a very long name, and you’ve typed kubectl get pods -n my-very-long-namespace-name for the tenth time today. If you’ve spent more than five minutes with Kubernetes, you know this is a pain in the A$$.

When I first started, I thought the hard way was the only way. I kept getting lost between clusters, and more than once I deployed containers to the wrong namespace or cluster because I forgot which “context” I was in.

In this post I’ll show you the four Kubernetes CLI tools that changed my daily workflow: kubectx, kubens, K9s and Stern, plus how to install them.

Switch clusters with kubectx

kubectx lets you switch between Kubernetes clusters with one short command. A context is a saved combination of a cluster, a user and a namespace in your kubeconfig file, so switching context is how you choose which cluster kubectl talks to.

Without kubectx, you first look up the exact context name and then switch to it:

kubectl config get-contexts
kubectl config use-context prod-cluster

With kubectx, you just type:

kubectx prod-cluster

To jump back to the context you were using before, run:

kubectx -

Run kubectx with no arguments to list every context and see which one is active. It’s fast, it’s simple, and it prevents heart attacks.

Set your default namespace with kubens

kubens locks in a namespace so you stop adding -n to every command. By default, kubectl looks at the default namespace, so if your app is in marketing-apps, you have to add -n marketing-apps every single time.

The plain kubectl way to change the namespace of your current context is a mouthful:

kubectl config set-context --current --namespace=marketing-apps

With kubens, it’s this:

kubens marketing-apps

From now on, every command you run applies to marketing-apps until you switch again. Like kubectx, kubens - takes you back to the previous namespace. I use this one constantly.

Watch your cluster in real time with K9s

K9s is a terminal-based UI for Kubernetes that shows what’s happening in your cluster live. While kubectx and kubens help with navigation, K9s helps with observation: you can view logs, scale deployments and kill buggy pods with simple keystrokes.

To open it against your current context, run:

k9s

It feels like a retro video game for DevOps, but it’s incredibly powerful for seeing exactly what’s going on without typing get pods every three seconds. If you prefer a desktop app over a terminal UI, take a look at managing Kubernetes clusters with Jet Pilot.

Tail logs from multiple pods with Stern

Stern lets you tail (watch live) logs from many pods at once. Standard kubectl logs is built around one pod at a time, so if five pods run the same microservice, debugging turns into a nightmare.

To follow the logs of every pod whose name matches my-service in a given namespace, run:

stern my-service -n marketing-apps

Stern color-codes the output by pod, so you can tell right away which one is throwing the error. Press Ctrl+C to stop.

Install these Kubernetes CLI tools

The quickest way to install all of them on macOS or Linux is Homebrew. The kubectx package installs both kubectx and kubens:

brew install kubectx k9s stern

Check that everything landed by running kubectx, kubens, k9s version and stern --version. If you don’t use Homebrew, each project’s GitHub page lists other install options, such as your distro’s package manager or prebuilt binaries.

Add fzf for interactive menus

If you use kubectx and kubens, I’d strongly suggest installing fzf too. When fzf is present, running kubectx or kubens with no arguments opens an interactive search menu, so you can scroll or fuzzy-search through your clusters and namespaces instead of typing them out.

brew install fzf

I wrote a whole guide on setting up fzf in your Zsh terminal if you want to go further with it.

Kubernetes is complex, but your daily workflow doesn’t have to be. Give these tools a try, your fingers will thank you! 🚀