Best AI Agent Skills for Kubernetes in 2026

A Kubernetes cluster breaks at 2 a.m., and the on-call engineer's first ten minutes are spent typing kubectl commands they half-remember, grepping through pod logs, and trying to reconstruct what changed. That triage work — read the state, spot the anomaly, form a hypothesis — is exactly what an agent is good at, if you give it eyes into the cluster. The skills below do that. They let an agent query your Kubernetes state, diagnose failing pods in plain language, watch real network traffic, and port-forward services for local work, instead of leaving you to remember the flag order under pressure.

If you run workloads on Kubernetes or OpenShift, here are the skills worth installing in 2026. Everything runs in Claude Code or as an MCP server, and I've flagged trust tier and license for each — a tool with cluster access can read secrets and change state, so scope matters more here than almost anywhere.

The short list

K8sGPT — the diagnosis engine

Start here if the job is figuring out why something is broken. K8sGPT (k8sgpt-ai/k8sgpt, verified, Apache-2.0, ~7.9k stars) scans a cluster, finds the problems, and explains them in language a human can act on — a CNCF Sandbox project with real production adoption behind it.

claude skill add k8sgpt-ai/k8sgpt

The reason it's the first install is that it collapses the slowest part of an incident: mapping a symptom to a cause. A CrashLoopBackOff tells you a pod is unhappy; K8sGPT tells you it's unhappy because of a missing config map or a failed image pull, in a sentence. Handing that analysis to an agent means it starts triage from a diagnosis instead of from raw kubectl describe output. For on-call work, that's the difference between minutes and the first useful sentence.

Kubernetes MCP Server — full management access

When you need the agent to actually operate the cluster, Kubernetes MCP Server (containers/kubernetes-mcp-server, verified, Apache-2.0, ~1.7k stars) is the heavyweight pick. Maintained under the containers org, it speaks both Kubernetes and OpenShift and exposes broad management operations to the agent.

claude mcp add kubernetes-mcp-server -- npx -y containers/kubernetes-mcp-server

This is the one for teams on Red Hat OpenShift or anyone who wants the agent managing resources, not just reading them. Because it's maintained under the same umbrella as Podman and the container tooling, it tracks the ecosystem closely. The flip side of its power is that it can change cluster state, so it belongs behind a read-only or scoped kubeconfig until you trust it in a given environment — more on that below.

MCP Server Kubernetes — the lightweight operator

If OpenShift isn't in the picture and you want something simpler, MCP Server Kubernetes (Flux159/mcp-server-kubernetes, verified, MIT, ~1.5k stars) gives the agent clean kubectl-style operations against a standard cluster without the OpenShift surface area.

claude mcp add mcp-server-kubernetes -- npx -y Flux159/mcp-server-kubernetes

Think of it as the plain-Kubernetes counterpart to the containers-org server. For a vanilla EKS, GKE, or AKS cluster, its smaller footprint is a feature — less to reason about, an MIT license that's easy to bring into a company repo, and enough coverage to list, inspect, and manage the resources you touch day to day. Most teams not on OpenShift will find this the more natural fit.

Kubeshark — see the traffic, not just the config

Some failures aren't in the YAML — they're in the wire. Kubeshark (kubeshark/kubeshark, verified, Apache-2.0, ~12k stars) is eBPF-powered network observability that indexes L4 and L7 traffic across the cluster, so the agent can see what services are actually saying to each other.

claude mcp add kubeshark -- npx -y kubeshark/kubeshark

This covers the class of problem the state-management servers can't: the pods are Running, the config looks right, and requests are still failing. Kubeshark shows the agent the real traffic — which call 500s, which service never gets hit, where the latency lives. eBPF means it captures this at the kernel level without you instrumenting the app. For debugging service-to-service issues in a mesh, it's the tool that turns "everything looks healthy" into an actual answer.

Kubefwd — bulk port-forwarding for local work

Developing against a cluster means constantly forwarding services to localhost, one kubectl port-forward at a time. Kubefwd (txn2/kubefwd, verified, Apache-2.0, ~4.1k stars) forwards them in bulk, mapping a whole namespace's services to your local machine with their real cluster DNS names.

claude mcp add kubefwd -- npx -y txn2/kubefwd

It's the quality-of-life pick for local development. Instead of juggling a dozen forwards and remembering which port maps to which service, the agent brings up the whole namespace and your local code talks to services by the same names they use in-cluster. For anyone iterating on a microservice against its real dependencies, that removes a genuinely tedious step.

SkyPilot — one workload, any infrastructure

