Docker and Kubernetes Without the Docs Marathon: 14 Prompts That Turn YAML Chaos Into a Working Deploy

Docker and Kubernetes Without the Docs Marathon: 14 Prompts That Turn YAML Chaos Into a Working Deploy

Every DevOps engineer knows the ritual: a CrashLoopBackOff at 2 a.m., three browser tabs with Kubernetes docs, a Stack Overflow thread from 2019, and a docker-compose.yml that worked on your laptop but dies in staging. The infrastructure is not hard because the concepts are hard — it is hard because the surface area is enormous. Dockerfiles, Compose files, Deployments, Services, Ingress, Helm values, GitHub Actions matrices, caching layers, resource limits, probes.

A well-aimed prompt collapses that surface area. Not "explain Kubernetes to me" — that gives you a blog post. But "here is my Dockerfile, my build log, and my base image; find why the image is 1.4 GB and rewrite it" gives you a diff you can ship. The difference is context: the model needs your actual files, your actual errors, and a constraint on the output format.

Below are 14 prompts I actually reuse, each with a real usage example. They are written for ChatGPT, Claude, or any competent LLM. Copy them, adapt the placeholders, and stop reading docs at 2 a.m. For Dockerfile and Compose basics there is a separate deep dive on this blog; here the focus is the full path from container to cluster to pipeline — and the debugging that eats your week.

1. The Dockerfile Autopsy

Task: turn a working-but-bloated Dockerfile into a small, cached, non-root image.

You are a senior container engineer. Here is my Dockerfile and the output of
`docker images` for the built image. Rewrite it to: (1) use a multi-stage build,
(2) order layers for maximum cache reuse, (3) run as a non-root user,
(4) pin the base image by digest. After the code, list each change and the
estimated size/security impact. Do not change the application's runtime behavior.

Dockerfile:
<paste>
Image size: <paste>

Why it works: the "list each change" clause turns the answer into a reviewable PR description instead of a black-box rewrite. Pinning by digest (FROM node:20-alpine@sha256:...) is a real supply-chain hardening step — the tag can be repointed, the digest cannot.

2. Compose File That Actually Starts

Task: fix docker-compose up failures caused by ordering, health, and networking.

My `docker compose up` fails with the error below. Here is compose.yaml.
Diagnose the root cause, then return a corrected file using `depends_on` with
`condition: service_healthy`, healthchecks, and named volumes. Explain why
each fix is needed in one line.

Error: <paste full stderr>
compose.yaml: <paste>

Why it works: the plain depends_on only waits for the container to start, not to be ready — a classic reason an app crashes because Postgres is still initializing. The condition: service_healthy form (Compose spec) is the real fix, and naming it forces the model to use it.

3. Dockerfile Lint in Plain English

Task: understand what Hadolint is complaining about without reading its wiki.

Here is Hadolint output for my Dockerfile. For each rule (DLxxxx), explain in
one sentence what it means and give the corrected line. Group by severity.

<hadolint output>

Hadolint is the de-facto Dockerfile linter; its rule codes (e.g. DL3008 — pin apt package versions) are stable and documented. This prompt converts a wall of warnings into a checklist you can actually action.

4. Manifest Generator With Guardrails

Task: generate a Deployment + Service + Ingress that will not get rejected by the API server.

Generate Kubernetes manifests for a stateless web app: image <img:tag>,
3 replicas, port 8080, CPU request 100m / limit 500m, memory 128Mi/256Mi,
liveness and readiness probes on /healthz, exposed via Ingress at <host>.
Target Kubernetes 1.29. Include resource requests/limits, securityContext with
runAsNonRoot, and a PodDisruptionBudget. Output valid YAML only.

Why it works: specifying the API version matters — autoscaling/v2, policy/v1 for PDB, and networking.k8s.io/v1 Ingress all differ from older tutorials you will find online. Asking for runAsNonRoot and a PDB up front bakes in production hygiene.

5. Decode a CrashLoopBackOff

Task: go from kubectl describe + logs to a ranked hypothesis list.

Pod is in CrashLoopBackOff. Here are `kubectl describe pod` (events section),
`kubectl logs --previous`, and the relevant container spec. Give the 3 most
likely causes ranked by probability, and for each the exact kubectl command to
confirm or rule it out. Do not guess — if info is missing, say what to collect.

<outputs>

Why it works: the "do not guess" clause is critical. LLMs love to invent causes; forcing them to name a diagnostic command keeps them honest. --previous is the flag that shows logs from the crashed container instance — a detail many forget.

6. Explain a YAML Diff Before You Apply

Task: understand what helm diff or kubectl diff will actually change.

Here is the diff between the live cluster state and what I'm about to apply.
Summarize the blast radius: what restarts, what gets recreated, what could
cause downtime. Flag anything that changes a Service selector or a PVC.

<diff output>

