Kubernetes, Docker and a Chat Window: The Prompts That Keep Me From Wrecking Prod on Deploy Day
Every DevOps engineer knows the feeling: it's 23:40, you push a tag, the pipeline goes green, and then the rollout stalls because a liveness probe has the wrong path, or the image is 1.4 GB and the node is OOM-killing your pod. The documentation exists. You just don't have the patience to read forty pages of YAML reference while the on-call phone is buzzing.
This is where a well-shaped prompt beats a Stack Overflow tab. Not a vague "write me a Dockerfile" — that gives you a generic FROM node:latest monstrosity. A battle-tested prompt that pins the model to a role, gives it your constraints, and forces it to output something you can paste into kubectl apply --dry-run=server.
Below are ten prompts I actually use, with real examples, real commands, and real gotchas. The theme is simple: problem → prompt → result. Every code snippet is valid for Kubernetes 1.29+ (the container runtime is containerd since 1.24, so docker commands on nodes are gone — use crictl instead). Every YAML field is real. Nothing here will magically run your cluster, but it will cut the time between "it broke" and "it's fixed."
1. The Dockerfile Diet: Cutting Image Size Without Breaking the Build
Problem: a Spring Boot image at 900 MB, slow pulls, and a fat attack surface.
Prompt:
You are a container security engineer. Rewrite this Dockerfile using a multi-stage build
with a distroless or slim runtime, non-root user, pinned base image digest, and .dockerignore.
Constraints: Java 21, Maven build, target image < 250 MB. Explain each layer's purpose.
Output: Dockerfile + .dockerignore + a one-line command to verify size and user.
Example result (real, working):
FROM maven:3.9-eclipse-temurin-21 AS build
WORKDIR /app
COPY pom.xml .
RUN mvn -B dependency:go-offline
COPY src ./src
RUN mvn -B package -DskipTests
FROM gcr.io/distroless/java21-debian12:nonroot
COPY --from=build /app/target/*.jar /app/app.jar
USER nonroot
ENTRYPOINT ["java","-jar","/app/app.jar"]
Verify: docker image inspect <img> --format '{{.Size}}' and docker run --rm <img> id. Distroless has no shell, so id won't work — check the USER directive instead. That's the kind of nuance the model should flag if you ask it to.
2. The "Explain This YAML Like I'm On-Call" Prompt
Problem: you inherited a 600-line Helm-rendered manifest and need to know what happens on kubectl delete pod.
Prompt:
Act as a Kubernetes SRE. Given this manifest, answer in a table:
(a) what happens on pod deletion, (b) which fields control it (terminationGracePeriodSeconds,
preStop hooks, readinessProbe), (c) what can cause a 30s+ outage, (d) the exact kubectl command
to test each hypothesis. No generic advice — reference the actual fields present.
Why it works: it forbids hand-waving. You get a table mapping terminationGracePeriodSeconds: 60 and a missing preStop hook to a concrete drain delay — and the fix (kubectl rollout restart deploy/x followed by kubectl get pods -w).
3. Building a kubectl Cheat-Sheet for a Specific Incident
Problem: CrashLoopBackOff, and you can't remember the order of debugging commands.
Prompt:
Give me a step-by-step kubectl debugging sequence for CrashLoopBackOff in namespace prod,
from cheapest to most expensive command. For each step: the command, what to look for,
and the decision rule (if X then Y). Use kubectl logs --previous, kubectl describe,
kubectl get events --sort-by=.lastTimestamp, kubectl debug with an ephemeral container.
The model reliably produces the canonical ladder:
kubectl get pods -n prod
kubectl describe pod <pod> -n prod
kubectl logs <pod> -n prod --previous --tail=100
kubectl get events -n prod --sort-by=.lastTimestamp | tail -20
kubectl debug -it <pod> -n prod --image=busybox --target=<container> -- sh
That last one is the real win: kubectl debug with --target shares the process namespace, so you can inspect a distroless container without rebuilding it.
4. Resource Requests and Limits: The Right-Sizing Prompt
Problem: every deployment has requests: 100m / 128Mi copy-pasted, and the cluster is 40% wasted.
Prompt:
I'll paste 7 days of `kubectl top pod` output. Compute P50 and P95 CPU/memory per container,
recommend requests = ceil(P95), limits = 2x requests, and flag any container where
limit/request ratio > 3. Output a YAML patch and a table of before/after.
Feed it the CSV from kubectl top pod -n prod --containers. The model does the arithmetic and hands you a kubectl patch or a resources: block. Caveat: kubectl top needs metrics-server; without it, use kubectl get --raw /apis/metrics.k8s.io/v1beta1/namespaces/prod/pods.
5. The CI/CD Pipeline Prompt (GitHub Actions, Real Syntax)
Problem: you want build → scan → push → deploy with rollback, but writing it from scratch is an hour of YAML archaeology.
Prompt:
Write a GitHub Actions workflow: build a Docker image, scan with Trivy (fail on HIGH/CRITICAL),
push to GHCR with SHA tag, deploy to Kubernetes via `kubectl set image`, wait for rollout,
and auto-rollback with `kubectl rollout undo` on failure. Use only official actions and
GITHUB_TOKEN. Include a concurrency group so deploys don't overlap.
Key lines you should expect (and verify):
concurrency:
group: deploy-prod
cancel-in-progress: false
jobs:
deploy:
steps:
- run: kubectl set image deploy/app app=ghcr.io/org/app:${{ github.sha }}
- run: kubectl rollout status deploy/app --timeout=120s || kubectl rollout undo deploy/app
cancel-in-progress: false is the detail that saves you: a cancelled mid-rollout deploy is a classic way to leave a cluster in a half-updated state.
6. Docker Compose for Local Dev That Mirrors Prod
Problem: docker compose up works on your laptop, fails in staging because of missing healthchecks and env vars.
Prompt:
Convert this docker-compose.yml to production-parity local dev: add healthchecks for postgres
and redis, depends_on with condition: service_healthy, named volumes, .env file, and
resource limits. Explain every depends_on condition.
Compose v2 supports depends_on: { db: { condition: service_healthy } } — a real field since the Compose Spec. The model will add pg_isready for Postgres and redis-cli ping for Redis. That alone kills 80% of "connection refused on startup" bugs.
7. The "Don't Break Prod" Pre-Deploy Checklist
Problem: deploys at Friday 5pm because nobody formalized the gate.
Prompt:
Generate a pre-deploy checklist for a Kubernetes service with HPA, PDB, and an Ingress.
Group by: manifests, secrets, observability, rollback. For each item give the kubectl
command that verifies it. Include PDB check (minAvailable vs replicas), HPA target check,
and readinessProbe alignment with the service port.
You get items like kubectl get pdb -n prod and the rule: minAvailable: 2 with replicas: 3 means a rolling update can only take one pod at a time — if maxSurge is 0, you deadlock. That's the kind of silent trap a checklist catches and a tired engineer doesn't.
8. Debugging a Failed Rollout With the Model as a Rubber Duck
Problem: kubectl rollout status times out; you have logs, events, and a deadline.
Prompt:
Here are: deployment spec, last 50 event lines, pod describe output, and app logs.
Do not guess. List hypotheses ranked by likelihood, each with the kubectl command that
confirms or rejects it. Then give the single most likely root cause and the fix command.
This is the highest-leverage prompt in the set because it forces falsifiable reasoning instead of a confident hallucination. If the model says "image pull secret missing," the confirming command is kubectl get events --field-selector reason=Failed — you check, you know.
9. Turning a Postmortem Into a Runbook
Problem: incident resolved, knowledge lost in Slack.
Prompt:
Turn this incident timeline into a runbook: symptoms, detection query (PromQL or kubectl),
mitigation steps, root cause, prevention. Keep it under one page. Use imperative mood.
Output becomes the doc nobody writes but everybody needs. Pair it with a PromQL alert like rate(container_cpu_usage_seconds_total[5m]) to catch the next occurrence.
10. The Security Review Prompt for Manifests
Problem: securityContext is empty everywhere; runAsRoot is the default.
Prompt:
Audit this manifest against CIS Kubernetes Benchmark and Pod Security Standards (restricted).
List violations, the exact YAML to fix each, and the kubectl command to verify.
Flag: runAsNonRoot, readOnlyRootFilesystem, allowPrivilegeEscalation, capabilities drop ALL,
seccompProfile RuntimeDefault.
The restricted profile requires seccompProfile.type: RuntimeDefault and allowPrivilegeEscalation: false — both real, both frequently missing. Ask for kubectl label ns prod pod-security.kubernetes.io/enforce=restricted to test enforcement in a staging namespace first.
The Takeaway
None of these prompts replace understanding Kubernetes — they compress the distance between a problem and a verified fix. The pattern is consistent: assign a role, state hard constraints, demand commands you can actually run, and forbid guessing. The model is a fast, tireless reviewer; the cluster is the source of truth. Keep --dry-run=server in your muscle memory, keep rollback one command away, and never let a Friday afternoon deploy be the first time your checklist runs.
If you want to go deeper on the underlying primitives — probes, PDBs, HPA, Pod Security Standards — the official docs at kubernetes.io and the CIS Benchmark remain the reference. Use AI to get there faster, not to skip the reading entirely.
Comments