N Prompts for Kubernetes: Master Manifests, Helm, and Deployments

Introduction

Kubernetes (K8s) has become the de facto standard for container orchestration, powering everything from small side projects to massive enterprise workloads. But writing YAML manifests from scratch, managing Helm charts, and orchestrating deployments can feel like a black art—especially when you need to produce consistent, production-grade configurations quickly. This is where prompts come in: structured natural language instructions that guide AI assistants (like ChatGPT, Claude, or Gemini) to generate Kubernetes resources for you. Instead of memorizing every API field or digging through documentation, you can describe your intent and get a battle-tested template.

In this article, I’ll share a curated collection of N prompts organized into three skill levels: basic, advanced, and expert. Each prompt includes a specific task, the exact prompt text, and a realistic example result. Whether you’re a developer new to K8s or a platform engineer managing dozens of clusters, these prompts will accelerate your workflow and reduce YAML fatigue.

I’ve designed these prompts based on real-world patterns from the Kubernetes community, the official Kubernetes documentation, and the Helm documentation. I’ll also cite source materials where applicable. Let’s dive in.

Basic Prompts

1. Generate a Simple Pod Manifest

Task: Create a Pod that runs an Nginx container with resource limits and a health check.

Prompt:

"Generate a Kubernetes Pod YAML manifest named 'web-server-pod' that runs the latest nginx container. Set CPU and memory limits: 500m CPU and 256Mi memory. Add a liveness probe that checks the HTTP endpoint '/' on port 80 every 10 seconds with a 5-second timeout. Also add a readiness probe with the same settings. Use the 'app: web' label."

Example Result:

apiVersion: v1
kind: Pod
metadata:
  name: web-server-pod
  labels:
    app: web
spec:
  containers:
  - name: nginx
    image: nginx:latest
    ports:
    - containerPort: 80
    resources:
      limits:
        cpu: "500m"
        memory: "256Mi"
      requests:
        cpu: "250m"
        memory: "128Mi"
    livenessProbe:
      httpGet:
        path: /
        port: 80
      initialDelaySeconds: 3
      periodSeconds: 10
      timeoutSeconds: 5
    readinessProbe:
      httpGet:
        path: /
        port: 80
      initialDelaySeconds: 3
      periodSeconds: 10
      timeoutSeconds: 5

This prompt covers the basics: container image, resource limits, and probes. The AI balances readability with production readiness. Note that best practice is to use :latest only in development; for production you’d pin a specific version like nginx:1.25.

2. Create a ClusterIP Service

Task: Expose the Pod internally via a ClusterIP Service.

Prompt:

"Write a Kubernetes Service YAML manifest named 'web-service' of type ClusterIP that selects pods with label 'app: web' and exposes port 80 mapping to target port 80. Use the default ClusterIP assignment."

Example Result:

apiVersion: v1
kind: Service
metadata:
  name: web-service
spec:
  selector:
    app: web
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80
  type: ClusterIP

ClusterIP is the default service type and makes the Pod reachable inside the cluster via web-service:80. This is a foundational building block for internal microservice communication.

3. Deploy a Simple Ingress

Task: Expose the Service externally using an Ingress resource.

Prompt:

"Generate an Ingress YAML manifest named 'web-ingress' that routes traffic from the host 'example.com' to the service 'web-service' on port 80. Use the nginx-ingress controller class 'nginx'. Also add a TLS section with a secret name 'example-tls'."

Example Result:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web-ingress
spec:
  ingressClassName: nginx
  tls:
  - hosts:
    - example.com
    secretName: example-tls
  rules:
  - host: example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: web-service
            port:
              number: 80

This prompt introduces ingressClassName, TLS termination, and path-based routing. The nginx ingress controller is widely adopted (see NGINX Ingress Controller documentation).

Advanced Prompts

4. Multi-Container Pod with Sidecar Pattern

Task: Deploy a Pod with a main application container and a logging sidecar that tails logs.

Prompt:

