12 Prompts for Kubernetes: Manifests, Helm, and Deployment

12 Prompts for Kubernetes: Manifests, Helm, and Deployment

Kubernetes (K8s) has become the de facto standard for container orchestration, but writing correct YAML manifests, managing Helm charts, and debugging deployments can be tedious. This guide provides 12 ready-to-use prompts that will help you generate Pod specs, Services, Ingress rules, and Helm values — all with real-world examples. According to the CNCF Annual Survey 2025, 96% of organizations are using or evaluating Kubernetes, yet 67% cite YAML complexity as a top challenge. These prompts cut that friction.

1. Generate a Pod Manifest with Resource Limits

Task: Create a Pod YAML for an Nginx container with CPU and memory constraints.
Prompt: "Generate a Kubernetes Pod manifest named 'web-pod' using the nginx:1.25 image. Set CPU request to 250m, limit to 500m; memory request to 256Mi, limit to 512Mi. Include a liveness probe on port 80."
Example:

apiVersion: v1
kind: Pod
metadata:
  name: web-pod
spec:
  containers:
  - name: nginx
    image: nginx:1.25
    resources:
      requests:
        cpu: "250m"
        memory: "256Mi"
      limits:
        cpu: "500m"
        memory: "512Mi"
    livenessProbe:
      httpGet:
        path: /
        port: 80
      initialDelaySeconds: 5
      periodSeconds: 10

Why it works: Resource limits prevent noisy neighbors on shared clusters. The probe ensures automatic restarts if the container hangs.

2. Create a ClusterIP Service for Internal Communication

Task: Expose a set of pods internally within the cluster.
Prompt: "Generate a Service manifest of type ClusterIP named 'backend-svc' that selects pods with label 'app: backend'. Expose port 8080 on the service and target port 80 on the pods."
Example:

apiVersion: v1
kind: Service
metadata:
  name: backend-svc
spec:
  selector:
    app: backend
  ports:
  - port: 8080
    targetPort: 80
  type: ClusterIP

Why it works: ClusterIP is the default and secure way to enable pod-to-pod communication without external exposure. The targetPort allows pods to run on a different port than the service.

3. Build a NodePort Service for External Access

Task: Expose an application externally using a NodePort.
Prompt: "Generate a Service of type NodePort named 'frontend-svc' that selects pods with label 'app: frontend'. Map service port 80 to target port 3000, and allocate a node port in the range 30000-32767."
Example:

apiVersion: v1
kind: Service
metadata:
  name: frontend-svc
spec:
  type: NodePort
  selector:
    app: frontend
  ports:
  - port: 80
    targetPort: 3000
    nodePort: 30080

Why it works: NodePort is simple for development or small clusters. The explicit nodePort avoids random assignment — use it sparingly in production due to security considerations.

4. Write an Ingress Manifest for Path-Based Routing

Task: Route traffic to different services based on URL path.
Prompt: "Generate an Ingress manifest named 'main-ingress' for the domain 'example.com'. Route '/api' to 'api-svc:8080' and '/web' to 'web-svc:80'. Use the nginx ingress controller and enable TLS with a secret named 'tls-secret'."
Example:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: main-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  tls:
  - hosts:
    - example.com
    secretName: tls-secret
  rules:
  - host: example.com
    http:
      paths:
      - path: /api
        pathType: Prefix
        backend:
          service:
            name: api-svc
            port:
              number: 8080
      - path: /web
        pathType: Prefix
        backend:
          service:
            name: web-svc
            port:
              number: 80

Why it works: Ingress consolidates routing rules, reduces the need for multiple LoadBalancers, and centralizes TLS termination. The rewrite-target annotation strips the path prefix before forwarding.

5. Create a Helm Chart Values File for a Microservice

Task: Configure a Helm deployment for a stateless microservice.
Prompt: "Write a values.yaml file for a Helm chart that deploys a microservice named 'user-service'. Set image repository to 'myrepo/user-service:2.0', replica count to 3, service port 9000, and enable a liveness probe with initial delay 10s. Include environment variables DATABASE_URL and API_KEY from a secret."
Example:

replicaCount: 3
image:
  repository: myrepo/user-service
  tag: "2.0"
  pullPolicy: IfNotPresent
service:
  port: 9000
livenessProbe:
  enabled: true
  initialDelaySeconds: 10
  periodSeconds: 15
env:
  - name: DATABASE_URL
    valueFrom:
      secretKeyRef:
        name: db-secret
        key: url
  - name: API_KEY
    valueFrom:
      secretKeyRef:
        name: api-secret
        key: key

Why it works: Helm values separate configuration from code, making deployments repeatable across environments. Using secrets for sensitive data follows security best practices.

6. Generate a ConfigMap for Application Configuration

Task: Store non-sensitive configuration in a ConfigMap.
Prompt: "Create a ConfigMap named 'app-config' with key-value pairs: LOG_LEVEL=debug, MAX_CONNECTIONS=100. Then mount it as environment variables in a Pod named 'worker'."
Example:

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  LOG_LEVEL: debug
  MAX_CONNECTIONS: "100"
