kube-medic_skill

Overview

This skill provides AI-powered Kubernetes cluster triage and diagnostics accessible through kubectl-style commands. It correlates events, pod states, logs, resource metrics, and deployment history to produce clear root-cause analysis and actionable fixes. It is read-only by default and guides any write operations with explicit command proposals and confirmation steps.

How this skill works

kube-medic runs targeted subcommands (sweep, pod, deploy, resources, events) to collect node status, pod details, logs, events, and resource usage. It correlates signals across sources—for example linking OOMKilled events to low memory limits or matching deployment rollouts to timing of pod failures. When a fix is needed, it presents exact kubectl commands, explains risks, and waits for explicit user confirmation before executing allowed write actions.

When to use it

• You need a quick health triage across an entire cluster or specific namespace (use sweep).
• A specific pod is crashing or misbehaving and you want a correlated autopsy (use pod).
• A deployment appears stuck, failing to roll out, or you need rollout history (use deploy).
• You suspect CPU/memory pressure or want top resource consumers and missing limits (use resources).
• You want a concise timeline of recent changes and warning events (use events).

Best practices

• Start with sweep to get the big picture, then deep-dive into the most critical items with pod or deploy.
• Always supply the cluster context when managing multiple clusters or ask which context to use.
• Treat kube-medic as read-only until you explicitly confirm a proposed write command.
• Narrow output by namespace for large clusters to avoid overwhelming results.
• Follow presented commands exactly and review the explained risks before confirming any write operation.

Example use cases

• Run sweep on production to find NotReady nodes, CrashLoopBackOff pods, and recent warning events.
• Run pod autopsy on a crashing pod to get container statuses, current and previous logs, events, and a diagnosis.
• Inspect a failing deployment to see rollout status, observedGeneration vs generation, and ReplicaSet revisions.
• List top memory and CPU consumers and identify pods missing resource requests or limits.
• Show the last 15–60 minutes of events in kube-system after a control-plane or networking incident.