Introduction
Kubernetes (K8s) has become the de facto orchestrator for containerized applications. Whether you're writing YAML manifests, packaging applications with Helm, or automating deployments, the command line and configuration files are your daily tools. But what if you could speed up these tasks by using AI prompts? This article provides 15 ready-to-use prompts that generate K8s manifests, Helm charts, deployment strategies, and troubleshooting commands. Each prompt is designed to be copy-pasted into an AI assistant (like ChatGPT or Claude) and yields practical, production-ready output. Let's dive in.
Prompts for Pods and Containers
1. Basic Pod Manifest
Prompt:
Generate a minimal Kubernetes Pod manifest for an Nginx container.
Example output:
apiVersion: v1
kind: Pod
metadata:
name: nginx-pod
spec:
containers:
- name: nginx
image: nginx:1.25
ports:
- containerPort: 80
Why: This prompt creates a simple, runnable Pod. It's the foundation for learning K8s and testing local clusters (e.g., Minikube).
2. Pod with Init Container
Prompt:
Create a Pod manifest that uses an init container to wait for a MySQL database to be ready before starting the main app container.
Example output:
apiVersion: v1
kind: Pod
metadata:
name: app-wait-for-db
spec:
initContainers:
- name: init-mysql
image: busybox
command: ['sh', '-c', 'until nslookup mysql-service.default.svc.cluster.local; do echo waiting for mysql; sleep 2; done;']
containers:
- name: app
image: myapp:v1
Why: Init containers are crucial for ensuring dependencies are ready. This prompt uses K8s DNS to check service availability.
3. Multi-Container Pod with Sidecar
Prompt:
Write a Pod manifest with two containers: an Nginx server and a sidecar that tails logs and sends them to stdout.
Example output:
apiVersion: v1
kind: Pod
metadata:
name: web-with-logger
spec:
containers:
- name: nginx
image: nginx:1.25
volumeMounts:
- name: logs
mountPath: /var/log/nginx
- name: log-sidecar
image: busybox
command: ['sh', '-c', 'tail -f /var/log/nginx/access.log']
volumeMounts:
- name: logs
mountPath: /var/log/nginx
ports:
- containerPort: 80
volumes:
- name: logs
emptyDir: {}
Why: Sidecars are a standard pattern for logging, monitoring, or proxying. This prompt produces a minimal but realistic example.
Prompts for Services and Networking
4. ClusterIP Service
Prompt:
Generate a ClusterIP Service YAML that exposes port 8080 on a set of Pods labeled 'app: myapp'.
Example output:
apiVersion: v1
kind: Service
metadata:
name: myapp-service
spec:
selector:
app: myapp
ports:
- protocol: TCP
port: 80
targetPort: 8080
Why: ClusterIP is the default Service type for internal communication. This prompt teaches the core selector and port mapping.
5. LoadBalancer and Ingress
Prompt:
Create a LoadBalancer Service YAML for a web app, and an Ingress resource to route traffic based on hostname 'example.com' to that service on port 80.
Example output (Service):
apiVersion: v1
kind: Service
metadata:
name: web-service
spec:
type: LoadBalancer
selector:
app: web
ports:
- port: 80
targetPort: 3000
Example output (Ingress):
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: web-ingress
spec:
rules:
- host: example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: web-service
port:
number: 80
Why: LoadBalancer provides external connectivity, and Ingress enables host/path‑based routing. This prompt covers both.
6. NetworkPolicy
Prompt:
Write a NetworkPolicy that allows only Pods with label 'role: frontend' to connect to Pods with label 'role: backend' on port 3306.
Example output:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: backend-ingress
spec:
podSelector:
matchLabels:
role: backend
ingress:
- from:
- podSelector:
matchLabels:
role: frontend
ports:
- protocol: TCP
port: 3306
Why: NetworkPolicy is essential for microservice segmentation. This prompt gives a concrete, security‑minded example.
Prompts for Helm Charts
7. Helm Chart Skeleton
Prompt:
List the directory structure of a minimal Helm chart and provide the content of Chart.yaml, values.yaml, and a simple deployment template.
Example output:
Chart.yaml
values.yaml
charts/
templates/
deployment.yaml
service.yaml
_helpers.tpl
Chart.yaml:
apiVersion: v2
name: mychart
version: 0.1.0
values.yaml:
replicaCount: 2
image:
repository: nginx
tag: latest
templates/deployment.yaml:
apiVersion: apps/v1
kind: Deployment
metadata:
name: {{ include "mychart.fullname" . }}
spec:
replicas: {{ .Values.replicaCount }}
selector:
matchLabels:
app: {{ include "mychart.name" . }}
template:
metadata:
labels:
app: {{ include "mychart.name" . }}
spec:
containers:
- name: nginx
image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
Why: This prompt teaches the Helm best practice: separating configuration from templates.
8. Helm with ConfigMap and Secrets
Prompt:
Extend a Helm chart to include a ConfigMap and a Secret. The values file should contain database credentials that are injected into the Secret.
Example placeholder in values.yaml:
database:
host: "mydb.example.com"
user: "admin"
password: "changeme"
Expected template additions:
- ConfigMap for non‑sensitive data (e.g., host).
- Secret using {{ .Values.database.password | b64enc }}.
- Deployment mounts ConfigMap and Secret as environment variables.
Why: Many real apps need both config and secrets. This prompt covers encoding and conditionals.
9. Helm Dependencies
Prompt:
Create a parent Helm chart that depends on the official Postgres chart and my own 'app' chart. Provide the Chart.yaml dependency syntax and the commands to update dependencies.
Example Chart.yaml:
dependencies:
- name: postgresql
version: 12.x.x
repository: https://charts.bitnami.com/bitnami
- name: app
version: 0.1.0
repository: "file://../app"
Command: helm dependency update
Why: Helm dependencies help reuse community charts and manage complex stacks.
Prompts for Deployment Strategies
10. RollingUpdate Deployment
Prompt:
Write a Deployment manifest that uses RollingUpdate strategy with maxSurge=25% and maxUnavailable=0%.
Example output:
apiVersion: apps/v1
kind: Deployment
metadata:
name: myapp
spec:
replicas: 4
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 25%
maxUnavailable: 0
selector:
matchLabels:
app: myapp
template:
metadata:
labels:
app: myapp
spec:
containers:
- name: app
image: myapp:v2
Why: Controlling surge and unavailable pods ensures zero‑downtime deployments.
11. Blue‑Green Deployment with Services
Prompt:
Provide YAML for two Services pointing to different Deployments (blue and green), plus a script to switch traffic by updating the label selector in the primary Service.
Example: Two Services app-blue and app-green with selectors version: blue and version: green. A main app Service that initially selects version: blue. Switch by running kubectl patch service app -p '{"spec":{"selector":{"version":"green"}}}'.
Why: Blue‑green reduces risk. This prompt gives a manual but clear approach.
12. Canary Deployment with Ingress
Prompt:
Create an Ingress that routes 10% of traffic to a canary Service and 90% to the stable Service using nginx.ingress.kubernetes.io/canary annotations.
Example Ingress:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: main-ingress
annotations:
nginx.ingress.kubernetes.io/canary: "true"
nginx.ingress.kubernetes.io/canary-weight: "10"
spec:
rules:
- host: example.com
http:
paths:
- backend:
service:
name: canary-service
Why: Canary releases are a best practice. This uses the NGINX Ingress Controller's native feature.
Prompts for Troubleshooting and Debugging
13. Debug BusyBox Pod
Prompt:
Write a command to run a temporary BusyBox Pod in the same namespace and with the same network as a target Pod to debug DNS issues.
Example command:
kubectl run debug-pod --image=busybox -it --rm --restart=Never -- /bin/sh -c 'nslookup myservice'
Why: Temporary debug Pods are a fundamental K8s troubleshooting technique.
14. Check Pod Logs and Events
Prompt:
Create a one-liner script that simultaneously tails logs from a specific Pod and streams its events, color‑coding output.
Example script:
kubectl logs -f pod/my-pod &
kubectl get events --watch --field-selector involvedObject.name=my-pod | while read line; do echo -e "\033[0;33m$line\033[0m"; done
Why: Combining logs and events speeds up debugging.
15. Resource Quota and LimitRange
Prompt:
Generate a ResourceQuota that limits CPU to 4 cores and memory to 8Gi across all Pods in a namespace, and a LimitRange that sets default requests and limits for containers.
Example ResourceQuota:
apiVersion: v1
kind: ResourceQuota
metadata:
name: compute-quota
spec:
hard:
requests.cpu: "4"
requests.memory: 8Gi
limits.cpu: "8"
limits.memory: 16Gi
Example LimitRange:
apiVersion: v1
kind: LimitRange
metadata:
name: container-limits
spec:
limits:
- default:
cpu: "500m"
memory: "256Mi"
defaultRequest:
cpu: "200m"
memory: "128Mi"
type: Container
Why: Resource management is critical in multi‑tenant clusters. This prompt covers both quota and defaults.
Conclusion
These 15 prompts cover the core aspects of Kubernetes management: from basic Pods to advanced deployments and Helm packaging. By feeding these exact prompts to an AI assistant, you can generate production‑ready manifests, speed up repetitive tasks, and learn best practices. Remember to always verify AI‑generated YAML against the official Kubernetes documentation and test in a non‑production environment first. Incorporate these prompts into your daily workflow to become more efficient with K8s.
What's your go‑to Kubernetes prompt? Share it with us in the comments below!
Comments