"Generate a Kubernetes Pod manifest named 'app-with-sidecar' that runs two containers: one container named 'app' using image 'my-app:1.0' exposing port 8080, and a sidecar container named 'log-collector' using image 'busybox:1.36' that runs the command 'tail -f /var/log/app.log'. Mount a shared emptyDir volume at '/var/log' in both containers. Add liveness probes for the app container."

Example Result:

apiVersion: v1
kind: Pod
metadata:
  name: app-with-sidecar
spec:
  volumes:
  - name: shared-logs
    emptyDir: {}
  containers:
  - name: app
    image: my-app:1.0
    ports:
    - containerPort: 8080
    volumeMounts:
    - name: shared-logs
      mountPath: /var/log
    livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
      initialDelaySeconds: 5
      periodSeconds: 10
  - name: log-collector
    image: busybox:1.36
    command: ["tail", "-f", "/var/log/app.log"]
    volumeMounts:
    - name: shared-logs
      mountPath: /var/log

Sidecar containers are a common pattern for logging, monitoring, or service mesh proxies (e.g., Envoy in Istio). The emptyDir volume is ephemeral, tied to the Pod’s lifecycle.

5. Deploy a StatefulSet with Persistent Storage

Task: Create a StatefulSet for a PostgreSQL database with persistent volume claims.

Prompt:

"Write a StatefulSet YAML manifest named 'postgres-sts' that deploys 3 replicas of PostgreSQL 16. Use a headless service named 'postgres-hl' with port 5432. Each Pod should mount a PersistentVolumeClaim named 'pg-data' with 10Gi of storage using the standard storage class. Include environment variables POSTGRES_USER and POSTGRES_PASSWORD from a Secret named 'pg-secret'."

Example Result:

apiVersion: v1
kind: Service
metadata:
  name: postgres-hl
spec:
  clusterIP: None
  selector:
    app: postgres
  ports:
  - port: 5432
    targetPort: 5432
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: postgres-sts
spec:
  serviceName: postgres-hl
  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: pg-secret
              key: user
        - name: POSTGRES_PASSWORD
          valueFrom:
            secretKeyRef:
              name: pg-secret
              key: password
        volumeMounts:
        - name: pg-data
          mountPath: /var/lib/postgresql/data
  volumeClaimTemplates:
  - metadata:
      name: pg-data
    spec:
      accessModes: ["ReadWriteOnce"]
      resources:
        requests:
          storage: 10Gi
      storageClassName: standard

StatefulSets guarantee stable network identities and ordered rolling updates—critical for stateful workloads like databases. The volumeClaimTemplates automatically create PVCs per replica.

6. Helm Chart for a Microservice

Task: Create a minimal Helm chart for a generic microservice.

Prompt:

"Generate a Helm chart skeleton for a microservice named 'my-service'. Include a Deployment, a Service (ClusterIP), and an Ingress. Use values.yaml for image, replicas, port, and ingress host. The Deployment should have resource limits and a liveness probe. The Ingress should support TLS via an optional tls secret."

Example Result (values.yaml):

replicaCount: 2
image:
  repository: my-service
  tag: latest
  pullPolicy: IfNotPresent
service:
  port: 80
  targetPort: 8080
resources:
  limits:
    cpu: "500m"
    memory: "256Mi"
  requests:
    cpu: "250m"
    memory: "128Mi"
ingress:
  enabled: true
  host: my-service.example.com
  tls:
    enabled: true
    secretName: my-service-tls

Example Result (templates/deployment.yaml):

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ include "my-service.fullname" . }}
spec:
  replicas: {{ .Values.replicaCount }}
  selector:
    matchLabels:
      app: {{ include "my-service.name" . }}
  template:
    metadata:
      labels:
        app: {{ include "my-service.name" . }}
    spec:
      containers:
      - name: {{ .Chart.Name }}
        image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
        imagePullPolicy: {{ .Values.image.pullPolicy }}
        ports:
        - containerPort: {{ .Values.service.targetPort }}
        resources:
          {{- toYaml .Values.resources | nindent 10 }}
        livenessProbe:
          httpGet:
            path: /health
            port: {{ .Values.service.targetPort }}
          initialDelaySeconds: 5
          periodSeconds: 10

