The Ultimate Guide to `kubectl plugins list`

Most teams accumulate ad hoc kubectl aliases and shell scripts to paper over missing functionality. While effective in isolation, these solutions are fragile, difficult to version, and nearly impossible to standardize across a team. Kubernetes provides a first-class alternative: kubectl plugins.

Kubectl plugins are standalone executables that extend the CLI with new subcommands. They encapsulate common operational workflows behind consistent, discoverable interfaces, replacing one-off scripts with reusable tooling. Many popular tools install themselves as plugins automatically, so you may already be using them indirectly.

Before adding or standardizing plugins, start by auditing your local setup. Running kubectl plugins list shows every plugin discoverable in your PATH, giving you a clear baseline of existing capabilities and making it easier to reason about what your environment—and your team—actually relies on.

Key takeaways:

• Automate workflows with custom commands: Use kubectl plugins to add new subcommands that encapsulate complex operations, turning multi-step processes like debugging or context switching into a single, repeatable command.
• Use Krew for lifecycle management: Treat Krew as the standard package manager for kubectl. It simplifies plugin discovery, installation, and versioning, preventing inconsistencies in your local development environment.
• Scale plugin management across your fleet: While plugins solve individual productivity, managing them across teams creates operational overhead. Use a platform like Plural to enforce a standard set of tools and security policies, ensuring consistency and governance across all clusters.

What is a kubectl plugin?

Kubectl plugins are standalone executables that extend the kubectl CLI with additional subcommands. Conceptually, they are first-class extensions to kubectl that let you encode common operational workflows as reusable commands instead of brittle shell pipelines.

If you have ever chained together long kubectl | jq | awk commands to extract or transform data, there is a good chance a plugin already exists to solve that problem in a cleaner, more maintainable way.

Plugins integrate transparently with kubectl. An executable named kubectl-foo automatically becomes available as kubectl foo. This extensibility is a deliberate design choice in Kubernetes, enabling operators and developers to build and share tools that address recurring pain points. As a result, there is a mature ecosystem of plugins for tasks such as context switching, resource inspection, debugging, and security analysis. Using these tools reduces cognitive overhead and makes day-to-day cluster interaction more efficient.

How plugins work

Kubectl discovers plugins using a simple convention-based mechanism. For a tool to be treated as a plugin, it must satisfy three conditions:

• It must be an executable file.
• Its filename must start with the kubectl- prefix.
• It must be located in a directory listed in your PATH.

When you run a command like kubectl my-plugin, kubectl searches your PATH for an executable named kubectl-my-plugin. If it finds one, it executes it and forwards any additional arguments unchanged. There is no special SDK or runtime involved, which makes plugins easy to write in any language.

Although you can manage plugin binaries manually, most teams rely on Krew. Krew acts as a package manager for kubectl plugins, handling discovery, installation, upgrades, and removal in a consistent way, similar to tools like apt or brew.

Why you should use them

The core value of kubectl plugins is leverage. They allow you to collapse complex, error-prone workflows into simple, memorable commands that are purpose-built for a specific task. This improves both speed and reliability, especially in production environments where mistakes are costly.

Plugins also reduce knowledge silos. Instead of every engineer maintaining their own set of aliases and scripts, teams can standardize on a shared set of plugins. This creates more consistent workflows across developers, SREs, and platform teams, and makes onboarding significantly easier.

Finally, the Kubernetes ecosystem continues to evolve rapidly. The active plugin community means you can adopt solutions to common operational challenges without reinventing them yourself, keeping your tooling aligned with best practices as they emerge.

List Your Installed Plugins

Before you can standardize or rationalize your kubectl extensions, you need a precise inventory of what is already installed. This discovery step is foundational for aligning tooling across environments, debugging unexpected behavior, and ensuring consistency as your team and cluster footprint scale.

Run the kubectl plugin list command

Kubectl includes a built-in command for enumerating all discoverable plugins:

kubectl plugin list

