What this prompt does
This prompt generates production-ready Kubernetes manifests to deploy [app_name] to a [cluster_type] cluster. The Deployment runs [replica_count] replicas with a rolling update strategy of maxSurge 1 and maxUnavailable 0, resource requests and limits of [resource_spec], and pod anti-affinity to spread pods across nodes. The maxUnavailable 0 setting is what keeps deploys boring in the best way, since a new pod becomes ready before an old one goes away.
The structure works because it covers the full set of objects a real deployment needs rather than just a bare Deployment. The container spec uses [image_registry]/[app_name]:[tag_strategy] with a liveness probe hitting [health_endpoint] after a [startup_delay] initial delay and a readiness probe on the same endpoint at 5-second intervals. It adds a ClusterIP Service mapping [service_port] to [container_port], an [ingress_controller] Ingress with TLS termination for [domain], a ConfigMap externalizing [config_values], and a Secret referencing [secrets] from [secret_store] instead of hardcoding them. It also defines a HorizontalPodAutoscaler scaling between [min_replicas] and [max_replicas] on CPU and memory, and a PodDisruptionBudget keeping at least [min_available] pods during node maintenance. Wiring liveness and readiness probes correctly is what turns a flaky rollout into a predictable one.
When to use it
- You are deploying a service to Kubernetes and want a complete, production-shaped manifest set.
- You want zero-downtime rolling updates with maxUnavailable 0.
- You need correctly separated liveness and readiness probes.
- You want autoscaling and a disruption budget for node maintenance.
- You want config and secrets externalized rather than baked into the image.
- You need an Ingress with TLS termination for a real domain.
Example output
Expect a deployable bundle of YAML manifests. You get a Deployment with rolling-update and anti-affinity settings, a container spec with both probes, a ClusterIP Service, an Ingress with TLS for [domain], a ConfigMap for [config_values], and a Secret referencing [secrets] via [secret_store]. It also includes a HorizontalPodAutoscaler with your replica bounds and a PodDisruptionBudget, so together they form a production-shaped set you can apply to the cluster and then tune against real metrics rather than starting from a blank file.
Pro tips
- Use an immutable
[tag_strategy]like a git SHA rather than latest, so rollbacks and rollouts stay deterministic. - Tune
[startup_delay]to your app's real boot time, since too short a delay lets the liveness probe kill pods mid-startup. - Keep liveness and readiness as separate concerns, since readiness gates traffic while liveness restarts, and conflating them causes flaky rollouts.
- Set
[resource_spec]from observed usage rather than guesses, because limits that are too tight trigger OOM kills under load. - Reference
[secrets]from[secret_store]instead of hardcoding, and keep them out of the ConfigMap entirely. - Make sure
[min_available]in the PodDisruptionBudget is compatible with[replica_count], or node drains can stall indefinitely.