Kubernetes rarely lives alone — teams also run jobs on cloud VMs and, increasingly, on scarce GPU capacity. SkyPilot (skypilot-org/skypilot, verified, Apache-2.0, ~10k stars) gives the agent one interface to run and scale workloads across Kubernetes and cloud infrastructure, picking where a job actually lands.

claude skill add skypilot-org/skypilot

This is the pick when the question is broader than one cluster — batch jobs, AI training, anything that should run wherever there's capacity. SkyPilot abstracts the "which cluster, which cloud, which GPU" decision, which is exactly the kind of routing an agent can handle if you let it. It stretches past pure Kubernetes ops into infrastructure orchestration, and for GPU-hungry teams that breadth is the whole point.

How to choose

Match the tools to what you're actually doing:

• On-call, diagnosing failures: K8sGPT first, add Kubeshark when the problem is network-shaped.
• Managing an OpenShift cluster: Kubernetes MCP Server (containers org).
• Managing a vanilla EKS/GKE/AKS cluster: MCP Server Kubernetes — lighter, MIT-licensed.
• Local development against the cluster: Kubefwd for bulk forwarding.
• Workloads beyond one cluster (batch, GPU, multi-cloud): SkyPilot.

If your remit is wider than Kubernetes, our agent skills for DevOps engineers roundup covers CI/CD and the broader ops stack, agent skills for incident response goes deeper on the on-call side, and agent skills for API development is relevant if the services in your cluster are what you're building.

Read-only first, always

There's one operating rule that matters more than which server you pick: give the agent a read-only path into the cluster before you give it a writing one. Kubernetes access is not like a file edit you can undo — a bad delete or scale against production is real, immediate, and sometimes irreversible. The safe pattern is a scoped kubeconfig or a service account with read-only RBAC for the diagnosis phase, so the agent can inspect, correlate, and propose without being able to change anything. K8sGPT and Kubeshark are naturally read-heavy and fit this mode well. The management servers (Kubernetes MCP Server, MCP Server Kubernetes) are where you graduate to write access — and even then, do it per-environment, starting in staging, never handing production write access as the default. The agents here are genuinely useful precisely because they can touch the cluster; that same reach is why you stage the trust.

Trust notes for a high-blast-radius category

Cluster access is about the highest-stakes access on this list. A Kubernetes server can read secrets, list every workload, and — if permitted — change or delete resources. So the trust bar is set accordingly. The featured picks are all verified-tier with permissive licenses (Apache-2.0 across most of them, MIT for the Flux159 server), and several have institutional backing: K8sGPT is a CNCF Sandbox project, Kubernetes MCP Server sits under the containers org, and SkyPilot is a well-adopted open project.

The control that matters isn't the tier, though — it's RBAC. Whatever server you run, the cluster's own role-based access control is your real seatbelt. Scope the service account tightly, prefer read-only for diagnosis, and expand write access one environment at a time. A verified skill with a wide-open cluster-admin kubeconfig is still a wide-open cluster-admin kubeconfig. Let the RBAC, not the trust tier, be the thing standing between the agent and production.

FAQ

Skill or MCP server for Kubernetes — which do I need? A skill (claude skill add) teaches the agent Kubernetes knowledge and diagnostic patterns, like K8sGPT's failure analysis or SkyPilot's orchestration model. An MCP server (claude mcp add) connects live to your cluster so the agent can query state, watch traffic, or manage resources. Most setups want a diagnosis skill plus a management server.

Can I keep the agent from changing my cluster? Yes, and you should start there. Point it at a kubeconfig backed by a read-only service account, and its RBAC will block any write. Do diagnosis in that mode, and only widen permissions per environment once you trust the setup — staging before production, never production write by default.

Does this work with managed Kubernetes like EKS or GKE? Yes. MCP Server Kubernetes and the containers-org server work against any standard cluster, managed or not — they use your kubeconfig, so if kubectl reaches your EKS/GKE/AKS cluster, so do they. The containers-org server additionally speaks OpenShift.

What handles network debugging versus config problems? Different tools. K8sGPT and the management servers reason about cluster state — pods, configs, resources. Kubeshark handles the wire: it captures L4/L7 traffic via eBPF, so it's the one for "the config is fine but requests are still failing" service-to-service problems.

Is K8sGPT production-ready? It's a CNCF Sandbox project with wide adoption (~7.9k stars) and Apache-2.0 licensed. Plenty of teams use it in real environments. As always, run it with read scoped appropriately and treat its analysis as a strong starting hypothesis you confirm, not a final verdict.