Extend kubectl with plugins [page]deterministic

This guide demonstrates how to install and write extensions for [kubectl](/docs/reference/kubectl/kubectl/). By thinking of core `kubectl` commands as essential building blocks for interacting with a Kubernetes cluster, a cluster administrator can think of plugins as a means of utilizing these building blocks to create more complex behavior. Plugins extend `kubectl` with new sub-commands, allowing for new and custom features not included in the main distribution of `kubectl`.

##

You need to have a working `kubectl` binary installed.

## Installing kubectl plugins

A plugin is a standalone executable file, whose name begins with `kubectl-`. To install a plugin, move its executable file to anywhere on your `PATH`.

You can also discover and install kubectl plugins available in the open source using [Krew](https://krew.dev/). Krew is a plugin manager maintained by the Kubernetes SIG CLI community.

> Caution: Kubectl plugins available via the Krew [plugin index](https://krew.sigs.k8s.io/plugins/) are not audited for security. You should install and run third-party plugins at your own risk, since they are arbitrary programs running on your machine.

### Discovering plugins

`kubectl` provides a command `kubectl plugin list` that searches your `PATH` for valid plugin executables. Executing this command causes a traversal of all files in your `PATH`. Any files that are executable, and begin with `kubectl-` will show up *in the order in which they are present in your `PATH`* in this command's output. A warning will be included for any files beginning with `kubectl-` that are *not* executable. A warning will also be included for any valid plugin files that overlap each other's name.

You can use [Krew](https://krew.dev/) to discover and install `kubectl` plugins from a community-curated [plugin index](https://krew.sigs.k8s.io/plugins/).

#### Create plugins

`kubectl` allows plugins to add custom create commands of the shape `kubectl create something` by providing a `kubectl-create-something` binary in the `PATH`.

#### Limitations

It is currently not possible to create plugins that overwrite existing `kubectl` commands or extend commands other than `create`. For example, creating a plugin `kubectl-version` will cause that plugin to never be executed, as the existing `kubectl version` command will always take precedence over it. Due to this limitation, it is also *not* possible to use plugins to add new subcommands to existing `kubectl` commands. For example, adding a subcommand `kubectl attach vm` by naming your plugin `kubectl-attach-vm` will cause that plugin to be ignored.

`kubectl plugin list` shows warnings for any valid plugins that attempt to do this.

## Writing kubectl plugins

You can write a plugin in any programming language or script that allows you to write command-line commands.

There is no plugin installation or pre-loading required. Plugin executables receive the inherited environment from the `kubectl` binary. A plugin determines which command path it wishes to implement based on its name. For example, a plugin named `kubectl-foo` provides a command `kubectl foo`. You must install the plugin executable somewhere in your `PATH`.

### Example plugin

```bash #!/bin/bash

# optional argument handling if [[ "$1" == "version" ]] then echo "1.0.0" exit 0 fi

# optional argument handling if [[ "$1" == "config" ]] then echo "$KUBECONFIG" exit 0 fi

echo "I am a plugin named kubectl-foo" ```

### Using a plugin

To use a plugin, make the plugin executable:

```shell sudo chmod +x ./kubectl-foo ```

and place it anywhere in your `PATH`:

```shell sudo mv ./kubectl-foo /usr/local/bin ```

You may now invoke your plugin as a `kubectl` command:

```shell kubectl foo ```

``` I am a plugin named kubectl-foo ```

All args and flags are passed as-is to the executable:

```shell kubectl foo version ```

``` 1.0.0 ```

All environment variables are also passed as-is to the executable:

```bash export K …(trimmed)