Kubernetes is insanely powerful and becomes much easier to manage when you extend kubectl with plugins. Thanks to the open-source community (and the Krew plugin manager), you can add tons of new subcommands to kubectl that streamline tasks and make cluster management easier.
But with hundreds of available plugins, how do you decide which to try?
We’re sharing our favorites. All the plugins that made our list are actively maintained and compatible with recent Kubernetes versions (think 1.30+).
Let’s dive in!
<h2>1. Preq – Detect Reliability Issues Early</h2>
What is it:
<code>preq</code> (pronounced “preek”) is a reliability problem detector that looks for common problems in your application before they cause outages. It is powered by a community-driven catalog of failure patterns (sort of like a vulnerability database, but for reliability).
With the <code>preq</code>, you can run checks against your running application cluster and get alerted to bugs, misconfigurations, or anti-patterns that others have already identified.
Why it’s useful:
If you’ve ever been blindsided by a production incident, <code>preq</code> can be a lifesaver. It hunts through events and configurations looking for sequences that match known failure patterns.
When it finds something, it provides a detailed report (with a recommended fix) so you can act fast. In short, it brings SRE expertise to your fingertips, helping teams pinpoint and mitigate problems before they escalate. It’s like having someone checking your cluster 24/7 (for free and open source!).
<blockquote>
This is an exciting new project, you can find and ⭐ star the repo here: <a href="https://github.com/prequel-dev/preq" target="_blank" rel="noopener nofollow">https://github.com/prequel-dev/preq</a>
</blockquote>
Installation:
<pre><code>kubectl krew install preq
</code></pre>
<blockquote>
Pro-tip: <a href="https://krew.sigs.k8s.io/docs/user-guide/setup/install/" target="_blank" rel="noopener nofollow">Install</a> the Krew plugin manager first
</blockquote>
Example usage:
Once installed, you can run <code>preq</code> on a specific workload or pod. For instance, to run reliability checks on a PostgreSQL pod:
<pre><code>kubectl preq pg17-postgresql-0
</code></pre>
This will scan the pod’s logs and events against the library of Common Reliability Enumeration (CRE) rules. If any known issues are detected, you’ll get an output detailing the problem and how to fix it (with references to documentation).
You can even schedule <code>preq</code> as a CronJob in your cluster to continuously monitor and push alerts (e.g. to Slack) when something’s amiss. In short, <code>preq</code> gives you proactive reliability insights that help stop outages before they happen.
<h2>2. Neat – Clean Up Verbose YAML Output</h2>
What is it:
kubectl-neat does exactly what it sounds like – it neatens up Kubernetes YAML output by removing all the clutter. When you do kubectl get … -o yaml, the output is often filled with extra fields (status, managedFields, selfLink, etc.) that make it hard to focus on the spec. neat strips out those noisy fields and default values, leaving you with a clean manifest that’s much easier to read.
Why it’s useful:
If you find your eyes glazing over from endless autogenerated metadata, this plugin is for you. It omits fields like managedFields, status, creationTimestamp, resourceVersion, and other boilerplate that Kubernetes injects. The result is a tidy view of the resource’s actual configuration.
This is super helpful for troubleshooting or comparing manifests – you can see just the fields you or your tools defined, without the Kubernetes-added noise. In short, neat makes YAML outputs concise
and readable.
Installation:
<pre><code>kubectl krew install neat
</code></pre>
Example usage:
Simply pipe any verbose output into kubectl neat. For example:
<pre><code>kubectl get podnginx-abc123 -o yaml | kubectl neat
</code></pre>
This will output the YAML for pod nginx-abc123 but without all the junk (owner references, timestamps, default values, etc.).
You can then easily diff or inspect this trimmed manifest. It’s a huge timesaver when you want to quickly understand a resource’s config without wading through Kubernetes added fields.
<h2>3. View-Secret – Decode Secrets on the Fly</h2>
What is it:
No more manual Base64 decoding! The kubectl-view-secret plugin makes it effortless to view Kubernetes Secrets in plain text. Normally, if you do <code>kubectl get secret my-secret -o yaml</code>, you’ll see Base64 encoded content for each key. With view-secret, those values are decoded to human-readable strings automatically.
Why it’s useful:
Ever needed to quickly check what value was stored in a Secret? This plugin saves you tons of time. Instead of copying the encoded string and running <code>echo ... | base64 -d</code> for each key, you just run one command and see actual secret values. This is especially handy for Secrets with multiple keys, like TLS certs or app configs. It’s also great for verifying that your Secret data is correct (in dev/test environments) without the hassle of decoding. Essentially, view-secret eliminates the manual steps when managing Secrets.
Installation:
<pre><code class="language-bash">kubectl krew install view-secret
</code></pre>
Example usage:
To view a secret named my-secret in default namespace, just run:
<pre><code class="language-bash">kubectl view-secret my-secret --all
</code></pre>
Adding the --all flag shows all key-value pairs. For example, you might get:
<pre><code>key1=supersecret
key2=topsecret
</code></pre>
as the output. No more copy-pasting and decoding – you immediately see that key1 is “supersecret” and key2 is “topsecret”. In one quick command, you have your secret values at hand (be careful where you run this though, as it will expose sensitive info in your terminal).
<h2>4. Tree – Visualize Resource Ownership</h2>
What is it:
The kubectl-tree plugin displays ownership hierarchy in your cluster in a nice tree format. Kubernetes objects often own or control other objects (e.g., a Deployment owns ReplicaSets which own Pods). tree lets you pick a top-level resource and see all its descendants laid out as an ASCII tree.
Why it’s useful:
This is fantastic for understanding which resources are linked together. For example, if you have a complex app, you can run kubectl tree on a Deployment or on a CustomResource and instantly see the chain of owned objects beneath it. It’s especially useful with CRDs, where the relationships might not be obvious. Instead of manually cross-referencing owners, you get a clear picture: e.g., a StatefulSet -&gt; Pods -&gt; PVCs, etc. This helps in cleanup (to ensure you delete dependents) and in troubleshooting cascading issues. In short, tree gives you a birds-eye view of how Kubernetes controllers have orchestrated your resources in a hierarchy.
Installation:
<pre><code class="language-bash">kubectl krew install tree
</code></pre>
Example usage:
To see what a particular resource owns, run:
<pre><code class="language-bash">kubectl tree deploy my-app
</code></pre>
This might output a tree of all objects created by the Deployment my-app, such as ReplicaSets and Pods. For instance:
<pre><code>Deployment/my-app
└─ ReplicaSet/my-app-5fd76f7d5c
 ├─ Pod/my-app-5fd76f7d5c-abcde
 └─ Pod/my-app-5fd76f7d5c-fghij
