Posted on 21 October 2020, updated on 6 August 2021.
As an SRE, part of the job includes operating Kubernetes clusters. My tool of choice is often kubectl, the official Kubernetes command-line interface. I am always on the lookout for ways to be more productive, so a few weeks ago I started using kubectl plugins. If you are thinking about doing the same, this article covers what you need to know to get started.
What is a kubectl plugin?
The Kubernetes CLI special interest group added a built-in plugin system to kubectl that allows anyone to add new sub-commands. This does not require editing kubectl’s source code or recompiling it.
Any executable file in your PATH that starts with kubectl- can be called with the kubectl command. To try this out, let’s write a very basic plugin called kubectl-hello.
Make this script executable and add it to your PATH:
That’s it! You can now use this plugin with kubectl:
Installing plugins manually and keeping track of them can be tedious. Thankfully, kubectl has a plugin manager.
How to install plugins with krew?
The community-driven plugin manager for kubectl is called krew.
On OS X, install krew by running brew install krew. For other platforms, follow these instructions to set it up on your computer.
This will install the kubectl-krew binary. Notice that krew is itself a kubectl plugin.
The open-source community keeps a list of plugins you can install in the official krew-index repository. Use krew to download the index:
You can view the list of available plugins with the search sub-command:
Installing a plugin is easy with the install sub-command. To try it out, install the whoami plugin:
If you installed a plugin a while ago, you may want to upgrade to a newer version, which could include new features or bug-fixes. Use the upgrade sub-command to upgrade one or all installed plugins:
My favorite plugins
Here are some of the plugins I use the most.
This simple plugin prints out the user you are currently authenticated as.
This plugin displays a human-readable table of the operations you are authorized to perform on your Kubernetes cluster. This is particularly useful when you are not the cluster administrator and want to know what you are permitted to do.
When viewing Kubernetes resources with kubectl get -o yaml, you will see many fields set by Kubernetes’ various controllers. The kubectl neat plugin removes those fields and outputs clean YAML for cluster operators.
Kubernetes has a built-in garbage collection mechanism where resources own other resources. The kubectl tree plugin allows you to view all of a resource’s children in recursive tree representation.
As you may know, when you create a Deployment in the Kubernetes API, a controller creates a corresponding ReplicaSet. Another controller then creates the required Pods. This plugin provides a great visualisation of this kind of resource ownership.
I find that this is a particularly useful way to visualize the rolling update performed by Deployment resources.
When you change the PodSpec template in a Deployment, a controller creates a new ReplicaSet with the new template. The controller gradually scales up the new ReplicaSet and scales down the old one. Eventually, the Pods owned by the new ReplicaSet have completely replaced those owned by the previous one.
As a Kubernetes cluster administrator, you sometimes need to open a shell on one of the cluster’s nodes to debug a low-level problem. The kubectl node-shell plugin provides an alternative to using SSH, by creating a privileged pod on the node of your choice to start a shell in no time.
This plugin will only work if you have the necessary permissions to create privileged Pods in your cluster. For security reasons, this is usually reserved for cluster administrators.
After a few weeks of using kubectl plugins, I highly recommend it. The open-source community has already developed many useful plugins. Writing your own plugin is extremely easy, so I expect the community to build new kubectl plugins at an increasingly greater pace.