You can add features to the kubectl Kubernetes command-line tool using plugins. Create kubectl sub-commands to add custom functionality while maintaining a cohesive interaction with Kubernetes. Read on to learn more about kubectl plugins, where to share plugins with the community, and what new useful plugins you may want to add to your own kubectl.
The kubectl command can be extended using kubectl plugins, which are executable files in your path that begin with kubectl- (kubectl followed by a dash). You can use any programming or scripting language, and no libraries or pre-loading are required.
The name of the plugin file determines the kubectl command. Including a dash (-) indicates a space, and an underscore (_) indicates a dash. For example, a kubectl hello world sub-command would be implemented in the kubectl-hello-world file, and a kubectl hello world at-night sub-command would be implemented in the kubectl-hello-world-at_night file.
Kubectl uses the longest available plugin, and passes remaining command-line arguments to the plugin. For example, if you run the command kubectl gke create regional kubectl will first look for an executable file kubectl-gke-create-regional, then kubectl-gke-create, and so on. If the first available plugin is kubectl-gke, the arguments create regional will be passed to the plugin.
You can add a command to an existing plugin by creating a more specific plugin. Using the above kube-gke example, you can add a kubectl gke create zonal command by creating kubectl-gke-create-zonal instead of adding functionality to the kubectl-gke plugin.
You can not use plugins to overwrite, or add sub-commands to, built-in kubectl commands. You can not use a kubectl create catastrophe plugin because create is already a kubectl command.
The first plugin to be found in your path will be used by kubectl. The kubectl plugin list command displays all available plugins, including warnings about duplicate plugins in your path, or plugins that are not executable.
Currently kubectl shell autocompletion does not include plugins in tab-completed suggestions, as mentioned in this feature request.
Two common ways to share kubectl plugins are the kubectl-plugin Github topic, and the Krew kubectl plugin manager.
You can classify a Github repository with topics to help others discover it. The kubectl-plugins Github topic contains 48 repositories, some including multiple kubectl plugins. Each plugin author has their own installation and upgrade process, varying from compiling your own binary, to downloading a single shell script.
Adding your plugins Github repository to this topic is a good idea even if you use Krew (described below) to share your plugin.
Krew is a plugin manager for kubectl plugins that aims to ease plugin discovery, installation, upgrade, and removal on multiple operating systems. You can search available plugins by running kubectl krew search ... or upgrade all Krew-installed plugins by running kubectl krew upgrade.
It currently is not possible to pin a plugin to your preferred version to keep it from being upgraded. You can install an older version of a plugin by getting its manifest file from a previous commit to the krew-index repository, and using the --manifest=FileName.yaml option to the kubectl krew install command.
Krew has been accepted by the Kubernetes SIG-CLI, and the central index may evolve into an index of catalogs similar to the Helm Hub, as mentioned in this proposal to adopt Krew as a SIG CLI subproject.
Install git, then follow the installation instructions on the Krew Github page. Here is an example using Krew to search for an install a kubectl plugin:
I'll use the krew info command to read more about the Resource Capacity plugin, then the krew install command to install it.
That was pretty easy - I didn't have to download, un-tar an archive, or verify any checksums. I happened to install on Linux, but this plugin is also available for Mac OS X. Now I can use the resource-capacity plugin on my relatively empty and boring cluster:
The Krew naming guide has great suggestions for using names that make plugins easier to discover by the krew search command, and avoiding broad or overloaded terms. For example, naming a plugin kubectl-gke-login or kubectl-gke-ui instead of the more general names kubectl-login or kubectl-ui.
The Krew plugin developer guide describes creating a plugin .zip or .tar.gz file for use with Krew, and the plugin.yaml manifest file that includes the information, checksums, and download links to your plugin for the operating systems you support. The final step is to create a krew-index pull request to add your plugin.yaml manifest file to the Krew index - once your pull request is accepted, your plugin will be available to anyone using Krew.
Acceptance of new plugins to the krew-index repo has some challenges as demonstrated in this tiller-init pull request. The aforementioned donation of Krew to the SIG-CLI includes plans to improve the plugin index process.
Time to share your plugins, whether you use a Git repository, Krew, or in a blog post like this. Speaking of sharing. . .
Display pod disruption budgets that allow less than one disruption - these can keep Kubernetes nodes from being drained during maintenance. This plugin requires the jq command.
While a Google Container Engine (GKE) cluster is being upgraded, it can be useful to list nodes with the name of the node pool and version of the Kubernetes Kubelet.
Thank you for reading! If you enjoyed this post, or have suggestions for the above kubectl plugins, please reach out to @IvanFetch on Twitter.