This command scans your environment and outputs every plugin kubectl can find, along with the full filesystem path to each executable. The path information is particularly useful when debugging PATH issues or validating where a plugin was installed.

If you only need the plugin names—for example, in a script or a quick sanity check—you can use the more concise output:

kubectl plugin list --name-only

This is the authoritative mechanism for plugin discovery in kubectl, as defined by the Kubernetes CLI behavior.

Understand the output

The output of kubectl plugin list is not arbitrary. Kubectl applies strict validation rules before treating a file as a plugin. A plugin will only appear in the list if all of the following conditions are met:

• The file is executable.
• The file is located in a directory included in your $PATH.
• The filename begins with the kubectl- prefix.

These constraints are intentional. The kubectl- prefix avoids naming collisions with unrelated binaries, while the executable and PATH requirements ensure kubectl can reliably locate and invoke the plugin. If a plugin is missing from the list, verifying these three conditions should be your first troubleshooting step.

Anatomy of a Valid Plugin

For kubectl to recognize and execute a plugin, the file must conform to a small but strict set of rules covering naming, location, and permissions. When these requirements are satisfied, the plugin is automatically discovered and exposed as a kubectl subcommand. If any requirement is missed, the file is effectively invisible to kubectl, regardless of how useful or well-written it is.

Understanding these mechanics is essential when managing a local toolchain and becomes even more important at scale. In environments with many engineers and clusters, consistency in tooling directly impacts operational efficiency and security. Getting the fundamentals right locally is a prerequisite for standardizing plugins across a team.

Naming conventions and executables

Every plugin must be an executable file whose name begins with the kubectl- prefix. For example, a script named kubectl-pod-summary is invoked as:

kubectl pod-summary

When you run this command, kubectl looks for an executable with the corresponding prefixed name and transfers execution to it, passing through any arguments. This naming convention is the core discovery mechanism for plugins.

The executable itself can be implemented in any language your system can run. Common choices include shell scripts, Go binaries, or Python scripts with the appropriate shebang. From kubectl’s perspective, there is no distinction—all plugins are treated as external executables.

PATH configuration and permissions

Correct naming alone is not sufficient. For a plugin to be discoverable, it must also be located in a directory listed in your system’s PATH environment variable and have execute permissions set.

If the file is not executable or resides outside of PATH, kubectl will fail to locate it and report a “plugin not found” error. This is a common source of confusion when plugins appear to be installed correctly but cannot be executed. Ensuring consistent PATH configuration across developer machines is therefore a key part of plugin standardization.

Compatibility and lifecycle management

While kubectl does not perform version or compatibility checks on plugins, the broader ecosystem relies on community conventions to maintain reliability. This is where a plugin manager such as Krew becomes important.

Krew maintains a curated index of plugins that are actively maintained and tested against supported versions of kubectl. It handles installation, upgrades, and removal, and ensures plugins are placed correctly in your PATH. For teams working with Kubernetes at scale, using Krew is the recommended approach to avoid version drift, broken plugins, and inconsistent local setups.

Manage Plugins with Krew

Manually managing kubectl plugins by dropping binaries into your PATH does not scale. It quickly becomes difficult to track versions, discover new tools, or ensure consistent setups across machines. This is why most teams rely on Krew, the de facto plugin manager for kubectl.

Krew handles the full plugin lifecycle: discovery, installation, upgrades, and removal. Conceptually, it fills the same role for kubectl plugins that apt or brew do for system packages. It exposes a curated, community-maintained index of plugins, making it easier to adopt tools that are actively maintained and widely used.

For platform teams, Krew is a practical mechanism for standardization. By defining a recommended set of Krew-managed plugins, you can ensure developers and operators are working with the same tooling everywhere. In the same way Plural provides a consistent workflow for managing Kubernetes clusters at scale, Krew brings consistency and control to the kubectl command line itself.

Install the Krew plugin manager

Before managing plugins, you must install Krew. Installation is OS-specific but intentionally simple. The official installation guide provides one-line commands for macOS, Linux, and Windows using common tools such as bash or PowerShell.

