All posts
Muhtalip Dede profile photoMuhtalip Dede · Founder of kprompt

kubectl cheat sheet with natural-language equivalents (kprompt)

A practical kubectl cheat sheet paired with natural-language prompts — get, list, describe, logs, scale, rollback, delete, explain, Helm, and JSON CI — for operators who know the API and want faster day-2 typing.

kubectl remains the primary command-line tool for Kubernetes. This cheat sheet does not replace it — it pairs common one-liners with natural-language prompts you can run through kprompt when flag order is the bottleneck, not understanding the API.

Reads (list, get, describe, logs, explain) run immediately. Mutations (scale, deploy, rollback, named delete, Helm install/upgrade) print a plan, run safety checks, and wait for approval unless you pass --approve. Prefer staging. Experimental software — wrong plans still happen; read before you apply.

How to use this sheet

  • Left: kubectl you already trust in scripts and runbooks
  • Right: a kprompt prompt that aims at the same outcome
  • Swap api / redis / staging for your names — always pass -n on shared clusters
  • For wipe-class language and other traps, see the edge-case guide

Context and namespace

kubectlkprompt
kubectl config current-contextkprompt config # shows context/namespace defaults
kubectl config use-context stagingkprompt config set context staging
kubectl config set-context --current --namespace=stagingkprompt config set namespace staging
kubectl … -n production --context prodkprompt "…" -n production --context prod

Get and list

kubectlkprompt
kubectl get pods -n stagingkprompt "list pods" -n staging
kubectl get deploy -n stagingkprompt "list deployments" -n staging
kubectl get svc -n stagingkprompt "list services" -n staging
kubectl get nodeskprompt "list nodes" # or: how many nodes are in the cluster
kubectl get cm -n stagingkprompt "list configmaps" -n staging
kubectl get secret db-creds -n prodkprompt "get secret db-creds" -n prod
kubectl get deploy,po -n stagingkprompt "list deployments" -n staging # then list pods

Generic get/list works for discoverable built-ins and CRDs when discovery can resolve the kind. Prefer group-qualified names (deployments.apps) when short names collide — see the edge-case guide.

Describe, logs, explain

kubectlkprompt
kubectl describe deploy/api -n stagingkprompt "describe api" -n staging
kubectl logs deploy/api -n staging --tail=100kprompt "logs api" -n staging
kubectl logs deploy/api -n staging --previouskprompt "logs api" -n staging # then ask for previous in follow-up if needed
(manual chain: get → describe → events → logs)kprompt "explain why api is crashing" -n staging
(same ladder for readiness)kprompt "explain why deployment api is not ready" -n staging

Incident start

kprompt "explain why payment-api is crashing" -n production
kprompt "logs payment-api" -n production
kprompt "describe payment-api" -n production

Scale, deploy, rollback (plan + approve)

kubectlkprompt
kubectl scale deploy/api --replicas=3 -n stagingkprompt "scale api to 3" -n staging
kubectl rollout undo deploy/api -n stagingkprompt "rollback api" -n staging
kubectl rollout status deploy/api -n stagingkprompt "rollback api" -n staging --wait # or scale --wait
kubectl create deploy redis --image=redis:7 -n cachekprompt "deploy redis" -n cache
kubectl delete deploy redis -n cachekprompt "delete deployment redis" -n cache

Mutation loop

$ kprompt "scale api to 3" -n staging

Plan
  1. kubectl scale deployment/api --replicas=3 -n staging

Risk: low
Apply? [y/N]

Hard denies block wipe-class prompts (delete all pods, wipe namespace, …). Named delete is Pod, Deployment, or Service only today. Details: safety post and edge-case guide.

Helm (when charts own the release)

helm / kubectl worldkprompt
helm install redis bitnami/redis -n cachekprompt "install redis" -n cache
helm upgrade … --version 1.3kprompt "upgrade nginx to 1.3" -n staging
helm uninstall --all # dangerous(hard deny — name a single release)

Requires helm on PATH. Plans can include template/dry-run style previews before approve. Deeper Helm vs raw kubectl decision guide is next on the content backlog.

Performance and traces

Classic pathkprompt
Prom UI / kubectl top / custom PromQLkprompt "why is my api slow?" -n production
Jaeger/Tempo UI searchkprompt "trace payment request" -n production
kubectl get hpa -n production(covered inside performance explain when Prom is configured)

Check what is wired

kprompt tools
kprompt "why is my api slow?" -n production

CI and JSON

PatternCommand
Emit PlanResultkprompt "scale api to 10" -n prod -o json
Gate denied… | jq -e '.risk.denied == false'
Apply after gatekprompt "scale api to 10" -n prod --approve --wait

Full pipeline patterns: CI plan gates post and /docs/ci.

History

Replay without retyping

kprompt history
kprompt history rerun 3
kprompt history rerun 3 --approve   # only if you already trust that plan

When to stay on raw kubectl

  • Exact scripts and GitOps PRs — commit kubectl/helm, not chat
  • Obscure API fields and one-off CRD patches you already know by heart
  • Air-gapped emergencies when the LLM provider is unreachable (unless Ollama is local)
  • Anything your org forbids sending operational context to a model

Quick install

Try the pairs on staging

curl -fsSL https://kprompt.ai/install | bash
export KPROMPT_GEMINI_API_KEY="..."

kprompt "list deployments" -n staging
kprompt "explain why api is not ready" -n staging
kprompt "scale api to 2" -n staging    # review plan → y or n

For incident phrasing by error type, use the error prompt playbook. For wipe jokes and --approve traps, use the edge-case guide. For why we compile to a plan instead of racing chat REPLs, see the intent compiler note. kubectl literacy stays the foundation — natural language is the accelerator.

Related posts