The "App Store" for kubectl
Kubernetes was designed to be extensible. One of its extensibility mechanisms is the kubectl plugin system: if you place a binary named kubectl-something anywhere in your system's PATH, kubectl automatically recognizes it as a subcommand. Running kubectl something will execute that binary, passing along any additional arguments. This means anyone can write a kubectl extension without modifying kubectl itself.
The problem: how do you discover, install, and update these plugins? That's what Krew solves. Krew is the official plugin manager for kubectl — think of it as apt for Debian, brew for macOS, or npm for Node.js, but specifically for kubectl plugins. It maintains a curated index of plugins, handles downloading the correct binary for your OS and architecture, and manages updates.
Installing Krew itself is a one-time setup: download the release archive matching your OS and architecture, extract it, and run its bundled installer, then add Krew's bin directory to your shell's PATH so kubectl krew and installed plugins are found.
Essential Krew Plugins:
| Plugin | Install Command | What It Does |
|---|---|---|
ctx (kubectx) |
kubectl krew install ctx |
Switch between clusters: kubectl ctx production |
ns (kubens) |
kubectl krew install ns |
Switch default namespace: kubectl ns dev |
who-can |
kubectl krew install who-can |
RBAC audit: kubectl who-can delete pods -n prod |
neat |
kubectl krew install neat |
Clean kubectl get -o yaml output by removing system-generated noise like managedFields |
stern |
kubectl krew install stern |
Tail logs from multiple Pods simultaneously using label selectors |
tree |
kubectl krew install tree |
Show owner-reference hierarchy: kubectl tree deployment api-server |
The neat plugin deserves special mention. When you run kubectl get pod mypod -o yaml, the output includes dozens of lines of system-generated metadata (managedFields, resourceVersion, uid, creationTimestamp, etc.) that are irrelevant when you're trying to understand the Pod's configuration. kubectl neat get pod mypod -o yaml strips all of that out, leaving only the fields you actually care about. This is invaluable when debugging or when you want to extract a clean manifest from a running resource.
Interviewers sometimes ask: "How would you check whether a specific ServiceAccount has permission to list secrets in the prod namespace?" The who-can plugin gives a direct answer: kubectl who-can list secrets -n prod. Without the plugin, you'd need to construct a kubectl auth can-i command with the --as flag and the full ServiceAccount name — which requires knowing the exact syntax. Mentioning who-can in an RBAC debugging scenario signals real operational experience.