After installation, verify that Krew is available by running:

kubectl krew

If the command returns the Krew help output, the plugin manager is correctly installed and integrated with your kubectl setup. From this point on, all plugin management is done through kubectl krew subcommands.

Find, install, and update plugins

Krew makes plugin discovery straightforward. You can search the central index with:

kubectl krew search <keyword>

Once you identify a plugin you want, install it with:

kubectl krew install <plugin-name>

Krew automatically downloads the correct binary for your operating system and architecture and places it in a location that kubectl can discover. No manual PATH management or permission changes are required.

Keeping plugins up to date is equally simple. Running:

kubectl krew upgrade

checks all installed plugins against the index and upgrades any that have newer versions available. This replaces the error-prone process of tracking individual repositories and release notes. The full catalog of available plugins is maintained by Krew and continues to grow with the Kubernetes ecosystem.

Uninstall plugins you no longer need

Effective tooling also means removing what you no longer use. Unused plugins add noise, increase cognitive load, and can introduce confusion when multiple tools overlap in functionality.

Krew makes cleanup trivial:

kubectl krew uninstall <plugin-name>

This command removes the plugin binary entirely, ensuring it is no longer available as a kubectl subcommand. Regularly pruning unused plugins helps keep your local environment focused, predictable, and aligned with the workflows your team actually relies on.

Must-Have Plugins to Boost Productivity

While kubectl is the standard interface for interacting with Kubernetes, plugins turn it into a highly customized control plane for day-to-day operations. They add purpose-built subcommands that automate repetitive tasks, surface better diagnostics, and reduce the amount of YAML and manual inspection required to get work done.

At scale, however, local productivity tools introduce a new challenge: consistency. Ensuring every engineer uses an approved, up-to-date set of plugins can become an operational burden. This is where a centralized platform matters. Individual plugins optimize local workflows, while Plural’s unified dashboard provides a consistent, secure, and observable environment for managing your entire Kubernetes fleet. Together, they ensure productivity gains apply not just locally, but across all clusters.

Below are several high-impact plugins, grouped by the problems they solve.

For resource management and debugging

Inspecting resources, understanding dependencies, and debugging live systems are daily tasks for platform engineers. The right plugins dramatically reduce the time spent navigating manifests and logs by providing concise summaries and interactive views directly in the terminal.

For persistent, UI-driven exploration across clusters, Plural’s embedded Kubernetes dashboard complements these tools by eliminating the need to manage kubeconfigs or VPN access while maintaining full visibility.

Commonly used plugins in this category include:

• kubectx and kubens
  These utilities simplify switching between clusters and namespaces. Instead of verbose kubectl config commands, you can change context with a single command, which is essential when working across multiple environments.
• k9s
  Provides a full-screen terminal UI for interacting with Kubernetes resources in real time. It offers a more visual and interactive alternative to raw kubectl output, especially useful during incident response.
• kubectl-view-utilization
  Displays CPU and memory requests, limits, and usage for nodes and workloads. This makes it easier to identify resource pressure and imbalance without pulling metrics from external systems.

For security and compliance

Security plugins help surface vulnerabilities and misconfigurations early, before they become production incidents. They are particularly valuable when evaluating third-party software or validating manifests against best practices.

At the fleet level, Plural enables consistent RBAC enforcement and uniform deployment of security tooling through Global Services, ensuring every cluster adheres to organizational standards.

Key security-focused plugins include:

• Trivy
  A comprehensive vulnerability scanner for container images, filesystems, and repositories. Integrating Trivy into local workflows helps catch known vulnerabilities earlier in the development lifecycle.
• kube-score
  Performs static analysis on Kubernetes manifests, checking them against reliability and security best practices and providing actionable recommendations.
• kubectl-who-can
  Simplifies RBAC auditing by showing which users, groups, or service accounts can perform a given action on a resource. This is especially useful when debugging unexpected permission issues.