Helm charts abstract configuration into values, making deployments reusable across environments. The official Helm documentation provides more depth on template functions.

Expert Prompts

7. Generate a Production-Grade NetworkPolicy

Task: Create a NetworkPolicy that restricts ingress traffic to a set of pods.

Prompt:

"Write a Kubernetes NetworkPolicy YAML manifest named 'api-allow-ingress' that applies to pods with label 'app: api'. Allow ingress traffic only from pods with label 'role: frontend' on TCP port 8080. Also allow ingress from the monitoring namespace on port 9090. Deny all other ingress traffic. Use policyTypes: [Ingress]."

Example Result:

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

NetworkPolicies are essential for zero-trust networking. The default deny behavior requires explicit allow rules. This example also demonstrates namespace selection, which is often used for cross-namespace monitoring.

8. HorizontalPodAutoscaler with Custom Metrics

Task: Set up HPA based on custom Prometheus metrics.

Prompt:

"Generate a HorizontalPodAutoscaler YAML manifest named 'api-hpa' for a Deployment named 'api-deployment'. Set minReplicas: 2, maxReplicas: 10. Use a custom metric from Prometheus named 'http_requests_per_second' with target value 100. Assume the custom.metrics.k8s.io API is available."

Example Result:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: api-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api-deployment
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Pods
    pods:
      metric:
        name: http_requests_per_second
      target:
        type: AverageValue
        averageValue: 100

This HPA uses the Pods metric type, which aggregates per-pod metrics. For this to work, you need a custom metrics adapter (like Prometheus Adapter) installed in your cluster. The official Kubernetes HPA walkthrough covers setup.

9. ArgoCD ApplicationSet for Multi-Cluster Deployment

Task: Create an ArgoCD ApplicationSet that deploys the same app to multiple clusters.

Prompt:

"Write an ArgoCD ApplicationSet YAML manifest named 'multi-cluster-appset' that deploys a Helm chart from a Git repository (https://github.com/myorg/my-chart.git) to two clusters: 'prod-us' and 'prod-eu'. Use cluster-specific values from a file named 'clusters.yaml' that contains cluster name and destination server. Set syncPolicy with automated prune and selfHeal."

Example Result:

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: multi-cluster-appset
spec:
  generators:
  - list:
      elements:
      - cluster: prod-us
        url: https://kubernetes.default.svc
      - cluster: prod-eu
        url: https://k8s-eu.example.com
  template:
    metadata:
      name: 'my-app-{{cluster}}'
    spec:
      project: default
      source:
        repoURL: https://github.com/myorg/my-chart.git
        targetRevision: HEAD
        path: charts/my-app
        helm:
          valueFiles:
          - 'values-{{cluster}}.yaml'
      destination:
        server: '{{url}}'
        namespace: my-app
      syncPolicy:
        automated:
          prune: true
          selfHeal: true

ArgoCD ApplicationSets are a powerful GitOps pattern for multi-cluster management. The list generator iterates over cluster definitions, templating both the application name and destination. For more, see the ArgoCD ApplicationSet documentation.

Conclusion

These N prompts cover the spectrum from single Pod manifests to multi-cluster GitOps configurations. The key takeaway is that AI-assisted Kubernetes authoring isn’t about replacing your knowledge—it’s about accelerating your workflow and reducing errors. By crafting precise prompts, you can generate production-quality YAML in seconds, then review and customize it.

Remember to always validate generated manifests with kubectl apply --dry-run=server and lint them with tools like kubeconform or kube-score. The Kubernetes ecosystem evolves rapidly; keep your prompts up to date with the latest API versions (e.g., apps/v1 for Deployments, networking.k8s.io/v1 for Ingress).

Now go ahead—experiment with these prompts, tweak them for your own workloads, and share your favorite variations with the community. Happy shipping!