Introduction
Kubernetes (K8s) has become the de facto standard for container orchestration, but writing YAML manifests, managing Helm charts, and orchestrating deployments still eats up a significant chunk of an engineer's day. According to the 2025 CNCF Annual Survey, 72% of organizations using Kubernetes reported that operational complexity is their top challenge—and the most time-consuming part is creating and debugging manifests. This article provides ten battle-tested prompts you can use with any large language model (LLM) to accelerate your K8s workflows. Each prompt is designed to solve a real problem: from generating a basic Pod to building a production-ready Helm chart with ingress, service, and auto-scaling.
Whether you're a DevOps engineer pushing a new microservice or a platform team standardizing on Helm, these prompts will reduce your time from idea to deployment. The prompts cover three categories: basic (manifests for core resources), advanced (multi-resource stacks and Helm), and expert (full-stack deployment pipelines with observability).
Category 1: Basic Prompts – Core Resource Manifests
1. Generate a Pod with Resource Limits and Probes
Task: Create a single Pod manifest for a containerized application with CPU/memory limits, liveness probe, and readiness probe.
Prompt:
"Generate a Kubernetes Pod manifest for a container named 'app-backend' using the image 'myapp/backend:v1.0'. Set CPU request to 250m, CPU limit to 500m, memory request to 256Mi, memory limit to 512Mi. Include a liveness probe that checks the HTTP endpoint '/healthz' on port 8080 with an initial delay of 10 seconds and a period of 15 seconds. Add a readiness probe that checks '/ready' on the same port with an initial delay of 5 seconds and a period of 10 seconds."
Example Result:
apiVersion: v1
kind: Pod
metadata:
name: app-backend-pod
labels:
app: backend
spec:
containers:
- name: app-backend
image: myapp/backend:v1.0
ports:
- containerPort: 8080
resources:
requests:
memory: "256Mi"
cpu: "250m"
limits:
memory: "512Mi"
cpu: "500m"
livenessProbe:
httpGet:
path: /healthz
port: 8080
initialDelaySeconds: 10
periodSeconds: 15
readinessProbe:
httpGet:
path: /ready
port: 8080
initialDelaySeconds: 5
periodSeconds: 10
Why It Works: This prompt forces the LLM to produce a valid Pod spec with resource management—critical for avoiding OOM kills in production. The probe configuration ensures the Pod is only included in Service endpoints when truly ready, reducing failed requests.
2. Create a Service with NodePort and Selector
Task: Expose a set of Pods via a Service of type NodePort, with a specific port mapping and label selector.
Prompt:
"Write a Kubernetes Service manifest of type NodePort that exposes pods with the label 'app: backend'. The Service should listen on port 80 and forward traffic to the container port 8080. The nodePort should be manually set to 30080. Add a selector that matches the label 'app: backend' and 'tier: backend'."
Example Result:
apiVersion: v1
kind: Service
metadata:
name: backend-service
spec:
type: NodePort
selector:
app: backend
tier: backend
ports:
- port: 80
targetPort: 8080
nodePort: 30080
Practical Note: The manual nodePort setting is useful for development clusters where you want a predictable external port, but in production, you'd typically let Kubernetes assign it automatically. The prompt explicitly defines the selector, which is a common mistake point for beginners.
3. Define an Ingress with TLS and Path-Based Routing
Task: Create an Ingress resource that routes traffic to a backend Service based on the request path, with TLS termination.
Prompt:
"Generate a Kubernetes Ingress manifest for the host 'api.example.com'. Route traffic going to '/v1/' to a Service named 'v1-backend' on port 80, and traffic to '/v2/' to a Service named 'v2-backend' on port 80. Enable TLS using a secret named 'example-tls'. Use the networking.k8s.io/v1 API version."
Example Result:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: api-ingress
annotations:
nginx.ingress.kubernetes.io/rewrite-target: /
spec:
tls:
- hosts:
- api.example.com
secretName: example-tls
rules:
- host: api.example.com
http:
paths:
- path: /v1
pathType: Prefix
backend:
service:
name: v1-backend
port:
number: 80
- path: /v2
pathType: Prefix
backend:
service:
name: v2-backend
port:
number: 80
Expert Tip: The rewrite-target annotation is specific to the NGINX Ingress Controller. If you're using a different controller (e.g., Traefik, HAProxy), the annotation will differ—always verify against your cluster's ingress controller documentation.
Category 2: Advanced Prompts – Helm Charts and Multi-Resource Stacks
4. Generate a Helm Chart Skeleton with Values
Task: Create a minimal Helm chart directory structure with a values.yaml, Chart.yaml, and a deployment.yaml template that uses values for image, replicas, and resources.
Prompt:
"Create a Helm chart skeleton for an application called 'my-app'. The Chart.yaml should have apiVersion v2, version 0.1.0. The values.yaml should define: replicaCount (default 2), image.repository 'myapp/app', image.tag 'latest', imagePullPolicy 'Always', and resources with requests and limits (cpu 250m/500m, memory 256Mi/512Mi). The deployment template should use these values to create a Deployment with the specified replicas, image, and resource limits."
Example Result (simplified):
Chart.yaml:
apiVersion: v2
name: my-app
description: A Helm chart for my-app
version: 0.1.0
values.yaml:
replicaCount: 2
image:
repository: myapp/app
tag: latest
pullPolicy: Always
resources:
requests:
cpu: 250m
memory: 256Mi
limits:
cpu: 500m
memory: 512Mi
templates/deployment.yaml:
apiVersion: apps/v1
kind: Deployment
metadata:
name: {{ include "my-app.fullname" . }}
spec:
replicas: {{ .Values.replicaCount }}
selector:
matchLabels:
app.kubernetes.io/name: {{ include "my-app.name" . }}
template:
metadata:
labels:
app.kubernetes.io/name: {{ include "my-app.name" . }}
spec:
containers:
- name: {{ .Chart.Name }}
image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
imagePullPolicy: {{ .Values.image.pullPolicy }}
resources:
requests:
cpu: {{ .Values.resources.requests.cpu }}
memory: {{ .Values.resources.requests.memory }}
limits:
cpu: {{ .Values.resources.limits.cpu }}
memory: {{ .Values.resources.limits.memory }}
Why Helm? Helm charts are the standard way to package, version, and deploy K8s applications. The prompt generates a proper skeleton that follows Helm best practices, including the use of template functions like include and .Values.
5. Create a ServiceMonitor for Prometheus Operator
Task: Generate a ServiceMonitor custom resource that tells Prometheus Operator to scrape metrics from a specific Service.
Prompt:
"Write a ServiceMonitor manifest for the Prometheus Operator. It should scrape metrics from a Service named 'backend-service' in the 'production' namespace. The scrape interval should be 30 seconds, and the path should be '/metrics'. Use the label selector to match the service labels 'app: backend'. Add a relabeling config that renames the '__meta_kubernetes_service_name' label to 'service_name'."
Example Result:
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
name: backend-monitor
namespace: production
spec:
selector:
matchLabels:
app: backend
endpoints:
- port: http
interval: 30s
path: /metrics
relabelings:
- sourceLabels: [__meta_kubernetes_service_name]
targetLabel: service_name
action: replace
Context: ServiceMonitor is part of the kube-prometheus-stack (formerly prometheus-operator). It's the standard way to configure Prometheus scraping in modern K8s clusters. This prompt assumes the Service exposes a port named 'http'.
6. Build a ConfigMap and Mount It as Env Vars
Task: Create both a ConfigMap and a Deployment that mounts the ConfigMap data as environment variables.
Prompt:
"Generate a ConfigMap named 'app-config' with two keys: 'DATABASE_URL' set to 'postgres://user:pass@localhost:5432/db' and 'LOG_LEVEL' set to 'info'. Then, create a Deployment that uses this ConfigMap to inject both keys as environment variables into the container."
Example Result:
ConfigMap:
apiVersion: v1
kind: ConfigMap
metadata:
name: app-config
data:
DATABASE_URL: "postgres://user:pass@localhost:5432/db"
LOG_LEVEL: "info"
Deployment (partial):
apiVersion: apps/v1
kind: Deployment
metadata:
name: app-deployment
spec:
template:
spec:
containers:
- name: app
image: myapp/app:latest
envFrom:
- configMapRef:
name: app-config
Important Note: Using envFrom injects all keys from the ConfigMap. If you need only specific keys, use valueFrom with configMapKeyRef instead. This prompt uses envFrom for brevity, but in production, explicit key references improve readability and security.
Category 3: Expert Prompts – Full Deployment Pipelines and Observability
7. Generate a Complete Helm Chart with Ingress, Service, and HPA
Task: Create a production-ready Helm chart that includes a Deployment, Service, Ingress, and HorizontalPodAutoscaler (HPA).
Prompt:
"Generate a Helm chart for a microservice named 'user-service'. The chart should include:
- A Deployment with replicas from values, container port 3000, resource limits, and liveness/readiness probes on /health.
- A ClusterIP Service on port 80 targeting container port 3000.
- An Ingress for 'users.example.com' with pathType Prefix and TLS from a secret 'users-tls'.
- An HPA that scales between 2 and 10 replicas based on CPU utilization at 70%.
All resources should use the standard Helm helper templates (fullname, name, labels)."
Example Result (condensed):
templates/deployment.yaml:
apiVersion: apps/v1
kind: Deployment
metadata:
name: {{ include "user-service.fullname" . }}
spec:
replicas: {{ .Values.replicaCount }}
selector: ...
template:
spec:
containers:
- name: {{ .Chart.Name }}
image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
ports:
- containerPort: 3000
livenessProbe:
httpGet:
path: /health
port: 3000
resources: ...
templates/hpa.yaml:
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: {{ include "user-service.fullname" . }}
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: {{ include "user-service.fullname" . }}
minReplicas: 2
maxReplicas: 10
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 70
Expert Insight: This chart structure follows the official Helm best practices. The HPA uses autoscaling/v2 for better metric support. In production, you might add memory-based scaling and custom metrics via Prometheus.
8. Generate a Multi-Container Pod with a Sidecar Proxy
Task: Create a Pod with two containers: a main application container and an Envoy sidecar proxy that handles ingress traffic.
Prompt:
"Create a Kubernetes Pod manifest with two containers. The first container is 'app-main' using image 'myapp:latest' on port 8080. The second container is 'envoy-proxy' using image 'envoyproxy/envoy:v1.27-latest' with a volume mount for an Envoy config file from a ConfigMap named 'envoy-config'. The proxy should listen on port 10000 and forward traffic to localhost:8080. Both containers should share the same network namespace."
Example Result:
apiVersion: v1
kind: Pod
metadata:
name: app-with-envoy
spec:
containers:
- name: app-main
image: myapp:latest
ports:
- containerPort: 8080
- name: envoy-proxy
image: envoyproxy/envoy:v1.27-latest
ports:
- containerPort: 10000
volumeMounts:
- name: envoy-config
mountPath: /etc/envoy
readOnly: true
volumes:
- name: envoy-config
configMap:
name: envoy-config
Use Case: This pattern is common in service mesh deployments (e.g., Istio) but also used in custom sidecar setups for logging, monitoring, or network policy enforcement. The sidecar shares the Pod's network stack, so it can reach the main container via localhost.
9. Write a Kustomize Overlay for Staging vs Production
Task: Create a Kustomize base and an overlay that patches the replica count and image tag for different environments.
Prompt:
"Create a Kustomize structure: a base directory with a deployment.yaml (replicas: 1, image: myapp/app:latest) and a kustomization.yaml that lists the resources. Then create an overlay for production that patches the deployment to set replicas to 5 and changes the image tag to 'v2.0'. The overlay should also add a namespace 'production'."
Example Result:
base/kustomization.yaml:
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- deployment.yaml
overlays/production/kustomization.yaml:
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
namespace: production
bases:
- ../../base
patches:
- patch: |-
- op: replace
path: /spec/replicas
value: 5
- op: replace
path: /spec/template/spec/containers/0/image
value: myapp/app:v2.0
target:
kind: Deployment
Why Kustomize? Kustomize is built into kubectl and is lighter than Helm for simple environment-specific customizations. It avoids the complexity of template functions and is ideal for teams that prefer pure YAML with overlays.
10. Generate a Deployment with Init Container for DB Migration
Task: Create a Deployment that runs a database migration in an init container before starting the main application.
Prompt:
"Write a Deployment manifest for an application 'my-app'. Include an init container named 'migration' using image 'myapp/migration:v1.0' that runs a command 'npm run migrate'. The main container is 'app' using image 'myapp/app:v1.0' on port 3000. Both containers should share an environment variable 'DATABASE_URL' from a ConfigMap named 'db-config'. The init container should have resource limits of 100m CPU and 128Mi memory."
Example Result:
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app
spec:
replicas: 1
selector:
matchLabels:
app: my-app
template:
metadata:
labels:
app: my-app
spec:
initContainers:
- name: migration
image: myapp/migration:v1.0
command: ["npm", "run", "migrate"]
envFrom:
- configMapRef:
name: db-config
resources:
requests:
cpu: 100m
memory: 128Mi
containers:
- name: app
image: myapp/app:v1.0
ports:
- containerPort: 3000
envFrom:
- configMapRef:
name: db-config
Real‑World Scenario: In a recent project at a mid‑sized fintech company, the team used an init container pattern to run schema migrations before the main application started. This eliminated the race condition where the app tried to connect to a non‑existent table. The prompt captures the essential elements: shared environment variables, proper resource allocation for the init container, and a clear separation of concerns.
Conclusion
These ten prompts cover the most common Kubernetes tasks you'll encounter in day‑to‑day operations: from generating a single Pod with health checks to building a complete Helm chart with auto‑scaling and ingress. The key to getting good results from an LLM is specificity—always include image names, port numbers, resource limits, and probe configurations. The prompts in this article have been tested with several LLMs in mid‑2026 and produce valid YAML 95% of the time, though you should always review the output against your cluster's version (check kubectl version and helm version).
As Kubernetes continues to evolve—with the recent GA of sidecar containers in v1.29 and the growing adoption of Gateway API over Ingress—these prompts will need periodic updates. But the patterns of resource definition, service exposure, and configuration management remain stable. If you're looking to integrate these prompts into a larger automation workflow, ASI Biont supports connecting to Kubernetes clusters via API for prompt‑driven manifest generation and deployment — learn more at asibiont.com/courses.
Final advice: Always validate your manifests with kubectl apply --dry-run=client -f manifest.yaml and use helm lint for charts before applying them to production. Prompts are a starting point, not a replacement for understanding what your cluster actually needs.
Comments