For workflow automation and CI/CD

Automation is critical for reliable delivery. These plugins streamline common development and deployment tasks and are often embedded into scripts and CI pipelines.

While local automation improves individual workflows, Plural CD provides a fully API-driven GitOps engine to manage deployments and infrastructure changes consistently across an entire Kubernetes fleet.

High-value automation plugins include:

• Krew
  Beyond managing plugins, Krew is foundational for standardization. It allows teams to define and distribute a shared set of approved plugins with minimal friction.
• stern
  Enables tailing logs from multiple pods and containers simultaneously, with color-coded output. This is invaluable for following request flows in distributed systems during deploys or incidents.
• Helm
  Often used alongside kubectl, Helm simplifies defining, installing, and upgrading complex applications. It is effectively mandatory in most CI/CD pipelines operating on Kubernetes.

Taken together, these plugins significantly reduce operational friction. When paired with a platform like Plural, they help teams move faster locally while maintaining consistency, security, and control across the entire Kubernetes environment.

Troubleshoot Common Plugin Problems

Even in well-maintained environments, kubectl plugins can occasionally fail in non-obvious ways. Most issues fall into a small number of categories: discovery failures, permission or PATH misconfiguration, and version incompatibilities. These problems are easy to overlook on a single workstation and become more costly when multiplied across teams and clusters, where consistency is essential. A structured troubleshooting approach helps isolate and resolve issues quickly.

Fix “plugin not found” errors

The unable to find plugin error indicates that kubectl cannot locate the plugin executable. Start by confirming whether kubectl recognizes the plugin at all:

kubectl plugin list

If the plugin does not appear in the output, it is either not installed correctly or not discoverable. Verify that the binary exists, that its filename starts with the kubectl- prefix, and that it resides in a directory included in your system’s PATH. In many cases, correcting the installation location or updating PATH resolves the problem immediately.

Resolve permission and PATH issues

If a plugin is listed by kubectl plugin list but fails to execute, the issue is usually related to file permissions or PATH precedence.

Plugin binaries must be executable. You can verify and correct this with:

chmod +x <plugin-file>

Beyond permissions, the ordering of directories in PATH matters. If multiple binaries with the same name exist in different locations, the shell will execute the first one it finds. Ensure the directory containing the intended plugin appears earlier in PATH to avoid accidental conflicts. Consistent PATH configuration across developer machines is a key requirement for reliable plugin behavior.

Handle version and dependency conflicts

Some plugins depend on specific kubectl versions or assume the presence of external tools. When a plugin fails unexpectedly, consult its documentation for stated version requirements and compatibility notes.

You can inspect your client and server versions with:

kubectl version

If there is a mismatch, upgrading or downgrading either kubectl or the plugin may be necessary. When issues are not obvious from error output, low-level diagnostics can help. Tools such as strace can be used to trace system calls and identify missing libraries or failing dependencies.

For teams operating at scale on Kubernetes, standardizing plugin versions through a manager like Krew and enforcing consistency via a platform such as Plural significantly reduces the frequency and impact of these issues.

Build Your Own kubectl Plugin

Even with the breadth of the Krew ecosystem, many organizations have recurring workflows that are too specific to be addressed by a generic plugin. In those cases, building a custom kubectl plugin is the right abstraction. A custom plugin lets you encapsulate complex command sequences, automate organization-specific processes, and integrate kubectl with internal systems.

Typical examples include plugins that provision temporary sandbox namespaces, enforce pre-deployment validation rules, or wrap internal APIs behind a consistent CLI interface. By encoding these workflows as plugins, you remove reliance on undocumented scripts and individual shell aliases. This is particularly valuable when operating at scale on Kubernetes, where consistency and repeatability directly affect reliability.

Custom plugins also make it easier to enforce standards. Instead of relying on tribal knowledge, you can codify operational best practices into a tool that every engineer uses. Platforms like Plural can then help distribute and manage these plugins consistently across environments, turning local automation into an organization-wide capability.