A Service selector change silently orphans pods; a PVC change can trigger data loss. Asking specifically for those two is the difference between a safe rollout and an incident.

7. CI/CD Pipeline From a Requirements List

Task: generate a GitHub Actions workflow instead of assembling it from snippets.

Write a GitHub Actions workflow for a Node.js app: on push to main and PRs;
jobs: lint, test (matrix Node 18/20), build Docker image, push to GHCR with
commit SHA tag, then deploy via kubectl. Use actions/cache for npm, pin every
action to a major version, use OIDC-friendly permissions block. Explain the
trigger logic.

Why it works: naming actions/cache and the permissions: block prevents the two most common workflow mistakes — slow runs and over-broad GITHUB_TOKEN scopes. Pinning actions to a major version (@v4) is the minimum supply-chain precaution.

8. Debug a Failing Pipeline Step

Task: read the raw CI log and find the real error.

My GitHub Actions job fails. Here is the failing step's log (last 100 lines).
Identify the actual error (ignore noise), explain the root cause, and give a
corrected step. If it's a permissions or secrets issue, say which scope/secret
is missing.

<log>

CI logs are 90% noise. The model is good at cutting to the line that matters — a missing permissions: packages: write, an unset secret, or a cache-key mismatch.

9. Image Size Forensics

Task: find what is fattening your image.

My image is 1.2 GB. Here is `docker history --no-trunc <image>`. Identify the
layers eating the most space and propose a multi-stage rewrite that drops
build tooling from the final image. Show the before/after layer table.

docker history exposes per-layer size — the fastest way to find the culprit (usually build tools, caches, or an unpinned latest base). The before/after table makes the win visible in a PR.

10. Resource Requests and Limits Advisor

Task: right-size CPU/memory from real usage.

Here is `kubectl top pod` output for my app over a typical load period.
Recommend CPU/memory requests and limits per container. Explain the
relationship between requests, limits, and QoS class (Guaranteed/Burstable/
BestEffort), and what happens on node pressure for each.

<top output>

Setting requests = limits gives Guaranteed QoS — the last to be evicted under memory pressure. The prompt forces the model to justify numbers against a real QoS tradeoff instead of guessing round figures.

11. Translate a Helm Values File

Task: understand what a chart's values.yaml overrides actually do.

Here is the values.yaml I'm overriding and the chart's default values.
For each key I changed, explain the effect on the resulting Deployment/Service.
Flag any override that would disable a probe, remove resource limits, or
change the Service type.

Helm overrides are where production guards quietly disappear. The explicit "flag if it removes limits/probes" clause catches the override that sets resources: {} and leaves your pods BestEffort.

12. NetworkPolicy From a Sentence

Task: write a default-deny policy with the minimum allow rules.

Write a Kubernetes NetworkPolicy set for namespace `app`: default-deny all
ingress/egress, then allow ingress to pods labeled app=web on port 8080 from
ingress-nginx, and egress to DNS (kube-system, port 53) and to a Postgres
Service on 5432. Output YAML, note which CNI plugins enforce egress.

Why it works: DNS egress is the rule everyone forgets — a default-deny policy that blocks port 53 breaks name resolution and looks like a mysterious timeout. Mentioning CNI enforcement matters: not every plugin enforces NetworkPolicy.

13. Rollback Plan Generator

Task: know how to undo a deploy before you run it.

I'm about to deploy image <tag> to a 3-replica Deployment via `kubectl set image`.
Give me a rollback plan: exact commands, how to verify success (readiness,
error rate), and the difference between `kubectl rollout undo` and redeploying
a previous image tag. Note what `kubectl rollout status` shows.

kubectl rollout undo reverts to the previous ReplicaSet revision; redeploying a tag is explicit and survives history pruning. Knowing the difference before the incident is the whole point.

14. The "Explain My Infra" Onboarding Prompt

Task: turn a repo of manifests into a human-readable architecture summary for a new teammate.

Here are the Kubernetes manifests and compose files from our repo. Produce a
one-page architecture summary: services, how they talk, external entry points,
stateful components and their volumes, and the 3 riskiest spots. Write for a
new engineer on day one.

This is the prompt that saves the most hours over a year — every new hire, every handover, every "what does this cluster even do" moment.

What Ties These Together

The One Habit That Makes All of This Work

Every prompt above shares one property: it hands the model real artifacts — a log, a diff, a docker history table — and constrains the output format. "Explain Kubernetes" produces a blog post; "here is my describe output, rank three causes, give me the confirming command" produces a fix. The model is a fast, tireless reader of the exact thing you are too tired to parse at 2 a.m. — not an oracle.

Start with prompt 5 the next time a pod refuses to start, and prompt 14 on your next Monday. Keep the ones that pay off, delete the rest, and always verify the generated YAML against a real cluster with kubectl apply --dry-run=server before it touches production. The docs are still there — you just stop reading them cover to cover.