Kubernetes has quickly grown to be a powerhouse in the modern technology space. By enabling companies to standardize their infrastructure deployment and fostering automation with new work, DevOps teams can be quickly overwhelmed by the dizzying array of tools and features.

As a consultant, I work with a lot of clusters that all have varying authentication mechanisms and RBAC. For me, being able to rapidly understand where I am and what I can do help me immensely when working across clusters. In today’s post, I’m going to be listing some of my favorite tools that make my day-to-day easier.

1. Understanding your Kubeconfig

Funny enough the first item on this list is not actually a tool, but more of a chore. Depending on your level of expierience with Kubernetes your kubeconfig is either extrememy tidy or a disaster. Taking some time to cleanup and, more importantly, rename some of your contexts will help you immensely with the other tools. I would also recommend stopping the use of tools built into major cloud providers to get your kubeconfig, but instead use the output to integrate into a managed file.

If you’re not sure where your kubeconfig is, it typicially lives (on Linux and macOS) at ~/.kube/config, where there are three major sections.

• clusters - The actual endpoint of a kubernetes API server (or similar proxy) and, if needed, the public certificate it presents.
• users - available users you can use to connect to the kubernetes API, this is where the secrets of your kubeconfig live.
• contexts - A mapping of a cluster and user together. This allows you to use one user to talk to multiple clusters, or use multiple users with one cluster.

Contexts don’t have any strict naming requirements, so taking the time to rename them can greatly help, especially with my next tool.

2. Kubectx and Kubens

kubectx (https://github.com/ahmetb/kubectx) and kubens are invaluable tools as you start working with multiple clusters. Both tools come from the kubectx project.

Kubectx allows you to quicky see available contexts and switch to them by running kubectx and kubectx myContextName, this is much faster than typing kubectl config get-contexts and then kubectl config use-context myContextName. You can also further shorten typing by creating an alias for ktx.

Kubens allows you to set a namespace as your context namespace. This gets saved into your kubeconfig so there are no other files you need to track. This works the exact same as kubectx and you can also create an alaias for this at kns.

As a quick 1.5 tip, you can also create an alias for kubectl! If you alias to k you can do things like k get po and k port-forard svc/my-service 8080:8080.

3. zsh and zsh-kubectl-prompt

zsh is an alternative shell you can use on macOS and Linux systems. Without getting into too many details about the pros and cons of switching your shell, I’ve found a nice configuration of zsh with zsh-kubectl-prompt (https://github.com/superbrothers/zsh-kubectl-prompt) to give me a ton more information when working in the shell.

The zsh prompt plugin allows you to see your currently configured context and namespace. Combining this with kubectx and kubens allows you to rapidly move between environments and if you renamed your clusters on step 1, you can begin to develop a memory of all of your different clusters.

4. Lens/Octant/Kubernetes GUI tools

Don’t let anyone tell you how to do your work. If you have a preference for GUI style tools and don’t move as quickly in the shell, you should use a simple desktop GUI to help understand a cluster. Tools like Lens (https://github.com/lensapp/lens) and Octant (https://github.com/vmware-tanzu/octant) make it easy to rapidly browse and discover information about a cluster.

I personally use Lens because it integrates nicely with our produciton monitoring (prometheus operator) and allows me to use that data within the application. Also, native support for one-click port-forwarding is very nice to have. Lens also has great support for contexts that is going to be similar for anyone that uses multiple Slack workspaces.

Conclusion

These are just some of the tools I’ve found that really help me with managing clusters during my day to day, the better part is that all of these tools are client side only and don’t require any modification to the cluster to work. Taking some time to get your configs under control can really help you speed up your experience using kubernetes and making it less frustrating.