Kubernetes prompts for ChatGPT, Claude and Codex

The best Kubernetes prompts give the model your manifests and the real output of kubectl describe and kubectl logs, then ask for a ranked diagnosis or a manifest you can validate before applying. Below are 12 Kubernetes prompts for ChatGPT, Claude, Claude Code and Codex for writing manifests, setting probes and resources, debugging broken pods and services, and locking down access.

If your container image isn't ready yet, start with the Docker prompts. The prompts here assume you have an image and a cluster.

How to use these prompts

Copy a prompt, replace each blank in double braces, or keep the default after the colon. {{namespace:default}} means the default namespace unless you change it.

Three habits matter with Kubernetes:

• Paste real cluster output. kubectl describe shows events and the reason a pod is stuck, which is most of the diagnosis. The debug pods guide starts there too.
• Remove secrets first. Strip Secret values, tokens and internal hostnames from anything you paste.
• Validate before applying. Ask the model for YAML, then run kubectl apply --dry-run=server -f file.yaml and kubectl diff -f file.yaml yourself.

In an agent, give it a read-only context and let it collect the output.

How do you write Kubernetes manifests with AI?

1. Write a Deployment and Service

The starting point for any app. Listing the production details up front avoids a bare-minimum manifest.

Write Kubernetes manifests for {{app:a web API}} running image
{{image:registry.example.com/api:1.4.2}} on port {{port:8080}}.

- A Deployment with {{replicas:3}} replicas and a rolling update strategy
- Liveness, readiness and startup probes on {{health_path:/healthz}}
- CPU and memory requests and limits (ask me if you need usage numbers)
- A securityContext: non-root, read-only root filesystem, no privilege
  escalation, drop all capabilities
- Consistent labels on the Deployment, pods and selector
- A ClusterIP Service in front of it

Explain each choice in one line.

2. Set up probes correctly

For apps that get restarted during slow startups or receive traffic before they're ready. The probes guide explains that a pod whose containers aren't ready gets no traffic through Services, and that a startup probe protects slow-starting containers.

My app takes up to {{startup_time:90 seconds}} to start. It exposes
{{endpoints:/healthz for liveness and /ready for readiness}}.

Current probes:
{{probes}}

Write liveness, readiness and startup probes for it. Explain what each one
protects against, how failureThreshold and periodSeconds give the startup
window, and why the liveness check should not depend on the database or
other services.

3. Pick requests and limits from real usage

For resource settings copied from a blog post. Usage numbers turn guesses into a decision.

Help me set CPU and memory requests and limits for {{workload:my API pods}}.

Observed usage over {{period:7 days}}:
{{usage}}

Current settings:
{{resources}}

Recommend requests and limits with reasons. Explain what happens when the
container hits each limit (CPU throttling versus being killed for memory),
whether a CPU limit makes sense here, and the risk of setting requests too
low for scheduling.

4. Move config and secrets out of the image

For apps with configuration baked into the image or into plain env values.

This Deployment hard-codes configuration in env values. Move it out:
- Non-secret settings into a ConfigMap
- Secrets into a Secret, referenced by name
- Mount or inject them as {{method:environment variables}}

Show the ConfigMap, the Secret with placeholder values only, and the
updated Deployment. Explain how a change to the ConfigMap reaches running
pods and whether they need a restart.

{{deployment}}

How do you debug broken pods with AI?

5. Pod in CrashLoopBackOff

For pods that start, crash and restart forever. The logs from the crashed instance come from kubectl logs --previous, which the kubectl logs reference describes as printing "the logs for the previous instance of the container."

My pod is in CrashLoopBackOff in namespace {{namespace:default}}.

Output of kubectl describe pod:
{{describe}}

Output of kubectl logs --previous:
{{logs}}

Rank the three most likely causes with the line of evidence for each: app
error, failing liveness probe, OOMKilled, bad command or arguments,
missing config or secret. Give the next command to confirm the top cause
and the fix.

6. Pod stuck in Pending

For pods that never get scheduled. The scheduler explains why in the events.

My pod has been Pending for {{duration:10 minutes}}.

Output of kubectl describe pod (especially Events):
{{describe}}

Node capacity from kubectl describe nodes or kubectl top nodes:
{{nodes}}

