Kubernetes prompts help US platform engineers and DevOps teams move faster on the yak-shaving parts of cluster work — Deployment manifests, Service and Ingress wiring, RBAC roles, autoscaling policies, and the endless triage of CrashLoopBackOff pods — without letting an AI push YAML you have not read. Every prompt below is written for real production clusters running on EKS, GKE, AKS, or on-prem with kubeadm. The prompts assume you have kubectl authenticated to a real cluster, a namespace you can experiment in, and CI/CD (Argo CD, Flux, GitHub Actions) that runs kubectl diff or a policy engine before anything hits prod.
These templates are opinionated about tooling. Manifests target the current stable Kubernetes API versions (apps/v1 for Deployments, networking.k8s.io/v1 for Ingress and NetworkPolicy, autoscaling/v2 for HPA). Package management is Helm 3 or Kustomize. Policy is OPA Gatekeeper or Kyverno. Observability is Prometheus + Grafana with the kube-state-metrics and node-exporter charts installed. Every prompt starts with 'Act as a US Kubernetes platform engineer.' so the model stays in a production-ops voice rather than tutorial mode.
This content is technical guidance, not a substitute for cluster-specific runbooks or your organization's change-management process. Never apply AI-generated YAML directly to production. Run kubectl diff, kubectl apply --dry-run=server, or Argo CD's diff view first, then apply in a staging namespace, then promote through your normal review. Blast radius on a bad Deployment or NetworkPolicy is real — a wrong selector can black-hole traffic to an entire namespace in seconds.
Kubernetes prompts help US platform engineers and DevOps teams move faster on the yak-shaving parts of cluster work — Deployment manifests, Service and Ingress wiring, RBAC roles, autoscaling policies, and the endless triage of CrashLoopBackOff pods — without letting an AI push YAML you have not read. Every prompt below is written for real production clusters running on EKS, GKE, AKS, or on-prem with kubeadm. The prompts assume you have kubectl authenticated to a real cluster, a namespace you can experiment in, and CI/CD (Argo CD, Flux, GitHub Actions) that runs kubectl diff or a policy engine before anything hits prod.
These templates are opinionated about tooling. Manifests target the current stable Kubernetes API versions (apps/v1 for Deployments, networking.k8s.io/v1 for Ingress and NetworkPolicy, autoscaling/v2 for HPA). Package management is Helm 3 or Kustomize. Policy is OPA Gatekeeper or Kyverno. Observability is Prometheus + Grafana with the kube-state-metrics and node-exporter charts installed. Every prompt starts with 'Act as a US Kubernetes platform engineer.' so the model stays in a production-ops voice rather than tutorial mode.
This content is technical guidance, not a substitute for cluster-specific runbooks or your organization's change-management process. Never apply AI-generated YAML directly to production. Run kubectl diff, kubectl apply --dry-run=server, or Argo CD's diff view first, then apply in a staging namespace, then promote through your normal review. Blast radius on a bad Deployment or NetworkPolicy is real — a wrong selector can black-hole traffic to an entire namespace in seconds.
Guides, tips, and deep dives for this prompt category
Create stunning Studio Ghibli-style AI art with 50 free prompts for ChatGPT. Magical landscapes, characters, food scenes, and cozy interiors in Miyazaki style.
Read moreCollectionCreate stunning Studio Ghibli-inspired images using ChatGPT GPT-4o. 50 free prompts for Ghibli art, landscapes, characters, and scenes.
Read moreCopy any prompt below, paste into ChatGPT, Claude, Gemini, or Copilot, and fill in the placeholders in [brackets].
Act as a US Kubernetes platform engineer. Write a production-ready Deployment YAML for [app name] running [container image and tag]. Include: apps/v1 apiVersion, replicas: [count], a rolling update strategy with maxSurge and maxUnavailable, labels app.kubernetes.io/name and app.kubernetes.io/part-of, resource requests and limits (cpu and memory), a readiness probe distinct from the liveness probe (path [/healthz or /ready], port [port], initialDelaySeconds tuned for typical startup), securityContext with runAsNonRoot: true and readOnlyRootFilesystem where possible, a topologySpreadConstraints block for zone spread, and a serviceAccountName field pointing to a dedicated SA (not default).
Act as a US Kubernetes platform engineer. Write a Service (ClusterIP) and an Ingress with TLS for [app name] in namespace [ns]. The Service selects pods with label app.kubernetes.io/name=[app] on port [port] targeting containerPort [port]. The Ingress uses ingressClassName [nginx or alb or gateway], host [host.example.com], TLS via cert-manager annotation cert-manager.io/cluster-issuer=[letsencrypt-prod], path type Prefix at /, and backend service reference to the Service above. Include the annotations that make sense for [ingress controller] (proxy-body-size, ssl-redirect, etc.) and note which are controller-specific.
Act as a US Kubernetes platform engineer. Generate a ConfigMap and a Secret pair for [app name] in namespace [ns]. The ConfigMap holds non-sensitive config: [list keys — LOG_LEVEL, FEATURE_FLAG_X, DB_HOST]. The Secret holds sensitive values: [list keys — DB_PASSWORD, API_TOKEN]. Show how the Deployment consumes both via envFrom (configMapRef and secretRef) and via volumeMounts for any file-based config. Note whether the Secret should be created from a sealed-secrets or external-secrets pattern for GitOps, and never inline base64-encoded real secrets in the YAML you commit.
Act as a US Kubernetes platform engineer. Set resource requests and limits for a [workload type: web API / batch job / stateful database / cache / ML inference] running [image]. Recommend starting values for CPU requests, CPU limits, memory requests, and memory limits based on typical patterns for that workload class, explain the request-vs-limit ratio you chose (why 1:2 CPU or 1:1 memory), warn about the OOMKill risk if memory limits are too tight, and suggest how to tune after observing actual usage in Prometheus (kube_pod_container_resource_usage vs. requests).
Act as a US Kubernetes platform engineer. Write an HPA (autoscaling/v2) for Deployment [name] in namespace [ns]. Target: minReplicas [min], maxReplicas [max], scale on CPU averageUtilization [target %] and memory averageUtilization [target %]. Include behavior block with stabilizationWindowSeconds for scale-down (usually 300s) and shorter for scale-up, and note whether custom metrics from Prometheus Adapter (like requests_per_second) would be a better signal than CPU for this workload. Warn about the interaction with cluster autoscaler and node warm-up time.
Act as a US Kubernetes platform engineer. Troubleshoot a CrashLoopBackOff on pod [pod name] in namespace [ns]. Here are the artifacts: kubectl describe pod output [paste], kubectl logs --previous [paste], recent events [paste]. Walk through the diagnosis: is the container exiting non-zero (bad command, missing env var, config parse error), is the liveness probe killing it before it becomes ready, is it OOMKilled (check Last State reason), is an initContainer failing, or is it a missing Secret/ConfigMap. Propose the minimal fix and how to confirm it in staging before prod.
Act as a US Kubernetes platform engineer. Write a Role and RoleBinding for ServiceAccount [sa-name] in namespace [ns] that grants exactly the permissions needed to [describe what the workload does — read ConfigMaps, list Pods for a leader election, patch its own Deployment status]. Follow least privilege: name only the resources and verbs actually needed, no wildcards, no ClusterRole unless the workload legitimately needs cluster scope. After the YAML, show the kubectl auth can-i commands to verify the effective permissions from the SA's perspective.
Act as a US Kubernetes platform engineer. Write a NetworkPolicy that isolates namespace [ns] so that pods in it can only receive traffic from [source: ingress controller namespace / same-namespace pods / a specific labeled namespace] and can only egress to [destination: kube-dns, cluster DNS, external API on port 443, a specific in-cluster service]. Include both ingress and egress rules, name the podSelector and namespaceSelector labels carefully, and note that the cluster's CNI plugin (Calico, Cilium, AWS VPC CNI with network policy support enabled) must enforce NetworkPolicy for this to actually do anything.
Act as a US Kubernetes platform engineer. Design a PersistentVolume and PersistentVolumeClaim setup for [use case: Postgres primary storage / shared media assets / prometheus TSDB / user uploads]. Recommend a StorageClass appropriate for the workload (gp3 or io2 on EKS, pd-ssd or pd-balanced on GKE, managed-csi-premium on AKS, local-path for dev), set reclaimPolicy (Retain for data you cannot lose, Delete for scratch), volumeBindingMode (WaitForFirstConsumer for zone-aware scheduling), and access mode (RWO for most, RWX only when needed). Warn about the pitfalls: RWX often needs EFS/Filestore/Azure Files, not block storage.
Act as a US Kubernetes platform engineer. Write a Helm chart values.yaml for [app name] with sensible defaults for a production deployment. Cover: image.repository and image.tag, replicaCount, resources.requests and resources.limits, service.type and service.port, ingress.enabled and ingress.host and ingress.tls, autoscaling.enabled with min/max/targetCPUUtilizationPercentage, nodeSelector/tolerations/affinity blocks (empty by default but documented), podSecurityContext and containerSecurityContext, and a serviceAccount block. Add YAML comments explaining each block and which values are commonly overridden per environment.
Act as a US Kubernetes platform engineer. Design a kubectl debug session plan for [issue: pod cannot reach internal DNS / cannot pull image from private registry / times out calling upstream service]. List the sequence of commands: kubectl get pod -o wide (which node), kubectl describe pod, kubectl logs and kubectl logs --previous, kubectl exec into the pod (or kubectl debug --image=nicolaka/netshoot if the container has no shell), then diagnostic commands inside — nslookup kubernetes.default, curl -v to the upstream, dig SRV records, check /etc/resolv.conf. For each step, state what output would confirm or rule out a hypothesis.
Act as a US Kubernetes platform engineer. Explain a rolling update strategy for Deployment [name] with maxSurge: [value or percentage] and maxUnavailable: [value or percentage]. Walk through what happens step by step during a rollout with [current replica count] pods: how many pods are added, how many old ones are killed at each step, how the readiness probe gates progression, and what the failure mode looks like if a new pod never becomes ready. Recommend values for a latency-sensitive user-facing service versus a background worker, and explain why maxUnavailable: 0 is safer but slower.
Act as a US Kubernetes platform engineer. Write an admission-controller policy for [OPA Gatekeeper or Kyverno] that enforces [policy goal: no privileged containers / required labels app.kubernetes.io/name and team / images only from approved registry ghcr.io/acme or docker.io/library / resource limits are set on every container]. Provide the full ConstraintTemplate and Constraint (Gatekeeper) or the ClusterPolicy (Kyverno), specify enforcementAction: [audit or deny], and include a test case that shows a violating manifest being rejected and a passing manifest being admitted.
Act as a US Kubernetes platform engineer. Draft a cluster upgrade runbook to go from Kubernetes [current version] to [target version] on [distribution: EKS / GKE / AKS / kubeadm]. Cover the sequence: check the Kubernetes release notes and CHANGELOG for removed APIs, run kubectl deprecations (or Pluto / kubent) to find deprecated APIs still in use, upgrade the control plane, wait and verify with kubectl version and kubectl get nodes, then roll node groups (drain, upgrade, uncordon) one at a time. List the workloads that need special handling (stateful sets, cluster autoscaler, ingress controller, CNI, metrics-server) and the rollback criteria.
Understanding the building blocks lets you adapt any prompt to your own creative direction.
Tell the AI who the output is for and what real workplace situation it should support.
Act as a federal program analyst preparing a plain-language memo for agency leadership.Name the exact deliverable: email, memo, checklist, SOP, meeting recap, training note, or status update.
Format the answer as a one-page briefing with bullets, risks, and next actions.Specify whether the output should sound official, executive-ready, plain-language, or employee-friendly.
Use a professional, neutral, public-sector tone suitable for a US agency audience.For government, HR, finance, healthcare, legal, and compliance workflows, accuracy guardrails matter more than clever wording.
Use only the facts below, flag assumptions, and include a section for items that need verification.Ask the model to surface uncertainty so the user can verify sensitive or official information before using it.
Before finalizing, list compliance risks, missing details, and any claims that need human review.Tested on this prompt category as of mid-2026. Ratings reflect quality for AI Prompts for Kubernetes specifically.
| Model | Best for | Rating |
|---|---|---|
| ChatGPT (GPT-4o / GPT-5) | Everyday drafting and summaries | |
| Claude Sonnet 4.5 | Long documents and policy | |
| Gemini 2.5 Pro | Grounded in Google workspace | |
| Copilot (M365) | Office 365 integration | |
| Perplexity | Answers with citations |
Ratings reflect suitability for this category. Free tiers available on all listed models. Last tested May 2026 by PromptSpace editors.
No. Always save the generated YAML to Git first, run kubectl apply --dry-run=server -f to catch schema errors, run it through your policy engine (Gatekeeper or Kyverno) in audit mode, apply it to a staging namespace, watch metrics and logs for at least a few minutes, and only then promote to prod through your normal GitOps flow (Argo CD, Flux) or CI pipeline. Blast radius on a bad Service selector or NetworkPolicy is measured in seconds.
Name your Kubernetes version in the prompt (EKS 1.30, GKE 1.29) so the model targets current APIs. Then run kubectl deprecations, Pluto, or kubent against the generated YAML before applying — these tools flag apps/v1beta1, extensions/v1beta1 Ingress, PodSecurityPolicy, and other removed APIs. For the ingress controller specifically, tell the model which controller (NGINX, ALB, GKE Gateway, Traefik) because annotations are controller-specific and change across major versions.
It can help, but only if you paste real evidence: kubectl describe pod, kubectl logs --previous (the previous container instance, since the current one may be terminated), and kubectl get events --sort-by=.lastTimestamp scoped to the namespace. Without those, the model guesses. With them, it can usually distinguish OOMKill from bad env config from failing liveness probe from missing ConfigMap. Always confirm the fix in staging before promoting.
Tell the model exactly what the workload needs to do — read ConfigMaps in its own namespace, patch its own Deployment status, list Pods for leader election — and reject any generated Role that uses wildcard verbs (*) or wildcard resources. After apply, run kubectl auth can-i --as=system:serviceaccount:<ns>:<sa> <verb> <resource> to enumerate what the SA can actually do. If the answer is more than you asked for, tighten the Role until it is not.
Read your organization AI tool policy first. Manifests may contain internal hostnames, container image tags that reveal architecture, and references to Secret names that leak product structure. Never paste actual Secret data (even base64-encoded — that is not encryption). For debugging, redact any customer-identifying info from logs and events before pasting. If your policy forbids external AI on infra config, run a local model or use your enterprise AI provider.
Learn the basics of creating stunning AI-generated images using prompts from our library.
GuideDiscover the secrets to crafting prompts that produce consistent, high-quality results.
CollectionCopy-paste 100 tested Midjourney v6 prompts: portraits, cinematic, fantasy, product shots & more. Free, updated for 2026 - instant results.
Social MediaCreate scroll-stopping Instagram content with these AI image prompts designed for Reels, Stories, and posts.
Browse our full library of ai prompts for kubernetes — all free, copy-paste ready, no signup.
Or use our AI Prompt Generator to create custom prompts for your exact style in seconds.
Start every prompt by naming your Kubernetes distribution and version (EKS 1.30, GKE 1.29, on-prem kubeadm 1.28), your ingress controller (NGINX, Traefik, AWS ALB, GKE gateway), your service mesh if any (Istio, Linkerd, none), and your namespace. Without those, the model will pick defaults that do not match your cluster — CRD versions drift between releases, admission controllers reject fields that used to be optional, and Ingress annotations are controller-specific.
Paste the smallest useful scope: one Deployment, one Service, one HPA at a time. For debugging prompts, include the actual output of kubectl describe pod, kubectl logs --previous, and kubectl get events --sort-by=.lastTimestamp. AI is much better at reading real events than at guessing why a pod is crashing. Always run kubectl apply --dry-run=server -f before applying, and diff against the live cluster with kubectl diff or Argo CD.
Before you kubectl apply anything to a production namespace, run through a checklist: does the manifest set resource requests AND limits (missing limits are a common cause of noisy-neighbor issues), does it define a readiness probe distinct from the liveness probe, does the Service selector actually match the Pod labels, does the Ingress host match a DNS record you control, and does the ServiceAccount have only the permissions the workload needs (least privilege).
For NetworkPolicy and RBAC changes specifically, test in a staging namespace with a copy of the workload first. A NetworkPolicy with a wrong podSelector will silently drop traffic and only show up as timeouts in the calling service. An overly broad RBAC ClusterRole can let a compromised pod escalate to cluster-admin. Always run 'kubectl auth can-i --as=system:serviceaccount:<ns>:<sa> <verb> <resource>' after applying an RBAC change to confirm the effective permissions.
Every cluster has house rules that generic prompts do not know. Keep a short cluster-conventions.md in your platform repo listing: mandatory labels (app.kubernetes.io/name, app.kubernetes.io/part-of, team, cost-center), mandatory annotations (owner Slack channel, PagerDuty service), default resource requests for each workload class, allowed image registries, and forbidden fields (hostNetwork, hostPath volumes, privileged containers). Feed that document into the prompt as context.
For Helm charts, name your umbrella chart pattern and any shared library chart your team uses. For Kustomize, name your base/overlay layout. If you run Argo CD or Flux, note that so the model produces manifests that live in Git rather than 'kubectl apply' one-liners. If you have policy engines (Gatekeeper, Kyverno), share the constraints so generated YAML passes admission on the first try.
AI-generated Kubernetes YAML is a starting point, not a merge candidate. Treat every generated manifest the way you would treat a junior engineer's PR: read every field, question every default, run it through your policy engine, and apply it to staging before prod. A good workflow is prompt → save YAML to Git → kubeval or kubeconform → policy check (Gatekeeper/Kyverno in --dryrun) → kubectl apply --dry-run=server → apply to staging → observe metrics for 10 minutes → promote.
Keep a short prompt library in your platform repo (docs/k8s-prompts.md) with the prompts that consistently produce good output for your stack. When Kubernetes releases a new version and deprecates a field (as happened with PodSecurityPolicy, extensions/v1beta1 Ingress, and beta CRDs over the years), update the prompts to name the current stable APIs. The prompts that survive version churn are the ones that pin API versions explicitly and describe your ingress and CNI stack by name.
No. Always save the generated YAML to Git first, run kubectl apply --dry-run=server -f to catch schema errors, run it through your policy engine (Gatekeeper or Kyverno) in audit mode, apply it to a staging namespace, watch metrics and logs for at least a few minutes, and only then promote to prod through your normal GitOps flow (Argo CD, Flux) or CI pipeline. Blast radius on a bad Service selector or NetworkPolicy is measured in seconds.
Name your Kubernetes version in the prompt (EKS 1.30, GKE 1.29) so the model targets current APIs. Then run kubectl deprecations, Pluto, or kubent against the generated YAML before applying — these tools flag apps/v1beta1, extensions/v1beta1 Ingress, PodSecurityPolicy, and other removed APIs. For the ingress controller specifically, tell the model which controller (NGINX, ALB, GKE Gateway, Traefik) because annotations are controller-specific and change across major versions.
It can help, but only if you paste real evidence: kubectl describe pod, kubectl logs --previous (the previous container instance, since the current one may be terminated), and kubectl get events --sort-by=.lastTimestamp scoped to the namespace. Without those, the model guesses. With them, it can usually distinguish OOMKill from bad env config from failing liveness probe from missing ConfigMap. Always confirm the fix in staging before promoting.
Tell the model exactly what the workload needs to do — read ConfigMaps in its own namespace, patch its own Deployment status, list Pods for leader election — and reject any generated Role that uses wildcard verbs (*) or wildcard resources. After apply, run kubectl auth can-i --as=system:serviceaccount:<ns>:<sa> <verb> <resource> to enumerate what the SA can actually do. If the answer is more than you asked for, tighten the Role until it is not.
Read your organization AI tool policy first. Manifests may contain internal hostnames, container image tags that reveal architecture, and references to Secret names that leak product structure. Never paste actual Secret data (even base64-encoded — that is not encryption). For debugging, redact any customer-identifying info from logs and events before pasting. If your policy forbids external AI on infra config, run a local model or use your enterprise AI provider.