Follow development best practices

When building a plugin, focus on maintainability and composability. In many cases, the most effective approach is to write a thin wrapper around existing, well-tested tools rather than reimplementing functionality from scratch. This keeps the plugin small, easier to reason about, and less likely to break as kubectl evolves.

If your team already maintains multiple in-house scripts that interact with kubectl, consolidating them into a single plugin is usually a net win. You gain a unified entry point, clearer versioning, and a cleaner upgrade path. To accelerate development and avoid structural mistakes, start from the official sample plugin provided by the Kubernetes project. It demonstrates the expected layout, argument handling, and interaction patterns that kubectl plugins should follow.

Test and distribute your custom plugin

A plugin is production software and should be treated accordingly. Before distribution, invest in testing at multiple levels. Unit tests validate your core logic, while integration tests ensure the plugin behaves correctly when interacting with a real cluster. This is especially important for plugins that mutate state or enforce policy.

Once the plugin is stable, the most effective distribution mechanism is Krew. Publishing through Krew makes installation and upgrades trivial for users and aligns your plugin with the standard kubectl tooling workflow. Before submitting, review the Krew submission guidelines carefully to ensure your plugin meets the required quality, security, and maintenance standards.

By building, testing, and distributing custom plugins in this way, you transform one-off scripts into a durable part of your Kubernetes tooling ecosystem.

Related Articles

• Kubernetes CNI: Kubernetes Networking Explained (2025)
• What is a CNI Plugin? A Guide to K8s Networking

Frequently Asked Questions

What's the real difference between managing plugins manually versus using Krew? Manually managing plugins by placing binaries in your PATH works fine if you're the only person using them on a single machine. However, this approach breaks down quickly in a team environment. Krew provides a standardized way to discover, install, and update plugins, ensuring every engineer is using the same version of the same tool. This consistency is critical for collaborative troubleshooting and maintaining a stable operational workflow, much like a centralized platform ensures consistency across your Kubernetes clusters.

Can a kubectl plugin be a security risk? Yes, absolutely. A kubectl plugin is an executable file that runs with the same permissions as your user account. A malicious or poorly written plugin could potentially access your kubeconfig files, credentials, or other sensitive data. To mitigate this, you should only install plugins from trusted sources, like the curated Krew index. For organizations, it's wise to establish a governance process to vet and approve a standard set of plugins for team-wide use, preventing engineers from installing arbitrary tools from the internet.

I've installed a plugin with Krew, but kubectl still says "plugin not found." What should I check first? This is a common issue and almost always relates to your system's PATH environment variable. When you install Krew, it modifies your shell's startup file (like .bashrc or .zshrc) to add the plugin directory to your PATH. However, this change only takes effect in new terminal sessions. The first step is to close your current terminal and open a new one. If that doesn't work, verify that the Krew directory (~/.krew/bin) is correctly listed in your PATH by running echo $PATH.

Is it worth the effort to build a custom plugin if my team just uses a few shell scripts? Consolidating your team's custom shell scripts into a single, formal plugin is highly recommended. While scripts get the job done, they often become a form of tribal knowledge—hard to find, difficult to version, and inconsistent across different machines. A formal plugin creates a single, discoverable tool that can be version-controlled, tested, and easily distributed to the entire team using Krew. This turns scattered scripts into a maintainable piece of internal software that simplifies onboarding and standardizes your unique operational workflows.

How do kubectl plugins fit into a modern GitOps workflow? Plugins and GitOps are complementary tools that address different parts of the engineering lifecycle. GitOps provides an automated, declarative way to manage your cluster state, handling continuous deployment from a source of truth like a Git repository. Plugins, on the other hand, are primarily for interactive, ad-hoc tasks performed by engineers. You might use a plugin to quickly debug a pod that was deployed via GitOps, generate a manifest before committing it to Git, or check security compliance on a running application. They enhance the local developer experience without interfering with the automated deployment pipeline.