You're staring at a YAML file at 2 AM, wondering why your HPA won't scale. Or maybe you're onboarding a new service and the Ingress config is fighting you. We've all been there. Kubernetes is powerful, but it's also notoriously verbose. That's where AI prompts come in. Instead of digging through 500 pages of docs, you can get a solid, working config in seconds. But only if you ask the right way. This isn't about magic—it's about giving the AI enough context to generate something that actually runs in your cluster. Let's get to it.
The Golden Rules of Kubernetes Prompts
Before we dive in, there's one thing you need to internalize: context is king. A prompt like "write an HPA" will give you a generic result. A prompt like "write an HPA for a Node.js app that scales between 2 and 10 replicas based on CPU at 70%" gives you exactly what you need. Always specify your environment—version, cloud provider, and any constraints. The best prompts are essentially a spec sheet.
1. The Minimal Nginx Deployment
Sometimes you just need a plain deployment to test something. This prompt gets you a stripped-down, working config.
Prompt:
"Generate a minimal Kubernetes Deployment YAML for nginx:latest, with 3 replicas, a resource request of 100m CPU and 128Mi memory, and a limit of 500m CPU and 256Mi memory. Include a Service of type ClusterIP on port 80. Use apiVersion apps/v1."
Why it works: It specifies the image, replicas, resource limits (which are crucial for the scheduler), and the exact API version. No extra fluff, just a deployable unit.
2. Zero-Downtime Rolling Update
Deployments are great, but a bad rolling update can take your app down. This prompt focuses on the strategy.
Prompt:
"Create a Deployment YAML for a Python Flask app (image: myrepo/flask-app:v2) with a rolling update strategy: maxUnavailable: 0, maxSurge: 1. Add startupProbe (HTTP GET /health, periodSeconds: 5, failureThreshold: 30) and readinessProbe (HTTP GET /ready, periodSeconds: 10). Set terminationGracePeriodSeconds: 60."
Why it works: maxUnavailable: 0 ensures no downtime. The probes make sure the new pod is actually ready before the old one is killed. The grace period lets your app finish in-flight requests.
3. Debugging a CrashLoopBackOff
You see CrashLoopBackOff and have no idea why. This prompt turns AI into a debugging partner.
Prompt:
"I have a pod in CrashLoopBackOff. The logs show 'Error: listen EADDRINUSE: address already in use :::8080'. My container is a Node.js app using Express. What are the most likely causes and how do I fix it? Give me the exact kubectl commands to diagnose."
Why it works: It gives the AI a specific error and context. The answer will include checking the logs (kubectl logs <pod> --previous), checking if the port is bound in the container (ss -tulpn), and checking for a hostPort conflict.
4. The Perfect HPA for a Web App
Autoscaling is where Kubernetes shines, but only if configured correctly.
Prompt:
"Write a HorizontalPodAutoscaler YAML for a Deployment named 'web-api' that scales between 3 and 15 replicas. Target average CPU utilization at 60%. Also, add a custom metric: scale if the average request latency (from Prometheus, metric name 'http_request_duration_seconds') exceeds 200ms for 5 minutes. Use apiVersion autoscaling/v2."
Why it works: It covers both resource-based and custom metrics. The autoscaling/v2 version supports multiple metrics, giving you a more dynamic scaling behavior than just CPU.
5. Autoscaling with Custom Prometheus Metrics
Speaking of custom metrics, this is a more advanced scenario that trips up many.
Prompt:
"Explain how to configure the Prometheus Adapter to expose a custom metric 'http_requests_total' as a custom.metrics.k8s.io resource. Provide the adapter config (values.yaml) and the HPA YAML that uses this metric to scale a deployment based on requests per second (rate of http_requests_total) above 100."
Why it works: It asks for the adapter configuration, which is often the hidden piece. The answer will include the rules section with metricsQuery and seriesQuery.
6. Cluster Autoscaler vs. HPA
A common point of confusion is when to use which. This prompt clarifies the difference in a practical way.
Prompt:
"I have a GKE cluster with Cluster Autoscaler enabled. My HPA is set to scale to 20 replicas, but the cluster only has 3 nodes. How do the Cluster Autoscaler and HPA interact? What happens when the HPA wants more pods but there are no free resources? Give a step-by-step explanation and any relevant kubectl commands to observe this."
Why it works: It asks for the interaction, not just definitions. The answer will explain that the HPA will create a pending pod, and the Cluster Autoscaler will add a node, then the pod will schedule.
7. Blue-Green Deployment with Services
Rollouts are great, but blue-green is still a valid pattern, especially when you need instant rollback.
Prompt:
"Describe a blue-green deployment strategy for a Kubernetes Deployment. I have two services: 'app-blue' and 'app-green' (both pointing to the same app version). The 'app' service selects the 'version: blue' pod. How do I switch traffic to green after testing? Provide the commands to update the selector and roll back if needed."
Why it works: It focuses on the service selector switch, which is the core mechanism. The answer will include kubectl patch svc app -p '{"spec":{"selector":{"version":"green"}}}'.
8. Canary Release with Istio
For more advanced traffic management, Istio is the go-to. This prompt gets you a canary config.
Prompt:
"Generate an Istio VirtualService and DestinationRule for a canary release. The service 'checkout' has two subsets: 'v1' (weight: 90) and 'v2' (weight: 10). The VirtualService should route to 'checkout-v1' and 'checkout-v2' with the specified weights. Use apiVersion networking.istio.io/v1beta1."
Why it works: It specifies the exact API version and the weight distribution, which is the heart of a canary. The answer will be a clean YAML you can apply directly.
9. Network Policies for Zero-Trust
Security is a top concern. This prompt helps you lock down traffic.
Prompt:
"Write a NetworkPolicy that allows ingress traffic to a pod with label 'app: db' only from pods with label 'app: api' on port 5432. Also, allow egress from the db pod to the api pod on port 8000. Use apiVersion networking.k8s.io/v1."
Why it works: It's specific about the source, destination, and port. This is a common pattern for database access and is much safer than allowing all traffic.
10. Persisting State with PersistentVolumeClaims
Stateless is easy; stateful is where things get tricky.
Prompt:
"Create a StatefulSet for a PostgreSQL database with 3 replicas. Each pod should have a PersistentVolumeClaim of 10Gi using the 'standard' StorageClass. The headless service should be named 'postgres' and the pods should be named 'postgres-0', 'postgres-1', etc. Include a readiness probe that checks if the database is ready using psql."
Why it works: It covers the key aspects of a StatefulSet: stable network identity, persistent storage, and ordered deployment. The answer will include a volumeClaimTemplates section.
11. Managing Secrets Safely
Hardcoding secrets in YAML is a big no-no. This prompt shows you the right way.
Prompt:
"Explain the best practices for managing secrets in Kubernetes in 2026. Compare Kubernetes Secrets, Sealed Secrets, and External Secrets Operator (ESO) with AWS Secrets Manager. Provide a YAML example for ESO that fetches a secret named 'api-key' from AWS and injects it into a pod as an environment variable."
Why it works: It asks for a comparison and a practical example. ESO is becoming the standard for cloud-native secret management, and this prompt gives you a working pattern.
12. Monitoring with Prometheus and Grafana
You can't scale what you can't see. This prompt sets up monitoring.
Prompt:
"Generate a PrometheusRule for alerting on PodCrashLooping. The rule should fire for a 'Warning' if the condition 'kube_pod_container_status_restarts_total > 3' persists for 5 minutes. Also, provide a Grafana dashboard JSON (just the panels) to visualize CPU and memory usage per pod."
Why it works: It gives a specific alert condition and asks for the dashboard panels, so you get both alerting and visualization in one go.
13. Cost Optimization with Spot Instances
Running on spot instances can save you a lot, but it's risky. This prompt helps you use them wisely.
Prompt:
"I want to use spot instances for my Kubernetes cluster on AWS. My critical workloads (like a database) should run on on-demand instances, but my stateless web servers can run on spot. How do I configure nodeSelector and nodeAffinity to achieve this? Provide YAML for the node groups and the pod spec."
Why it works: It clearly separates critical and non-critical workloads. The answer will include taints and tolerations or node affinity rules.
14. Debugging DNS Issues Inside the Cluster
DNS is a common source of weird problems. This prompt is a lifesaver.
Prompt:
"My pod can't resolve the service name 'my-svc'. I'm using CoreDNS. What are the first three things to check? Provide the kubectl commands to test DNS resolution from within a pod."
Why it works: It asks for a diagnostic checklist. The answer will include checking the CoreDNS pods (kubectl get pods -n kube-system -l k8s-app=kube-dns), checking the pod's /etc/resolv.conf, and using nslookup or dig from within the pod to test.
15. The All-in-One "Explain My Cluster" Prompt
When you're stuck, sometimes you just need a second pair of eyes.
Prompt:
"Act as a senior Kubernetes administrator. I have a cluster with the following symptoms: requests are timing out, and the API server is slow. I've attached the output of kubectl get nodes, kubectl get pods -A, and kubectl describe node (paste output). Analyze the output and diagnose the most likely root cause. Provide a list of next steps."
Why it works: It provides the AI with real data to analyze. You'll get a structured diagnosis, often pointing to resource exhaustion, network issues, or etcd problems.
Wrapping Up
These prompts are a starting point, not a silver bullet. The best way to use them is to adapt them to your specific situation. Add your own context, your app's name, your cloud provider. The more specific you are, the better the result. And always, always test in a staging environment first. Happy scaling!
Comments