Explain the scheduler's message in plain language. Check resource
requests, node selectors and affinity, taints and tolerations, and
unbound PersistentVolumeClaims. Give the fix and the trade-off of each
option.

7. Service not reachable

For a Service that returns nothing or times out. Most often the selector or port doesn't match the pods.

Requests to my Service {{service:api}} in namespace {{namespace:default}}
fail with: {{error}}

Service YAML:
{{service_yaml}}

Pod labels and ports (kubectl get pods --show-labels, container ports):
{{pods}}

Output of kubectl get endpointslices -l kubernetes.io/service-name={{service:api}}:
{{endpoints}}

Check the selector, port and targetPort, readiness, and any NetworkPolicy.
Give the fix and a command to test from inside the cluster.

8. OOMKilled or CPU throttling

For pods that get killed or slow down under load.

My {{workload:API}} pods {{symptom:get OOMKilled under load}}.

kubectl describe pod output (Last State and resources):
{{describe}}

Memory and CPU usage over time:
{{usage}}

Tell me whether this is a real leak, normal growth or a limit set too
low. Explain how to tell them apart from the usage curve. Recommend new
limits or a code change, and what to measure after the change.

How do you make workloads reliable and secure?

9. Survive node drains and scale with load

For apps that go down during cluster upgrades. A PodDisruptionBudget limits how many pods voluntary disruptions, like a drain, can take down at once.

My Deployment {{deployment:api}} runs {{replicas:3}} replicas. Write:
- A PodDisruptionBudget so a node drain never takes it below
  {{min_available:2}} available pods
- A HorizontalPodAutoscaler that scales between {{min:3}} and {{max:10}}
  replicas on {{metric:CPU utilization at 70 percent}}
- Topology spread constraints so replicas land on different nodes

Explain how the PDB and the HPA interact, and one setting that would
block node drains entirely.

10. Write least-privilege RBAC

For a ServiceAccount that needs a few permissions, not cluster-admin. The RBAC good practices page recommends avoiding wildcards and preferring RoleBindings over ClusterRoleBindings.

My workload {{workload:a deploy bot}} needs to
{{actions:read pods and restart Deployments}} in namespace
{{namespace:default}} only.

Write a ServiceAccount, a Role with the minimum verbs and resources, and a
RoleBinding. No wildcards. Then give the kubectl auth can-i commands, using
--as=system:serviceaccount:NAMESPACE:NAME, that prove it can do exactly
this and nothing more.

11. Add a NetworkPolicy

For namespaces where every pod can talk to every other pod. NetworkPolicies only work if the cluster's network plugin supports them, so the prompt asks you to check.

In namespace {{namespace:default}}, only {{allowed:pods labeled app=web}}
should reach {{target:pods labeled app=api}} on port {{port:8080}}. The api
pods need egress to {{egress:the database and DNS}} only.

Write a default-deny NetworkPolicy plus the allow policies. Explain how to
check that my network plugin enforces NetworkPolicy, and give commands to
test that allowed traffic works and blocked traffic fails.

12. Review a manifest before applying

For a second pair of eyes before a change reaches production.

Review this Kubernetes manifest before I apply it to {{environment:production}}.

Check: image tags (no latest), probes, requests and limits, securityContext,
labels and selectors, replica count and PDB, Secrets in plain text,
hostPath or privileged settings, and deprecated API versions for
Kubernetes {{k8s_version:1.37}}.

Rank findings by risk with the fix for each. Then list what kubectl diff
should show if the change is safe.

{{manifest}}

What should you check before you apply the output?

Treat every AI-written manifest as a draft until it passes these checks:

Paste any failure back into the same conversation. The real error message is the fastest way to a correct second draft.

Turn your favorite one into a skill

If you review or write manifests every week, make the prompt a skill so Claude Code or Codex follows it automatically. The manifest review and CrashLoopBackOff prompts are good first picks. Paste one into the free SKILL.md generator. For infrastructure around the cluster, see the Terraform skill, and for the image itself the Docker skill guide.

Kipt keeps prompts like these as Markdown in a private GitHub repo you own, with fillable {{blanks}}, tags and Cmd+K search. Skills saved there install into Claude Code or Codex with one command.