10 Prompts for Kubernetes: Manifests, Helm, and Deployment Mastery

Kubernetes has become the de facto standard for container orchestration, but even experienced engineers can spend hours debugging a misconfigured Ingress or a Helm chart that refuses to render correctly. According to the 2025 CNCF Annual Survey, 78% of respondents reported using Kubernetes in production, yet configuration complexity remains the top operational challenge. This article presents 10 carefully crafted prompts that will help you generate precise Kubernetes manifests, debug Helm charts, and streamline deployments. Each prompt is accompanied by a real-world example, a problem-solution breakdown, and actionable output. By the end, you will have a reusable toolkit to turn vague requirements into production-ready YAML.

1. Generate a Basic Pod Manifest

Prompt: "Create a Kubernetes Pod manifest for a stateless web application running Nginx:1.25. The container should expose port 80, set resource requests (256Mi memory, 250m CPU) and limits (512Mi memory, 500m CPU), mount an emptyDir volume at /var/log/nginx, and include a liveness probe that checks /healthz on port 80 every 10 seconds with a 5-second timeout."

Problem: A junior DevOps engineer needs to deploy a simple web server but is unsure how to structure resource requests, probes, and volumes correctly.

Solution: The prompt above produces a complete Pod manifest with all necessary fields.

Result:

apiVersion: v1
kind: Pod
metadata:
  name: nginx-web-app
spec:
  containers:
  - name: nginx
    image: nginx:1.25
    ports:
    - containerPort: 80
    resources:
      requests:
        memory: "256Mi"
        cpu: "250m"
      limits:
        memory: "512Mi"
        cpu: "500m"
    volumeMounts:
    - name: log-volume
      mountPath: /var/log/nginx
    livenessProbe:
      httpGet:
        path: /healthz
        port: 80
      initialDelaySeconds: 5
      periodSeconds: 10
      timeoutSeconds: 5
  volumes:
  - name: log-volume
    emptyDir: {}

Key takeaways: Always define resource limits to prevent noisy-neighbor issues in multi-tenant clusters. Liveness probes prevent cascading failures by restarting unhealthy containers.

2. Create a Production-Grade Service (ClusterIP)

Prompt: "Generate a Kubernetes Service manifest of type ClusterIP that selects pods with label app: myapp and exposes port 8080 to target port 3000. Include session affinity with ClientIP and a timeout of 10800 seconds."

Problem: A team needs internal service discovery with sticky sessions for a stateful microservice.

Solution: The prompt produces a Service manifest with session affinity.

Result:

apiVersion: v1
kind: Service
metadata:
  name: myapp-service
spec:
  selector:
    app: myapp
  ports:
  - protocol: TCP
    port: 8080
    targetPort: 3000
  sessionAffinity: ClientIP
  sessionAffinityConfig:
    clientIP:
      timeoutSeconds: 10800
  type: ClusterIP

Key takeaways: Session affinity is useful for in-memory caches but can lead to uneven load distribution—use it sparingly. The default timeout for ClientIP is 10800 seconds (3 hours).

3. Expose an App with an Ingress Controller (nginx-ingress)

Prompt: "Write an Ingress manifest for the nginx-ingress controller that routes requests from api.example.com to a Service named api-service on port 80. Enable TLS with a secret named tls-secret, add a 301 redirect from HTTP to HTTPS, and set a 10MB body size limit via annotation."

Problem: An application must be publicly accessible with HTTPS and custom routing rules.

Solution: The Ingress manifest includes TLS, annotations, and routing.

Result:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: api-ingress
  annotations:
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
    nginx.ingress.kubernetes.io/proxy-body-size: "10m"
spec:
  ingressClassName: nginx
  tls:
  - hosts:
    - api.example.com
    secretName: tls-secret
  rules:
  - host: api.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: api-service
            port:
              number: 80

Key takeaways: Without the ssl-redirect annotation, nginx-ingress does not automatically redirect HTTP to HTTPS. The proxy-body-size annotation prevents large payloads from being rejected.

4. Deploy a StatefulSet with PersistentVolumeClaim

