Введение
Kubernetes (K8s) — стандарт оркестрации контейнеров в production. По данным Cloud Native Computing Foundation (CNCF) за 2025 год, более 75% организаций используют K8s в продакшене. Но работа с манифестами YAML, Helm-чартами и деплоем часто превращается в рутину: ошибки в отступах, забытые env-переменные, неправильные селекторы. AI-ассистенты вроде ChatGPT или Claude могут сгенерировать 90% кода за секунды.
Я собрал 15 проверенных промтов, которые использую в ежедневной работе. Они покрывают Pod, Service, Ingress, Helm, StatefulSet, NetworkPolicy, отладку и CI/CD. Каждый промт — это не просто шаблон, а готовый запрос с примером вывода. Никакой теории — только практика.
1. Создание Pod с ресурсами и health checks
Промт:
Сгенерируй YAML манифест для Pod с именем web-app, образ nginx:1.25. Укажи requests: cpu 250m, memory 256Mi и limits: cpu 500m, memory 512Mi. Добавь livenessProbe (HTTP GET /health, port 80, initialDelaySeconds 5, periodSeconds 10) и readinessProbe (HTTP GET /ready, port 80, initialDelaySeconds 3, periodSeconds 5).
Пример вывода:
apiVersion: v1
kind: Pod
metadata:
name: web-app
spec:
containers:
- name: nginx
image: nginx:1.25
resources:
requests:
cpu: "250m"
memory: "256Mi"
limits:
cpu: "500m"
memory: "512Mi"
livenessProbe:
httpGet:
path: /health
port: 80
initialDelaySeconds: 5
periodSeconds: 10
readinessProbe:
httpGet:
path: /ready
port: 80
initialDelaySeconds: 3
periodSeconds: 5
Зачем: Без probes Pod не будет перезапущен при зависании, а readiness предотвращает отправку трафика на неготовый контейнер. Это минимальный стандарт для production.
2. Service ClusterIP с селекторами
Промт:
Напиши YAML для Service типа ClusterIP с именем app-svc. Селектор: app: web, tier: frontend. Порт 80 на контейнере (targetPort: 80) и порт 8080 на сервисе. Добавь аннотацию service.beta.kubernetes.io/aws-load-balancer-type: nlb (для будущего переключения на LB).
Пример вывода:
apiVersion: v1
kind: Service
metadata:
name: app-svc
annotations:
service.beta.kubernetes.io/aws-load-balancer-type: "nlb"
spec:
selector:
app: web
tier: frontend
ports:
- port: 8080
targetPort: 80
protocol: TCP
type: ClusterIP
Зачем: ClusterIP — базовый тип для внутренней коммуникации. Селекторы должны точно совпадать с labels Pod, иначе трафик не дойдёт.
3. Ingress с TLS и rewrite-target
Промт:
Сгенерируй Ingress для домена example.com. Путь /api/* направляется на сервис api-svc:8080. Путь /* направляется на web-svc:80. Используй ingress-nginx, добавь rewrite-target: /$2 для /api. TLS с секретом tls-secret.
Пример вывода:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: example-ingress
annotations:
nginx.ingress.kubernetes.io/rewrite-target: /$2
spec:
ingressClassName: nginx
tls:
- hosts:
- example.com
secretName: tls-secret
rules:
- host: example.com
http:
paths:
- path: /api(/|$)(.*)
pathType: ImplementationSpecific
backend:
service:
name: api-svc
port:
number: 8080
- path: /
pathType: Prefix
backend:
service:
name: web-svc
port:
number: 80
Зачем: rewrite-target обязателен для корректной маршрутизации в ingress-nginx. Без него /api/test попадёт в корень сервиса.
4. Helm chart с values.yaml и шаблоном deployment
Промт:
Создай структуру Helm chart с именем my-app. В templates/deployment.yaml — шаблон Deployment с образом {{ .Values.image.repository }}:{{ .Values.image.tag }}, репликами {{ .Values.replicaCount }}, переменными окружения из .Values.env. В values.yaml задай: replicaCount: 2, image.repository: nginx, image.tag: 1.25, env: [{name: NODE_ENV, value: production}].
Пример вывода (values.yaml):
replicaCount: 2
image:
repository: nginx
tag: "1.25"
env:
- name: NODE_ENV
value: production
Пример вывода (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 }}"
env:
{{- toYaml .Values.env | nindent 8 }}
Зачем: Helm — стандарт для управления сложными приложениями. Шаблонизация позволяет переиспользовать чарты для разных окружений.
5. StatefulSet с PersistentVolumeClaim
Промт:
Напиши StatefulSet для PostgreSQL. Имя: postgres-db. 3 реплики, образ postgres:15. Добавь volumeClaimTemplates с запросом 10Gi SSD, storageClassName: fast. Переменные окружения POSTGRES_USER и POSTGRES_PASSWORD из Secret db-secret. Используй serviceName: postgres-headless.
Пример вывода:
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: postgres-db
spec:
serviceName: postgres-headless
replicas: 3
selector:
matchLabels:
app: postgres
template:
metadata:
labels:
app: postgres
spec:
containers:
- name: postgres
image: postgres:15
env:
- name: POSTGRES_USER
valueFrom:
secretKeyRef:
name: db-secret
key: user
- name: POSTGRES_PASSWORD
valueFrom:
secretKeyRef:
name: db-secret
key: password
volumeMounts:
- name: data
mountPath: /var/lib/postgresql/data
volumeClaimTemplates:
- metadata:
name: data
spec:
accessModes: [ "ReadWriteOnce" ]
storageClassName: "fast"
resources:
requests:
storage: 10Gi
Зачем: StatefulSet нужен для stateful-приложений (БД, очереди). Каждый Pod получает уникальный идентификатор и свой PVC — данные не теряются при перезапуске.
6. ConfigMap и Secret для переменных окружения
Промт:
Создай ConfigMap app-config с ключами: TIMEOUT=30, LOG_LEVEL=info. Secret db-secret с ключами: password=base64-password. Затем напиши Pod, который монтирует ConfigMap как env и Secret как env.
Пример вывода:
apiVersion: v1
kind: ConfigMap
metadata:
name: app-config
data:
TIMEOUT: "30"
LOG_LEVEL: info
---
apiVersion: v1
kind: Secret
metadata:
name: db-secret
type: Opaque
data:
password: YmFzZTY0LXBhc3N3b3Jk # base64-encoded
---
apiVersion: v1
kind: Pod
metadata:
name: app-pod
spec:
containers:
- name: app
image: myapp:1.0
envFrom:
- configMapRef:
name: app-config
- secretRef:
name: db-secret
Зачем: ConfigMap для нечувствительных данных, Secret — для паролей и токенов. Никогда не хардкодьте их в образе.
7. HorizontalPodAutoscaler (HPA) на основе CPU
Промт:
Создай HPA для Deployment web-app. Минимум 2 реплики, максимум 10. Автоскейлинг по CPU: targetAverageUtilization 70%. Используй apiVersion autoscaling/v2.
Пример вывода:
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: web-app-hpa
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: web-app
minReplicas: 2
maxReplicas: 10
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 70
Зачем: HPA автоматически масштабирует Pod при нагрузке. Без него вы переплачиваете за idle или падаете при пике.
8. NetworkPolicy для изоляции трафика
Промт:
Напиши NetworkPolicy, которая разрешает входящий трафик только от Pod с label app: frontend к Pod с label app: backend на порт 8080. Исходящий трафик разрешён к Pod с label app: database на порт 5432.
Пример вывода:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: backend-policy
spec:
podSelector:
matchLabels:
app: backend
policyTypes:
- Ingress
- Egress
ingress:
- from:
- podSelector:
matchLabels:
app: frontend
ports:
- port: 8080
egress:
- to:
- podSelector:
matchLabels:
app: database
ports:
- port: 5432
Зачем: По умолчанию весь трафик разрешён. NetworkPolicy — первый шаг к zero-trust безопасности.
9. Job и CronJob для batch-задач
Промт:
Создай Job для однократного выполнения: образ busybox, команда "echo Hello K8s". Затем CronJob, который запускает эту же задачу каждые 5 минут.
Пример вывода:
apiVersion: batch/v1
kind: Job
metadata:
name: hello-job
spec:
template:
spec:
containers:
- name: hello
image: busybox
command: ["echo", "Hello K8s"]
restartPolicy: Never
backoffLimit: 2
---
apiVersion: batch/v1
kind: CronJob
metadata:
name: hello-cron
spec:
schedule: "*/5 * * * *"
jobTemplate:
spec:
template:
spec:
containers:
- name: hello
image: busybox
command: ["echo", "Hello K8s"]
restartPolicy: Never
Зачем: Job для миграций, CronJob для бэкапов или очистки логов.
10. Отладка: kubectl exec и логи
Промт:
Напиши команды для отладки Pod: 1) получить логи Pod my-pod за последние 30 минут с --tail=50, 2) выполнить bash внутри контейнера, 3) проверить описание события (kubectl describe pod) на ошибки ImagePullBackOff. Дай пример вывода ошибки.
Пример вывода:
# Логи
kubectl logs my-pod --since=30m --tail=50
# Интерактивный shell
kubectl exec -it my-pod -- /bin/bash
# Описание Pod для поиска ошибок
kubectl describe pod my-pod | grep -A 5 "Conditions:"
# Пример: Status: ImagePullBackOff, Reason: ErrImagePull
Зачем: 90% проблем с K8s решаются через логи и describe. Это база при деплое.
11. PersistentVolume и PersistentVolumeClaim (статический)
Промт:
Создай статический PV на 50Gi с hostPath /mnt/data, accessMode ReadWriteOnce. Затем PVC, который запрашивает 20Gi и использует этот PV.
Пример вывода:
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv-data
spec:
capacity:
storage: 50Gi
accessModes:
- ReadWriteOnce
hostPath:
path: /mnt/data
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: pvc-data
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 20Gi
Зачем: Для хранения данных вне Pod. В production используйте cloud-диски (EBS, GCE PD) вместо hostPath.
12. InitContainer для ожидания зависимостей
Промт:
Напиши Pod с initContainer, который проверяет доступность БД (postgres:5432) через nc -z, и только после этого запускает основной контейнер приложения.
Пример вывода:
apiVersion: v1
kind: Pod
metadata:
name: app-with-init
spec:
initContainers:
- name: check-db
image: busybox
command: ['sh', '-c', 'until nc -z postgres 5432; do echo waiting for db; sleep 2; done']
containers:
- name: app
image: myapp:1.0
Зачем: InitContainer гарантирует порядок запуска. Без него приложение может стартовать до готовности БД и упасть.
13. Helm-чарт с зависимостями (subcharts)
Промт:
Создай Helm chart my-app, который зависит от subchart postgresql (из Bitnami). В Chart.yaml укажи dependency с именем postgresql, версией 12.x, репозиторием https://charts.bitnami.com/bitnami. Покажи, как переопределить postgresql.auth.postgresPassword в values.yaml.
Пример вывода (Chart.yaml):
dependencies:
- name: postgresql
version: "~12.0"
repository: "https://charts.bitnami.com/bitnami"
Пример вывода (values.yaml):
postgresql:
auth:
postgresPassword: "securepass"
Зачем: Subcharts позволяют переиспользовать готовые решения (БД, Redis) без копирования кода.
14. Rollback и стратегия обновления
Промт:
Настрой Deployment с RollingUpdate: maxSurge=25%, maxUnavailable=25%. Покажи команду для отката на предыдущую ревизию.
Пример вывода:
apiVersion: apps/v1
kind: Deployment
metadata:
name: web-app
spec:
revisionHistoryLimit: 5
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 25%
maxUnavailable: 25%
Команда отката:
kubectl rollout undo deployment/web-app
Зачем: RollingUpdate без downtime. Откат — спасение при неудачном деплое.
15. ResourceQuota и LimitRange для namespace
Промт:
Создай ResourceQuota для namespace dev: max CPU 4 cores, memory 8Gi, max pods 10. LimitRange: min CPU 100m, max CPU 1, default request CPU 200m.
Пример вывода:
apiVersion: v1
kind: ResourceQuota
metadata:
name: dev-quota
namespace: dev
spec:
hard:
requests.cpu: "4"
requests.memory: 8Gi
limits.cpu: "4"
limits.memory: 8Gi
pods: "10"
---
apiVersion: v1
kind: LimitRange
metadata:
name: dev-limits
namespace: dev
spec:
limits:
- defaultRequest:
cpu: 200m
min:
cpu: 100m
max:
cpu: "1"
type: Container
Зачем: Предотвращает «шумных соседей» в мультитенантных кластерах.
Заключение
Эти 15 промтов покрывают 80% задач, с которыми я сталкиваюсь ежедневно: от создания Pod до Helm-чартов и отладки. Сохраните их в свой рабочий файл — они сэкономят часы ручного написания YAML. Но помните: AI генерирует код, но вы отвечаете за его корректность. Всегда проверяйте манифесты через kubectl apply --dry-run=client и тестируйте в staging. K8s — мощный, но ошибки в конфигурации могут стоить downtime.
Попробуйте применить любой промт прямо сейчас: скопируйте в ChatGPT или Claude, адаптируйте под свой проект и деплойте. Увидите разницу в скорости.
Комментарии