Kyle GalbraithA large part of my day to day work centers around Kubernetes. Or as it's often referred to, K8s. I blog about my experiences with AWS, serverless, and various architecture or programming concepts.
I don't often write about my experiences with Kubernetes. To be honest, K8s is a complex system of systems and the underlying infrastructure is no walk in the park. So it has taken some time to understand and thus, write about.
But in the spirit of learning in public and sharing my own experiences, it's time to share a bit.
In this post, I won't be running through the basics of K8s. I won't be laying out how I provision or maintain clusters within AWS. I also won't be diving into complex things you can run within a cluster.
Those are all great future blog posts. If those are ideas that inspire you to write your own posts, do it!
Instead, I'm going to start with a topic that is critical when it comes to working with any new technology, tooling. Without good tools in the eco-system surrounding a given technology, the worse it is to use.
So in this post, I am going to share the three tools I use when working with Kubernetes clusters. Major kudos to my coworkers that have often pointed me towards these tools. Disclaimer: these are my opinions on tools that work for me, your situation will be different.
1. kubectx for managing many K8s clusters
When interacting with K8s clusters, you do so by using their kubeconfig file. kubectl uses the information inside of your kubeconfig file to connect to the API server running within your cluster.
When only interacting with one cluster, your kubeconfig is going to be straightforward. It only has one cluster inside of it. Thus kubectl commands like kubectl get ns will get all the namespaces inside of the one cluster.
But things get a more painful when you have more than one cluster. In that scenario, you have many clusters and contexts defined inside of your one kubeconfig file.
Say you have two clusters with their respective contexts in your kubeconfig, foo and bar. Now to list the namespaces in foo you would run the following commands:
kubectl config use-context foo
kubectl get ns
Then when you want to switch to the bar cluster you have to run the use-context command again.
This is where kubectx comes in.
With kubectx you can change to a different cluster context with relative ease.
kubectx foo
Furthermore, you can move through contexts in other ways. For example, I can move back to the previous context I was in by running kubectx -. Need to list the different contexts? Use kubectx to list all the cluster contexts in your kubeconfig.
2. kubens for managing namespaces within a cluster
Packaged with kubectx is another tool, kubens.
kubectx is for switching into and interacting with different Kubernetes contexts/clusters. Whereas kubens is the same idea but focused on the namespaces within a single cluster.
This is a very handy tool to use when having to use a lot of kubectl commands and you get tired of including -n <namespace>.
You can run kubens <namespace> to switch into a given namespace. Once you have selected your namespace you can run all your kubectl commands without having to specify -n with them.
# list the namespaces in the cluster
kubens
# switch into a specific namespace
kubens my-namespace
# run your usual kubectl commands within the selected namespace
kubectl get deployments
kubectl get ingress
3. k9s for command center management of a cluster
Do you prefer a more centralized tool to interact with clusters, namespaces, and resources? I do. kubectx and kubens are great but they are often used to make using kubectl more streamlined.
k9s is a streamlined CLI for managing K8s clusters.
It's actually an entire terminal dedicated to managing your Kubernetes clusters. You don't need kubectx as it allows you to choose which cluster you want to manage. You don't need kubens as you can select the namespace you want to operate in. It simplifies the amount of tooling you need to manage your clusters.
k9s has loads of keyboard shortcuts. The main one to know is :<type-the-resource-name> to switch to the different K8s resource you want to view. For example, if I wanted to see the pods in a cluster I would type :pods followed by hitting your enter key. Now I can view all the pods in a given namespace or across the entire cluster.
You can also filter the resources by typing /yourthing followed by the enter key again.
Anything you can do with kubectl you can often do a lot quicker in k9s. Tailing the logs of a pod has a keyboard shortcut. Shelling into a running container has one to. Killing resources, editing them on the fly, etc, all available in k9s.
Conclusion
Kubernetes is a complex system. It has dozens and dozens of resources that you often want to interact with at some point. This is in addition to actually deploying your applications and services within it.
Without solid tooling, it can be difficult to manage. Things like kubens ease our pain a bit by allowing us to isolate our kubectl calls to a single namespace. kubectx allows us to lock ourselves to a single K8s cluster. k9s harnesses the power of kubectl, kubens, and kubectx into one command terminal.
Are these all the tools? Not even close. These are the ones I use on a daily basis. But this is a growing space and more tools are going to come along. If you have any tools you come across, feel free to drop them in the comments below.
Want to check out my other projects?
I am a huge fan of the DEV community. If you have any questions or want to chat about different ideas relating to refactoring, reach out on Twitter or drop a comment below.
Outside of blogging, I created a Learn AWS By Using It course. In the course, we focus on learning Amazon Web Services by actually using it to host, secure, and deliver static websites. It's a simple problem, with many solutions, but it's perfect for ramping up your understanding of AWS. I recently added two new bonus chapters to the course that focus on Infrastructure as Code and Continuous Deployment.