Prompt: "Generate a StatefulSet manifest for a PostgreSQL 16 database with 3 replicas. Each pod should have a 10Gi PersistentVolumeClaim using the standard storage class, a container port 5432, environment variables for POSTGRES_USER, POSTGRES_PASSWORD, and POSTGRES_DB (sourced from a secret named db-secret), and a readiness probe that checks pg_isready."

Problem: A team needs a reliable, stateful database deployment where each pod has its own persistent volume.

Solution: The StatefulSet ensures stable network identities and persistent storage per replica.

Result:

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: postgres
spec:
  serviceName: postgres
  replicas: 3
  selector:
    matchLabels:
      app: postgres
  template:
    metadata:
      labels:
        app: postgres
    spec:
      containers:
      - name: postgres
        image: postgres:16
        ports:
        - containerPort: 5432
        env:
        - name: POSTGRES_USER
          valueFrom:
            secretKeyRef:
              name: db-secret
              key: user
        - name: POSTGRES_PASSWORD
          valueFrom:
            secretKeyRef:
              name: db-secret
              key: password
        - name: POSTGRES_DB
          valueFrom:
            secretKeyRef:
              name: db-secret
              key: db
        readinessProbe:
          exec:
            command:
            - pg_isready
          initialDelaySeconds: 10
          periodSeconds: 5
        volumeMounts:
        - name: data
          mountPath: /var/lib/postgresql/data
  volumeClaimTemplates:
  - metadata:
      name: data
    spec:
      accessModes: [ "ReadWriteOnce" ]
      storageClassName: standard
      resources:
        requests:
          storage: 10Gi

Key takeaways: StatefulSets require a Headless Service (serviceName) for stable DNS. volumeClaimTemplates automatically create PVCs for each replica.

5. Generate a Helm Chart from Scratch

Prompt: "Create a minimal Helm chart for a Node.js microservice. The chart should include: a Deployment, a Service of type ClusterIP, and an Ingress. Use values.yaml to parameterize the image repository, tag, replica count (default 2), port, and ingress host. Templates should use the 'app.kubernetes.io/name' label convention."

Problem: A developer wants to package an application for reproducible deployments without writing dozens of YAML files manually.

Solution: The prompt produces a chart skeleton with proper templating.

Result (directory structure):

mychart/
├── Chart.yaml
├── values.yaml
└── templates/
    ├── deployment.yaml
    ├── service.yaml
    └── ingress.yaml

values.yaml:

replicaCount: 2
image:
  repository: myregistry/node-app
  tag: latest
  pullPolicy: IfNotPresent
service:
  type: ClusterIP
  port: 3000
ingress:
  enabled: true
  host: app.example.com

deployment.yaml (template excerpt):

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ include "mychart.fullname" . }}
  labels:
    app.kubernetes.io/name: {{ include "mychart.name" . }}
spec:
  replicas: {{ .Values.replicaCount }}
  selector:
    matchLabels:
      app.kubernetes.io/name: {{ include "mychart.name" . }}
  template:
    metadata:
      labels:
        app.kubernetes.io/name: {{ include "mychart.name" . }}
    spec:
      containers:
      - name: {{ .Chart.Name }}
        image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
        ports:
        - containerPort: {{ .Values.service.port }}

Key takeaways: Helm charts decouple configuration from code. Use the built-in template functions (include, default, required) to handle edge cases.

6. Debug a Failing Helm Install with --dry-run

Prompt: "A Helm install fails with 'cannot re-use a name that is still in use'. Write a command to debug the release history, then another command to force a dry-run with template output so I can see the rendered YAML without actually installing."

Problem: A release name conflict prevents a chart from being deployed.

Solution: Use Helm commands to inspect and simulate.

Commands:

# List all releases and their status
helm list -a -n production

# Remove a failed release (if safe)
helm uninstall my-release -n production

# Dry-run with debug output to see the rendered templates
helm install my-release ./mychart --dry-run --debug -n production

Result: The dry-run command prints the full rendered YAML, helping you spot template syntax errors or missing values. The -a flag shows releases in all states (failed, pending, etc.).

Key takeaways: Always use --dry-run before a critical install. The --debug flag adds verbose output, including the computed values.

