15 Kubernetes Prompts for Efficient Manifest, Helm, and Deployment Management

Introduction

Kubernetes (k8s) has become the de facto standard for container orchestration, but managing manifests, Helm charts, and deployments can be tedious. Prompts — structured instructions for AI assistants — streamline these tasks by generating YAML, debugging configurations, and automating repetitive workflows. This article collects 15 battle-tested prompts that developers actually use daily in production environments, covering Pods, Services, Ingress, Helm, and deployment strategies. Each prompt includes a real usage example and practical notes.

Why Use Prompts for Kubernetes?

AI assistants like Claude or Copilot interpret natural language to produce syntactically correct Kubernetes resources. Instead of memorizing every field in a Pod spec, you describe intent — “expose port 8080 with a selector app: frontend” — and get a ready-to-apply manifest. According to the CNCF's 2025 Annual Survey, 78% of DevOps engineers now use AI tools for at least one part of their k8s workflow. Prompts reduce boilerplate, catch misconfigurations early, and accelerate onboarding for teams new to Kubernetes.

Prompt 1: Generate a Basic Pod Manifest

Prompt:

Create a Kubernetes Pod manifest for an Nginx container. Use image nginx:1.25, expose port 80, include resource limits: 256Mi memory, 500m CPU. Add a liveness probe checking /healthz on port 80.

Usage Example:

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

Note: Always verify the image tag and probe path. Nginx doesn't have /healthz by default — you may need to create it or use exec probe.

Prompt 2: Create a Deployment with Rolling Update Strategy

Prompt:

Create a Kubernetes Deployment for a Python Flask app. Use image flask-app:v2, 3 replicas, rolling update with maxSurge=1 and maxUnavailable=0. Add env vars for DATABASE_URL from a ConfigMap and API_KEY from a Secret. Set resource requests: 128Mi, 250m.

Note: The rolling update strategy ensures zero-downtime deployments. maxUnavailable=0 means new pods must be ready before old ones are terminated.

Prompt 3: Generate a ClusterIP Service

Prompt:

Write a Kubernetes Service manifest of type ClusterIP for the Flask app from the previous Deployment. Target port 5000, expose port 80. Use selector app: flask-app.

Usage Example:

apiVersion: v1
kind: Service
metadata:
  name: flask-service
spec:
  type: ClusterIP
  selector:
    app: flask-app
  ports:
  - port: 80
    targetPort: 5000

Note: ClusterIP is the default. For external access, use NodePort or LoadBalancer.

Prompt 4: Create a NodePort Service for Development

Prompt:

Generate a NodePort Service for the Nginx Pod. Expose port 80, nodePort 30080. Use selector app: nginx.

Note: NodePort range is 30000-32767. Avoid port conflicts by checking existing services.

Prompt 5: Ingress with TLS and Path-Based Routing

Prompt:

Create an Ingress resource for the domain api.example.com. Route /v1/* to the flask-service on port 80, and /static/* to nginx-service on port 80. Enable TLS with a secret named example-tls.

Usage Example:

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

Note: TLS secret must exist in the same namespace. Use cert-manager for automatic certificate management.

Prompt 6: ConfigMap from Environment File

Prompt:

Generate a ConfigMap from an .env file with keys: DB_HOST=localhost, DB_PORT=5432, DEBUG=true. Also create a Pod that mounts all environment variables from this ConfigMap.

Note: ConfigMaps are immutable by default in recent versions. Use kubectl create configmap for updates.

Prompt 7: Secret for Database Credentials

Prompt:

Create a Kubernetes Secret named db-creds with keys: username=admin (base64 encoded), password=s3cret. Then create a Deployment that mounts these as environment variables.

Note: Secrets are base64-encoded, not encrypted. Enable encryption at rest for production.

Prompt 8: Helm Chart Structure Creation

Prompt:

Generate a Helm chart structure for a microservice named 'user-service'. Include templates for Deployment, Service, Ingress, ConfigMap, and Secret. Add values.yaml with default replicas=2, image.repository=myrepo/user-service, image.tag=latest.

Usage Example:

user-service/
├── Chart.yaml
├── values.yaml
├── templates/
│   ├── deployment.yaml
│   ├── service.yaml
│   ├── ingress.yaml
│   ├── configmap.yaml
│   ├── secret.yaml
│   └── _helpers.tpl

Note: Use helm create as a starting point, then customize.

Prompt 9: Helm Values Override for Staging

Prompt:

Create a values-staging.yaml file for the user-service Helm chart. Override replicas to 1, image.tag to staging-latest, and enable ingress with host staging.user.example.com.

Note: Apply with helm install -f values-staging.yaml.

Prompt 10: Generate a Helm Dependency (Subchart)

Prompt:

Add a dependency on the Bitnami Postgresql chart (version 12.x) to the user-service Chart.yaml. Configure it to use a custom database name 'users_db' and password from a secret.

Note: Run helm dependency update after adding.

Prompt 11: Deployment Rollback Strategy

Prompt:

Explain how to rollback a Deployment to the previous revision using kubectl. Also provide a prompt to generate a script that automates rollback if a canary deployment fails health checks.

Usage Example:

kubectl rollout undo deployment/flask-app

Note: Use kubectl rollout history to see revision numbers.

Prompt 12: Canary Deployment with Service Mesh

Prompt:

Generate a canary Deployment for the flask-app that routes 10% traffic to version canary-v2 using a Service Mesh (e.g., Istio VirtualService). The canary pod uses image flask-app:v2 and has an additional label version: canary.

Note: Service mesh is optional; you can also use multiple Services with label selectors for simple canary.

Prompt 13: PersistentVolumeClaim for Stateful App

Prompt:

Create a PersistentVolumeClaim named pvc-data with 10Gi storage, access mode ReadWriteOnce. Then create a Deployment for a MySQL database that mounts this PVC at /var/lib/mysql.

Note: PVC must match available StorageClass. Use kubectl get storageclass to list.

Prompt 14: HorizontalPodAutoscaler (HPA)

Prompt:

Generate an HPA for the flask-app Deployment that scales between 2 and 10 replicas when CPU utilization exceeds 70%. Use metrics-server.

Usage Example:

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

Note: Metrics-server must be installed in the cluster.

Prompt 15: Troubleshooting Pod CrashLoopBackOff

Prompt:

Debug a Pod in CrashLoopBackOff. List commands to check logs, describe events, and verify resource limits. Also provide a prompt to generate a script that tails logs for all pods with label app=flask-app.

Usage Example:

kubectl logs pod/flask-app-xxx --previous
kubectl describe pod/flask-app-xxx
kubectl get events --field-selector involvedObject.name=flask-app-xxx

Note: The --previous flag shows logs from the terminated container.

Conclusion

These 15 prompts cover the core daily tasks of Kubernetes developers: generating manifests, configuring Helm charts, and managing deployments. By integrating AI prompts into your workflow, you reduce boilerplate, standardize outputs, and focus on architecture decisions. Remember to always review generated YAML — AI can hallucinate fields or use outdated APIs. Combine prompts with kubectl apply --dry-run=client for validation. For teams adopting GitOps, store prompts in a shared repository to enforce consistency. Start with one prompt today, and iterate based on your cluster's specific needs.

← All posts

Comments