In my previous article on kubectl plugins, I explained how kubectl plugins work and how you can develop your own plugins. If “kubectl plugins” are new to you, read that article first.

In this article, I will explain why we have developed a kubectl plugin manager at Google, and how it addresses some of the usability, discoverability and packaging problems around kubectl plugins.

A world without a plugin manager

Here are some of the current problems I higlighted there about the usability of “kubectl plugins” ecosysetem in my earlier article.

As a kubectl user:

  • how do I discover which plugins exist? (Maybe I’ll find some on GitHub or on blog posts etc.)
  • how do I install plugins? Some developers distribute via apt get, some tell me to run go get, some plugins require me to to unzip their plugin to /usr/local/bin. Which one is the preferred way?
  • how do I keep plugins I installed up-to-date?
  • how do I cleanly uninstall a plugin that I am no longer using?

As a kubectl plugin developer:

  • how do I package my plugin for many Linux distros, macOS and Windows?
  • how can kubectl users discover my plugin?
  • how do I release updates on my plugin?

We’ve been working a plugin manager named Krew, aiming to take a stab at these problems.

Krew: the plugin manager for kubectl

Meet Krew, an open source “kubectl plugin manager” for discovering, installing and packaging kubectl plugins. Krew, helps you find and install plugins to your machine through simple commands like:

  • kubectl krew search → find plugins
  • kubectl krew install foo → install a plugin.
  • kubectl krew upgrade → keep ’em plugins up-to-date
  • kubectl krew uninstall foo → remove plugin from your machine

In a nutshell: Krew has a centralized plugin index which contains manifests of each plugin. These manifests describe the tar/zip archive URL of the plugin package for each supported platform/OS. Krew downloads this archive, places the plugin files on user’s machine and creates a symlink.

Krew is available to use today. You can find it on GitHub.

My summer intern at Google (Luk Burchard) and I have been working on this idea of a plugin manager for the “kubectl plugins” concept since the summer of 2017. Today, over 20 kubectl plugins are distributed on krew. (This number is actually the majority of open source plugins today.) By starting on this project before the plugin ecosystem took off, we are making the “kubectl plugins” feature easier for users and plugin developers.

Krew: for users

For a kubectl user, Krew makes it easy to discover and manage the lifecycle of plugins.

Krew provides a high level interface for all these installation, upgrade, and removal operations. You can just find plugins, install them and start using them with Krew, without worrying about how they’re installed under the covers.

Krew: for developers

Since kubectl plugins are simple as placing a kubectl-foo executable in $PATH, do developers actually need something like Krew? Maybe not, but so far the plugin developers have found it to be a super easy way to distribute plugins cleanly, and let users upgrade when there’s a newer version.

Normally, on Linux alone, you need to package your software as at least deb, rpm and snap packages to have a decent coverage of the user base. Not to mention, macOS and Windows have completely different package managers.

Krew provides an easy way to install plugins on multiple platforms through a fairly simple manifest file. Take a look at an example Krew plugin manifest.

Krew takes a minimalistic approach here. It assumes most plugins are self-contained (can be distributed as a zip/tarball archive) and doesn’t have runtime/library dependencies (to python, or to libncurses).

Therefore, Krew has a simple installation procedure: It downloads a tarball/zip file, extracts it to an installation directory, and symlinks the plugin executable to a directory in $PATH.

Given you’re writing your plugins in Go or bash, this works just fine. Using this simplification, Krew avoids being a full-fledged package manager. Read the Krew developer guide to learn more.

And for discoverability, Krew has a centralized plugin index repository where developers can submit their plugins for discovery.

Frequently asked questions

  • Why should I develop tools as “kubectl plugins” instead of standalone executables? Read my previous article about kubectl plugins.
  • What’s wrong with distributing plugins with apt/brew? Nothing, if you think it covers your user base, and you think you can maintain an apt/yum/brew repo yourself.
  • Did you just write another package manager? Not really. Krew is a glorified curl+untar+mv+symlink. Krew avoids many difficult aspects of package management and aims to be a simple tool that can work for the majority of plugin ecosystem (which uses Go and bash). For example, some of the shortcuts krew takes:
    • No dependency management: plugins are self-contained and can’t have dependencies. If you need any more tools/libraries for your plugin to work, krew can show a message like “also install x, y, z” after the installation.
    • No version pinning: krew always installs last version of any plugin
  • Don’t you need a package manager to install krew? Krew itself is a kubectl plugin on Krew (Krewception). Once you manually install Krew, Krew will update Krew itself (along with other plugins you installed) with krew uprade command.

Try out Krew today

Krew is open source and already hosts over 20 plugins! Despite its infancy (v0.2), it’s been working fine for a lot of people. Find installation instructions at github.com/GoogleContainerTools/krew and please report issues that you encounter. We need your feedback to mature this!

If you’re a developer interested in creating and distributing kubectl plugins, visit the developer guide, and come to the Kubernetes SIG CLI meetings to discuss about krew and plugins! I am also available on Twitter to discuss anything about the “kubectl plugins” system.

(Thanks to Megan O’Keefe for reading drafts of this article.)