7. Set Up a ConfigMap for Environment Variables

Prompt: "Generate a ConfigMap manifest that mounts environment variables for a Python app: DATABASE_URL (postgres://user:pass@db:5432/appdb), REDIS_URL (redis://redis:6379), and LOG_LEVEL (DEBUG). Then show a Deployment that injects these via envFrom."

Problem: An application needs non-sensitive configuration injected without hardcoding values in the container image.

Solution: ConfigMap provides a decoupled configuration layer.

ConfigMap:

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  DATABASE_URL: "postgres://user:pass@db:5432/appdb"
  REDIS_URL: "redis://redis:6379"
  LOG_LEVEL: "DEBUG"

Deployment excerpt:

spec:
  template:
    spec:
      containers:
      - name: myapp
        image: myapp:1.0
        envFrom:
        - configMapRef:
            name: app-config

Key takeaways: Use ConfigMaps for non-sensitive data. For secrets (passwords, tokens), use Secrets and reference them separately. envFrom injects all keys as environment variables.

8. Implement a Rolling Update Strategy

Prompt: "Generate a Deployment manifest for a Java microservice with a rolling update strategy: maxSurge=1, maxUnavailable=0, and a 30-second terminationGracePeriodSeconds. Include a startup probe that waits for the HTTP /ready endpoint on port 8080."

Problem: Zero-downtime deployments are required for a customer-facing service.

Solution: A rolling update with startup probe ensures new pods are ready before old ones are terminated.

Result:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: java-service
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  selector:
    matchLabels:
      app: java-service
  template:
    metadata:
      labels:
        app: java-service
    spec:
      terminationGracePeriodSeconds: 30
      containers:
      - name: java-app
        image: myregistry/java-service:2.0
        ports:
        - containerPort: 8080
        startupProbe:
          httpGet:
            path: /ready
            port: 8080
          initialDelaySeconds: 10
          periodSeconds: 5
          failureThreshold: 30

Key takeaways: maxUnavailable=0 ensures at least the desired number of pods are always running. A startup probe prevents the liveness probe from killing slow-starting containers.

9. Create a HorizontalPodAutoscaler (HPA)

Prompt: "Generate an HPA manifest that scales a Deployment named 'api' between 2 and 10 replicas based on CPU utilization (target 60%) and memory utilization (target 80%). Use the autoscaling/v2 API."

Problem: An API service experiences variable traffic and needs to scale automatically.

Solution: HPA with multiple metrics provides responsive scaling.

Result:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: api-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 60
  - type: Resource
    resource:
      name: memory
      target:
        type: Utilization
        averageUtilization: 80

Key takeaways: The HPA controller requires the metrics-server to be installed in the cluster. Using multiple metrics prevents premature scaling based on a single metric spike.

10. Write a NetworkPolicy to Restrict Traffic

Prompt: "Generate a NetworkPolicy that allows ingress traffic only from pods with label 'role: frontend' to pods with label 'role: backend' on TCP port 3000, and denies all other ingress traffic."

Problem: A security audit requires pod-level network segmentation to prevent lateral movement.

Solution: A NetworkPolicy implements zero-trust networking.

Result:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: backend-ingress-policy
spec:
  podSelector:
    matchLabels:
      role: backend
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          role: frontend
    ports:
    - protocol: TCP
      port: 3000

Key takeaways: By default, all pods can communicate. A NetworkPolicy with an empty ingress block denies all ingress traffic. Always test policies in a non-production environment first.

Conclusion

These 10 prompts cover the most common Kubernetes configuration tasks, from basic Pods to advanced HPA and NetworkPolicy. By using structured prompts, you eliminate guesswork and reduce the time spent debugging YAML syntax errors. Start by incorporating the first three prompts into your daily workflow—Pod manifests, Services, and Ingresses—then graduate to Helm charts and autoscaling as your infrastructure grows. The official Kubernetes documentation (kubernetes.io/docs) and Helm hub (artifacthub.io) remain your best friends for reference. Bookmark this guide, and the next time you need to write a manifest, let a prompt do the heavy lifting.