Generating production-ready Kubernetes manifests
Turn a service description into deployment, service, HPA, PDB and NetworkPolicy manifests that pass cluster admission policies.
Prompt
Generate Kubernetes manifests for a stateless HTTP service named {name} listening on port {port}. Include Deployment, Service, HorizontalPodAutoscaler, PodDisruptionBudget and a default-deny NetworkPolicy. Set resource requests and limits, readiness and liveness probes, a non-root securityContext and a read-only root filesystem. Output Kustomize base plus overlays for dev and prod.Problem
Teams copy manifests between services and inherit whatever was wrong with the original: missing probes, no limits, root containers.
Scenario
A new internal API needs to ship to a cluster that enforces Pod Security Admission `restricted` and requires NetworkPolicies.
Architecture
- Kustomize base with prod/dev overlays
- HPA on CPU with a conservative minimum replica count
- Default-deny egress with explicit allow rules
Why Bob?
Manifest boilerplate is high volume and low creativity. Generating it from a specification removes copy-paste drift while keeping the review in human hands.
Prompt
Use the prompt above and substitute {name} and {port}.Bob Workflow
- State the assumptions it is making about the cluster
- Emit the base, then the overlays
- Explain each securityContext field
Generated Result
A working base that passes `kubeconform` and the cluster's admission policy on first or second iteration.
Validation
- `kubectl apply --dry-run=server`
- `kubeconform -strict`
- Policy check with your admission controller in audit mode
Security
Check that no manifest mounts the service account token unless required, and that image tags are digests in prod overlays.
Lessons Learned
- Ask for the cluster constraints up front or you will get permissive defaults
- Resource limits need real profiling data — treat generated values as placeholders
Resources
- Kubernetes Pod Security Standards