---
apiVersion: v1
kind: Pod
metadata:
  name: worker
spec:
  containers:
  - name: worker
    image: myapp/worker:1.0
    envFrom:
    - configMapRef:
        name: app-config

Why it works: ConfigMaps decouple configuration from container images. The envFrom field injects all keys at once, reducing boilerplate.

7. Write a PersistentVolumeClaim for Stateful Workloads

Task: Request 10Gi of storage for a database pod.
Prompt: "Generate a PersistentVolumeClaim named 'mysql-pvc' requesting 10Gi of ReadWriteOnce storage with storage class 'fast-ssd'. Then mount it at /var/lib/mysql in a MySQL pod."
Example:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mysql-pvc
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
  storageClassName: fast-ssd

Why it works: PVCs abstract storage provisioning. The storage class ensures the correct underlying volume type (e.g., SSD for databases).

8. Create a HorizontalPodAutoscaler for Scaling

Task: Autoscale a deployment based on CPU usage.
Prompt: "Generate an HPA named 'web-hpa' for the deployment 'web-deploy'. Target 70% CPU utilization, with minimum 2 and maximum 10 replicas."
Example:

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

Why it works: HPA dynamically adjusts replicas to maintain performance. The v2 API supports multiple metrics (memory, custom) — start with CPU as a baseline.

9. Generate a NetworkPolicy to Restrict Traffic

Task: Allow only ingress traffic from a specific namespace.
Prompt: "Write a NetworkPolicy named 'allow-monitoring' that allows ingress to pods with label 'app: api' only from pods in namespace 'monitoring' on port 8080."
Example:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-monitoring
spec:
  podSelector:
    matchLabels:
      app: api
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: monitoring
    ports:
    - port: 8080

Why it works: Network policies enforce micro-segmentation. Without them, all pods can communicate by default — a major security risk.

10. Create a Helm Chart Template for a Deployment

Task: Write a reusable Deployment template in a Helm chart.
Prompt: "Generate a deployment.yaml template for a Helm chart that uses values for 'image.repository', 'image.tag', 'replicaCount', and 'service.port'. Include a readiness probe on the container port."
Example:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ .Release.Name }}-{{ .Chart.Name }}
  labels:
    app: {{ .Chart.Name }}
spec:
  replicas: {{ .Values.replicaCount }}
  selector:
    matchLabels:
      app: {{ .Chart.Name }}
  template:
    metadata:
      labels:
        app: {{ .Chart.Name }}
    spec:
      containers:
      - name: {{ .Chart.Name }}
        image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
        ports:
        - containerPort: {{ .Values.service.port }}
        readinessProbe:
          httpGet:
            path: /health
            port: {{ .Values.service.port }}
          initialDelaySeconds: 5

Why it works: Helm templates use Go templating to inject values. The {{ .Release.Name }} ensures unique resource names per release.

11. Write a DaemonSet for Log Collection

Task: Run a fluentd agent on every node.
Prompt: "Generate a DaemonSet named 'fluentd-agent' that runs the image 'fluent/fluentd:v1.16' on all nodes. Mount /var/log from the host to /var/log in the container."
Example:

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluentd-agent
spec:
  selector:
    matchLabels:
      name: fluentd-agent
  template:
    metadata:
      labels:
        name: fluentd-agent
    spec:
      containers:
      - name: fluentd
        image: fluent/fluentd:v1.16
        volumeMounts:
        - name: varlog
          mountPath: /var/log
      volumes:
      - name: varlog
        hostPath:
          path: /var/log

Why it works: DaemonSets ensure one pod per node, ideal for logging, monitoring, or networking agents. HostPath volumes give access to node-level data.

12. Generate a Job for Batch Processing

Task: Run a one-time data migration script.
Prompt: "Create a Kubernetes Job named 'db-migrate' that runs the image 'myapp/migrate:1.0' with a command 'python migrate.py'. Set backoffLimit to 2 and activeDeadlineSeconds to 300."
Example:

apiVersion: batch/v1
kind: Job
metadata:
  name: db-migrate
spec:
  backoffLimit: 2
  activeDeadlineSeconds: 300
  template:
    spec:
      containers:
      - name: migrate
        image: myapp/migrate:1.0
        command: ["python", "migrate.py"]
      restartPolicy: Never

Why it works: Jobs guarantee completion. The backoffLimit prevents infinite retries on failure, and activeDeadlineSeconds sets a hard timeout.

Conclusion

These 12 prompts cover the most common Kubernetes tasks — from basic Pods to advanced Helm templates and autoscaling. Start by copying the examples into your cluster, then customize parameters for your workload. For production, always add resource limits, probes, and security contexts. Bookmark this guide and use the prompts as a quick reference. Next time you need a manifest, just paste the prompt into your favorite AI tool — it will save you hours of YAML debugging.