ChatGPT on Pager Duty: Kubernetes and CI/CD Prompts That Survive Production
Every DevOps engineer knows the 2 a.m. feeling: a pod is in CrashLoopBackOff, the Helm release is stuck in pending-upgrade, and the pipeline failed on a step that worked yesterday. You do not need a chatbot that confidently writes latest into a Dockerfile. You need a prompt that produces a reviewable artifact — a manifest, a pipeline, a diagnosis — which you then check with kubectl diff or terraform plan before anything touches production. This roundup is built around exactly that principle: AI drafts, the human approves.
Below are ten prompts covering the daily routine — from Dockerfiles and Kubernetes manifests to GitHub Actions pipelines, Helm debugging, and log triage. Each comes with a usage example, the expected output, and the safety guardrail that keeps the change from reaching prod unreviewed.
1. Dockerfile with a pinned base and a build-stage split
What it removes: the blank-page problem when containerizing a new service.
You are a container build engineer. Write a multi-stage Dockerfile for a
Python 3.12 FastAPI app using requirements.txt. Requirements:
- pin the base image to a specific patch tag, never :latest
- run as a non-root user with a fixed UID
- copy requirements first, install, then copy source (layer caching)
- final image based on slim, no build tools left behind
- add a HEALTHCHECK hitting /health
Output the Dockerfile plus a short table: layer, why it exists.
Expected result: a two-stage Dockerfile of roughly 20 lines. Guardrail: run docker scout cves or trivy image on the build — pinning a tag does not mean the tag is patched.
2. Kubernetes Deployment with probes and resource limits
What it removes: hand-writing YAML and forgetting readinessProbe for the fifth time.
Generate a Kubernetes Deployment + Service for image registry.example.com/api:1.4.2
on port 8000. Include: 3 replicas, liveness and readiness probes on /health,
CPU/memory requests and limits, securityContext with runAsNonRoot and
readOnlyRootFilesystem, and a PodDisruptionBudget. Explain each field you add
that is not strictly required.
Expected result: deployment, service, and PDB manifests, plus a rationale list. Guardrail: always apply with kubectl diff -f manifest.yaml first — it shows the server-side diff before you commit.
3. Resource sizing from real usage, not vibes
What it removes: guessing at requests and limits.
Here is the output of `kubectl top pods -n payments` for the last hour [paste].
Suggest CPU/memory requests and limits for each pod using the rule: request =
peak usage rounded up, limit = 2x request. Flag any pod where the gap between
peak and average suggests a memory leak rather than normal load.
Expected result: a table with current usage, suggested request/limit, and a leak flag. Guardrail: kubectl top shows a snapshot, not a trend — cross-check with Prometheus container_memory_working_set_bytes over 7 days before resizing.
4. GitHub Actions pipeline with caching and least privilege
What it removes: copy-pasting a pipeline from a 2021 blog post.
Write a GitHub Actions workflow: on push to main, build the Docker image,
run tests, push to GHCR, then deploy to a staging namespace via kubectl.
Requirements: use actions/checkout@v4 and docker/build-push-action@v6,
cache the Go module download, set permissions: contents: read,
packages: write at job level, and store the kubeconfig in a secret.
Explain every permission you grant.
Expected result: a complete .github/workflows/deploy.yml. Guardrail: review the permissions: block manually — over-broad GITHUB_TOKEN scopes are a common supply-chain foothold. See the official docs at docs.github.com/en/actions/security-guides.
5. Debugging a Helm release stuck in pending-upgrade
What it removes: the trial-and-error of Helm troubleshooting.
My Helm release is stuck: `helm status api` shows STATUS: pending-upgrade
since 40 minutes ago. Here is `helm history api` [paste] and the error from
`kubectl describe job api-migrate` [paste]. Walk me through the diagnosis
step by step, and give me the exact commands to either roll back safely or
force-clear the stuck release. Warn me about what data I could lose.
Expected result: a decision tree ending in helm rollback api <revision> or a documented --force path. Guardrail: helm rollback does not undo database migrations — confirm the migrate Job is idempotent before rolling back.
6. Triaging a crashing pod from logs
What it removes: scrolling through 5000 lines of stack trace at 3 a.m.
This pod is in CrashLoopBackOff. Here are the last 100 lines of
`kubectl logs api-7d9f --previous` [paste] and `kubectl describe pod` [paste].
Identify the root cause, rank the three most likely fixes, and tell me which
single command to run next to confirm. Do not suggest restarting the pod —
it will crash again.
Expected result: a ranked hypothesis list with a confirming command. Guardrail: --previous gives logs from the crashed container — without it you may be looking at an empty current run.
7. Terraform change review before apply
What it removes: the anxiety of reading a 400-line plan diff.
Here is `terraform plan` output [paste]. Summarize what will be destroyed,
recreated, or modified in place. Flag anything marked "must be replaced"
that holds state (databases, buckets, DNS zones). For each destructive
change, propose a safer alternative (e.g. create_before_destroy, moved blocks).
Expected result: a change summary table with risk flags. Guardrail: never run terraform apply on AI output — the plan is the source of truth, and moved blocks must be verified against actual resource addresses.
8. Writing a runbook from a real incident
What it removes: the post-incident ritual of writing docs nobody reads.
Here is the timeline of yesterday's incident [paste Slack thread]. Write a
runbook section titled 'API latency spike' with: symptoms, first 5 diagnostic
commands, escalation path, and rollback procedure. Keep it under 400 words,
use imperative mood, and mark every step that requires production access.
Expected result: a runbook a junior can follow under pressure. Guardrail: have an on-call engineer dry-run each command in staging before publishing.
9. Auditing a manifest for security gaps
What it removes: manual review against CIS benchmarks.
Review this Deployment manifest [paste] against the Kubernetes Pod Security
Standards (restricted profile). List every violation with the exact field and
a corrected snippet. Do not rewrite the whole file — show only the diffs.
Expected result: a violation table mapped to the official PSS controls (kubernetes.io/docs/concepts/security/pod-security-standards). Guardrail: PSS is enforced by the API server via namespace labels — verify your cluster actually enforces restricted before assuming a manifest passes.
10. Translating a ticket into a CI/CD change
What it removes: the gap between a product request and pipeline edits.
Ticket: 'Deploy preview environments for each pull request.'
Propose a GitHub Actions design: trigger on pull_request, spin up a
namespaced ephemeral environment, comment the URL on the PR, tear down on
close. Output the workflow skeleton, the namespace naming convention, and
the cleanup job. Flag cost and secret-management risks.
Expected result: a workflow skeleton plus a risk list. Guardrail: ephemeral namespaces leak cloud spend — always pair with a scheduled cleanup and a ttl label.
The pattern that keeps prod alive
Notice what every prompt above shares: it asks for a reviewable artifact and an explanation, never for blind execution. ChatGPT is excellent at the shape of a Dockerfile, the skeleton of a pipeline, the first draft of a runbook. It is not the thing that should hold the kubeconfig. Use kubectl diff, terraform plan, and helm template as your review gates, and treat every AI output as a pull request from a fast but overconfident colleague.
Start with one prompt — the crashing-pod triage is a good first candidate — and keep it in a team snippet library. The routine it removes is real; the review step is what makes the routine safe to remove.
Comments