</code></pre>
This tells you the Deployment owns a ReplicaSet, which in turn has two Pods. You can use kubectl tree on other high-level resources too (like an Ingress or a CRD instance) to reveal what’s underneath. It’s a superb way to navigate complex deployments and ensure you understand resource dependencies.
<h2>5. Tail – Stream Logs from Multiple Pods</h2>
What is it:
kubectl-tail (the Krew plugin name is just tail) is a handy plugin for tailing logs from multiple pods in real time. It’s like a supercharged version of <code>kubectl logs -f</code>, allowing you to aggregate logs across several pods or even an entire label/selector. Under the hood, this plugin is based on Kail, providing Stern-like functionality directly as a kubectl plugin.
Why it’s useful:
When debugging an app that’s distributed across many pods (say a deployment with replicas or a microservice with multiple components), it’s inconvenient to open separate log streams for each pod. kubectl tail solves this by letting you target multiple pods at once – for example, by deployment name, service name, or label selector. The logs from all matching pods are merged and streamed to your terminal. You can even filter by timeframe (–since) or specific pods. As Alex Moss noted, one great feature is targeting a higher-level resource: e.g. <code>kubectl tail --svc=my-service</code> to see logs from all pods behind that Service. This plugin simplifies multi-pod debugging and gives you a consolidated, live view of what’s happening across your application.
Installation:
<pre><code class="language-bash">kubectl krew install tail
</code></pre>
Example usage:
Here are a few common ways to use kubectl tail:
By namespace: View logs from all pods in a namespace (e.g. default):
<pre><code class="language-bash">kubectl tail --ns default
</code></pre>
By label selector: Stream logs from pods matching a label, e.g. all pods with app=web:
<pre><code class="language-bash">kubectl tail -l app=web --since=10m
</code></pre>
(This would show the last 10 minutes of logs from every pod labeled app=web, and then continue streaming.)
Multiple specific pods: If you want to tail two particular pods:
<pre><code class="language-bash">kubectl tail --pod web-abcde --pod web-fghij --since=1h
</code></pre>
In each case, logs from all targeted pods will stream live to your terminal. The plugin even color-codes logs by pod, making it easier to distinguish sources. It’s a simple but powerful way to debug issues that span many pods without juggling multiple kubectl logs commands.
Checkout part II.

The squad for Kubernetes afficionados. 
All things Kubernetes: best practices, tools, tricks, new features, operator building. 
For experienced Kubernetes administrators and Kube-newbies alike.


KubeSquad

10 kubectl Plugins That Make You the Most Valuable Kubernetes Engineer in the Room (Part I)

Ese tree no lo cachaba y esta bueno, a instalar con krew