12 Prompts for Kubernetes: Manifests, Helm, and Deployment Automation
Kubernetes (K8s) has become the de facto orchestration platform for containerized applications, but writing correct YAML manifests, configuring Helm charts, and troubleshooting deployments can still feel like a black art. According to the 2023 CNCF Annual Survey (cncf.io/reports), 96% of organizations use Kubernetes in some form, yet 63% of developers report that writing and debugging Kubernetes manifests is their biggest productivity bottleneck. This collection of 12 ready-to-use prompts will help you generate production-grade Pod definitions, Services, Ingress rules, and Helm charts—plus guide you through common deployment pitfalls.
Each prompt is designed to be copy-pasted into an AI assistant (e.g., ChatGPT, Claude, or a local LLM) and then adapted to your specific project. You will get the exact task description, a concrete usage example, and best-practice notes based on official Kubernetes documentation (kubernetes.io/docs) and the Helm documentation (helm.sh/docs).
1. Pod Manifest with Resource Limits and Health Checks
Task: Generate a minimal but production-ready Pod YAML that includes CPU/memory resource requests and limits, plus liveness and readiness probes.
Prompt:
Create a Kubernetes Pod manifest for an Nginx container with:
- Container name: web-server
- Image: nginx:1.25-alpine
- Resource requests: 128Mi memory, 100m CPU
- Resource limits: 256Mi memory, 250m CPU
- Liveness probe: HTTP GET /health on port 80, initial delay 5s, period 10s
- Readiness probe: HTTP GET /ready on port 80, initial delay 3s, period 5s
- Labels: app=web, env=staging
Usage example: Save the output as pod-nginx.yaml and apply with kubectl apply -f pod-nginx.yaml. Check probes with kubectl describe pod <pod-name>. According to the official Kubernetes documentation (kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/), setting both probes prevents traffic routing before the container is ready and avoids cascading failures.
2. Multi-Container Pod with Init Container
Task: Generate a Pod that runs an init container to wait for a database, then starts the main application container.
Prompt:
Write a Kubernetes Pod manifest with:
- Init container named "init-db" using busybox:1.36, runs command: "until nc -z db-service 5432; do echo waiting for db; sleep 2; done"
- Main container named "app" using your-image:latest, listens on port 8080
- Both containers share an emptyDir volume at /data
- Add a PostStart lifecycle hook that creates a file /data/started
Usage example: This pattern is commonly used for applications that require a database to be ready before starting. The init container runs to completion, then the main container starts. The emptyDir volume allows sharing small data (like config files) between init and main containers. Test the lifecycle hook by exec-ing into the container: kubectl exec <pod-name> -- ls /data.
3. ClusterIP Service Exposing Multiple Ports
Task: Create a Service that exposes two ports from the same application container—one for HTTP, one for metrics.
Prompt:
Generate a Kubernetes Service manifest of type ClusterIP named "my-app-svc" that:
- Selects pods with label app=my-app
- Exposes port 80 targeting container port 8080 (name: http)
- Exposes port 9090 targeting container port 9090 (name: metrics)
- Uses protocol TCP for both
Usage example: Apply the manifest, then verify with kubectl get svc my-app-svc. This setup is typical for applications like Prometheus exporters that expose metrics on a separate port. According to the Kubernetes networking documentation (kubernetes.io/docs/concepts/services-networking/service/#defining-a-service), multiple ports require a name for each port, which must be a valid DNS label.
4. NodePort Service for External Access (Development)
Task: Generate a NodePort Service that exposes a web application on a static port across all cluster nodes.
Prompt:
Create a Kubernetes Service of type NodePort named "frontend-svc" with:
- Selector: app=frontend, tier=web
- Port 80 -> target port 3000
- nodePort: 30080 (static)
- Session affinity: ClientIP
Usage example: Apply and access via http://<any-node-ip>:30080. NodePort is not recommended for production because it exposes the service on every node, bypassing typical load balancers. Use it for local testing or when a LoadBalancer is unavailable. The session affinity setting ensures that a client’s requests always go to the same pod—useful for stateful applications.
5. Ingress with TLS Termination and Path-Based Routing
Task: Write an Ingress resource that routes traffic to two different backend services based on URL path, with HTTPS enabled.
Prompt:
Generate a Kubernetes Ingress manifest (networking.k8s.io/v1) named "main-ingress" that:
- Uses annotation nginx.ingress.kubernetes.io/rewrite-target: /
- Host: example.com
- Path /api/* routes to service "api-svc" on port 8080
- Path /* routes to service "web-svc" on port 80
- TLS with secret name "example-tls"
Usage example: Before applying, ensure you have an ingress controller installed (e.g., nginx-ingress). Create the TLS secret with kubectl create secret tls example-tls --cert=cert.crt --key=key.key. The rewrite-target annotation strips the path prefix before forwarding to the backend. According to the Kubernetes Ingress documentation (kubernetes.io/docs/concepts/services-networking/ingress/), path types can be either Prefix or Exact—choose Prefix for /api/* routing.
6. ConfigMap and Secret Injected as Environment Variables
Task: Generate a Pod that reads configuration from a ConfigMap and sensitive data from a Secret, both as environment variables.
Prompt:
Create a Kubernetes Pod manifest that:
- Uses container image alpine:3.18
- Injects ConfigMap "app-config" with keys DB_HOST, DB_PORT as env vars
- Injects Secret "db-credentials" with keys DB_USER, DB_PASSWORD as env vars
- Prints all env vars on startup using command: ["env"]
Usage example: First create ConfigMap and Secret:
kubectl create configmap app-config --from-literal=DB_HOST=localhost --from-literal=DB_PORT=5432
kubectl create secret generic db-credentials --from-literal=DB_USER=admin --from-literal=DB_PASSWORD=s3cret
Apply the Pod, then check logs with kubectl logs <pod-name> to see the environment variables. Note that Secrets are base64-encoded only—not encrypted—so enable encryption at rest (etcd encryption) in production.
7. HorizontalPodAutoscaler Based on CPU and Memory
Task: Write an HPA that automatically scales a Deployment based on average CPU and memory utilization.
Prompt:
Generate a HorizontalPodAutoscaler (autoscaling/v2) named "app-hpa" that:
- Targets Deployment "my-app-deployment"
- Min replicas: 2, Max replicas: 10
- Average CPU utilization: 70%
- Average memory utilization: 80%
- Scale-down stabilization window: 120 seconds
Usage example: Apply after the Deployment exists. The HPA requires metrics-server to be installed in the cluster (github.com/kubernetes-sigs/metrics-server). Test by generating load with a tool like kubectl run load-generator --image=busybox -- /bin/sh -c "while true; do wget -q -O- http://my-app-svc; done". Watch scaling with kubectl get hpa -w.
8. Helm Chart Skeleton with Values and Templates
Task: Generate a basic Helm chart skeleton (Chart.yaml, values.yaml, and a simple Deployment template) for a microservice.
Prompt:
Create a Helm chart directory structure "my-microservice" with:
- Chart.yaml: apiVersion v2, name my-microservice, version 0.1.0
- values.yaml with: replicaCount: 2, image.repository: nginx, image.tag: alpine, service.port: 80
- templates/deployment.yaml: a Deployment that uses values from values.yaml, with labels app: {{ .Chart.Name }}
- templates/service.yaml: a ClusterIP Service exposing port {{ .Values.service.port }}
Usage example: Create the directory, paste each file, then run helm install my-release ./my-microservice. Override values with helm install my-release ./my-microservice --set image.tag=latest. According to Helm best practices (helm.sh/docs/chart_best_practices/), always use the {{ .Release.Name }} prefix for resource names to avoid conflicts when installing the same chart multiple times in one namespace.
9. Helm Template with Conditionals and Loop
Task: Extend the Helm chart to conditionally create an Ingress and loop over multiple environment variables from a list.
Prompt:
Extend the Helm chart from prompt 8:
- In templates/ingress.yaml: create Ingress only if {{ .Values.ingress.enabled }} is true, with host {{ .Values.ingress.host }}
- In templates/configmap.yaml: create a ConfigMap with key-value pairs from {{ .Values.envVars }} (a list of objects with name and value keys)
- Use a range loop: {{- range .Values.envVars }}
Usage example: Add to values.yaml:
ingress:
enabled: true
host: example.com
envVars:
- name: LOG_LEVEL
value: debug
- name: NODE_ENV
value: production
Run helm template my-release ./my-microservice to see the rendered YAML without installing. This is invaluable for debugging complex templates.
10. Helm Values Validation and Schema
Task: Create a values.schema.json file to validate user-provided values before installation.
Prompt:
Write a JSON Schema file values.schema.json for a Helm chart that validates:
- replicaCount must be integer >= 1
- image.repository must be string, not null
- image.tag must be string
- ingress.enabled must be boolean
- envVars array items must have name (string) and value (string)
Usage example: Place the file in the chart root. When a user runs helm install with invalid values (e.g., replicaCount="five"), Helm will reject it with a clear error message. Helm uses JSON Schema draft-07 (helm.sh/docs/topics/values_schema/). This reduces deployment failures caused by misconfigured values.
11. Rolling Update Deployment with Strategy and Rollback
Task: Generate a Deployment manifest with a rolling update strategy, including maxSurge and maxUnavailable settings.
Prompt:
Write a Kubernetes Deployment manifest for "api-server" with:
- 3 replicas
- Rolling update strategy: maxSurge=25%, maxUnavailable=25%
- Container image: my-api:2.0, port 3000
- Liveness and readiness probes on /health (HTTP, port 3000)
- Update the image to my-api:2.1 using kubectl set image
Usage example: Apply the Deployment, then update the image: kubectl set image deployment/api-server api-server=my-api:2.1. Monitor the rollout with kubectl rollout status deployment/api-server. If something goes wrong, roll back with kubectl rollout undo deployment/api-server. The maxSurge=25% means one additional pod (25% of 3 = 0.75, rounded up to 1) can be created during the update, while maxUnavailable=25% allows one pod to be unavailable.
12. Troubleshooting: Pod Status, Logs, and Events
Task: Write a series of kubectl commands to diagnose a failing Pod, then ask the AI to explain the output.
Prompt:
I have a Pod named "my-pod" that is stuck in CrashLoopBackOff. Generate a sequence of kubectl commands to:
1. Check the Pod status and recent events
2. View the last 100 lines of logs
3. Describe the Pod to see resource limits and probe configurations
4. Exec into the container (if running) to check internal state
Explain what each command reveals.
Usage example: Run the commands:
- kubectl get pods my-pod — shows status
- kubectl logs my-pod --tail=100 — shows recent logs
- kubectl describe pod my-pod — shows events, resource limits, and probe config
- kubectl exec -it my-pod -- /bin/sh — interactive shell (if container is running)
According to the Kubernetes troubleshooting guide (kubernetes.io/docs/tasks/debug/debug-pods/), CrashLoopBackOff usually indicates a startup failure—check the logs first, then verify probes are correctly configured. If the container exits immediately, the init container might be failing.
Conclusion
Mastering Kubernetes manifests, Helm charts, and deployment strategies is essential for any DevOps engineer or platform team. The 12 prompts above cover the most common scenarios you will encounter daily—from writing a simple Pod to validating Helm values with JSON Schema. Use them as a starting point, but always adapt the generated YAML to your specific cluster configuration and security requirements.
For further reading, consult the official Kubernetes documentation (kubernetes.io/docs) and Helm hub (artifacthub.io). If you have a favorite prompt that you use daily, share it in the comments below. And remember: always test your manifests in a staging environment before rolling to production.
Comments