What this prompt does
This prompt frames the AI as a senior platform engineer that produces production-grade Kubernetes manifests as working YAML that applies cleanly with kubectl and kustomize, not pseudocode. You supply the [service_name], the container [image], the [environments] to overlay, and the [traffic_profile]. It returns a Deployment with resource requests and limits, liveness and readiness probes, and graceful shutdown; a ClusterIP Service plus Ingress with TLS; an HPA driven by CPU and one custom metric sized for the traffic profile; a PodDisruptionBudget and a NetworkPolicy; a ServiceAccount with least-privilege RBAC; and a kustomize base with overlays for each environment.
The structure works because it includes the parts copy-paste manifests usually skip: disruption budgets, network policy, and real probes, which are what keep a service alive through node drains and rolling updates instead of dropping traffic. [image] and [service_name] populate the Deployment and naming so the manifests reference what you actually run. [traffic_profile] sizes the HPA, so a bursty high-rps workload gets different scaling thresholds than a steady one. [environments] drives the overlays, parameterising replicas, limits, and host per environment so dev, staging, and prod diverge cleanly from a single shared base rather than living as three drifting copies.
When to use it
- You need manifests that survive node drains and rolling updates, not toy examples.
- You want PodDisruptionBudget and NetworkPolicy included by default.
- You need per-environment overlays for replicas, limits, and host.
- You want an HPA sized to your actual traffic shape.
- You need least-privilege RBAC instead of a default service account.
- You are deploying a stateless service and want a solid manifest baseline.
Example output
You get a kustomize directory tree with the base manifests (a Deployment with resource requests and limits, liveness and readiness probes, and graceful shutdown, a ClusterIP Service, an Ingress with TLS, an HPA, a PodDisruptionBudget, a NetworkPolicy, and a least-privilege ServiceAccount and RBAC) plus one example overlay parameterising replicas, limits, and host. The YAML is meant to apply cleanly with kubectl and kustomize, so it is structured as real files you can lay down and build on rather than conceptual snippets.
Pro tips
- Set
[traffic_profile]realistically; it sizes the HPA thresholds and behaviour. - List your real
[environments]so the overlays parameterise the right values per stage. - Use the exact
[image]reference so the Deployment pulls what you intend. - Tune the liveness probe carefully; too-aggressive checks restart healthy pods under load.
- Keep the PodDisruptionBudget and NetworkPolicy; they are what blog-copied manifests omit and what keeps the service serving during node drains.
- Review the RBAC to confirm the ServiceAccount grants only the permissions the service actually needs, not a broad default role.
- Run kustomize build and a dry-run apply per overlay before trusting it against a real cluster.
