A 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.
When interacting with K8s clusters, you do so by using their
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
Say you have two clusters with their respective contexts in your
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.
kubectx you can change to a different cluster context with relative ease.
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
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
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
Do you prefer a more centralized tool to interact with clusters, namespaces, and resources? I do.
kubens are great but they are often used to make using
kubectl more streamlined.
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
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
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.
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.