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.
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 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, 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
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.
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.
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-ui instead of the more general names
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. . .
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.