Введение
Kubernetes (K8s) стал стандартом де-факто для оркестрации контейнеров, но его кривая обучения остаётся крутой. Даже опытные инженеры тратят часы на отладку манифестов, поиск правильных параметров для Pod'ов или настройку Ingress. Современные AI-инструменты (вроде GPT-4 или Claude) могут ускорить этот процесс в разы, если правильно формулировать промты. В этой подборке — 10 проверенных промтов, которые помогут вам генерировать корректные YAML-манифесты, Helm-чарты и сценарии деплоя. Каждый промт сопровождается примером результата и пояснением, почему он работает.
1. Промт для создания базового Pod
Задача: Сгенерировать манифест Pod с веб-сервером Nginx, пробросом портов и ограничением ресурсов.
Промт: «Создай YAML-манифест для Pod с именем web-server, образ nginx:1.25, пробрось порт 80, установи requests: cpu 100m, memory 128Mi и limits: cpu 200m, memory 256Mi. Добавь метку app: web.»
Пример результата:
apiVersion: v1
kind: Pod
metadata:
name: web-server
labels:
app: web
spec:
containers:
- name: nginx
image: nginx:1.25
ports:
- containerPort: 80
resources:
requests:
memory: "128Mi"
cpu: "100m"
limits:
memory: "256Mi"
cpu: "200m"
Пояснение: Указание requests и limits — best practice для избежания проблемы «шумных соседей» (noisy neighbor) на кластере. Промт чётко задаёт все ключевые параметры, что минимизирует риск некорректной генерации.
2. Промт для Service типа LoadBalancer
Задача: Создать Service, который балансирует трафик между подами с меткой app: web и предоставляет внешний IP.
Промт: «Напиши YAML для Service типа LoadBalancer, который слушает порт 80 и перенаправляет трафик на порт 8080 подов с меткой app: web.»
Пример результата:
apiVersion: v1
kind: Service
metadata:
name: web-service
spec:
type: LoadBalancer
selector:
app: web
ports:
- port: 80
targetPort: 8080
Пояснение: Важно указывать targetPort, если контейнер слушает нестандартный порт. В облачных провайдерах (AWS, GCP) такой Service автоматически создаёт балансировщик.
3. Промт для Ingress с TLS
Задача: Настроить Ingress для маршрутизации трафика на сервис web-service, с поддержкой SSL и именем хоста example.com.
Промт: «Сгенерируй манифест Ingress для хоста example.com, который маршрутизирует трафик на сервис web-service порт 80. Используй TLS-сертификат из секрета tls-secret.»
Пример результата:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: web-ingress
spec:
tls:
- hosts:
- example.com
secretName: tls-secret
rules:
- host: example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: web-service
port:
number: 80
Пояснение: В современных версиях K8s (1.19+) Ingress использует apiVersion networking.k8s.io/v1. Указание pathType обязательно.
4. Промт для ConfigMap и Secret
Задача: Создать ConfigMap с конфигурацией nginx и Secret с паролем для БД.
Промт: «Создай ConfigMap с именем nginx-config, содержащим nginx.conf с server_name example.com. Также создай Secret с именем db-password, где пароль admin123 закодирован в base64. Покажи, как подключить оба к Pod.»
Пример результата:
apiVersion: v1
kind: ConfigMap
metadata:
name: nginx-config
data:
nginx.conf: |
server {
listen 80;
server_name example.com;
}
---
apiVersion: v1
kind: Secret
metadata:
name: db-password
type: Opaque
data:
password: YWRtaW4xMjM=
Пояснение: Secret хранит данные в base64, но это не шифрование — используйте внешние инструменты вроде Sealed Secrets или Vault для продакшена.
5. Промт для HorizontalPodAutoscaler (HPA)
Задача: Настроить автоскейлинг для Deployment на основе CPU.
Промт: «Создай HPA для Deployment web-deployment, который масштабирует количество подов от 2 до 10, если средняя загрузка CPU превышает 70%.»
Пример результата:
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: web-hpa
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: web-deployment
minReplicas: 2
maxReplicas: 10
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 70
Пояснение: API autoscaling/v2 поддерживает несколько метрик (CPU, memory, custom). Для работы HPA требуется metrics-server.
6. Промт для базового Helm-чарта
Задача: Создать структуру Helm-чарта для микросервиса.
Промт: «Сгенерируй структуру Helm-чарта с именем my-app, включающую Chart.yaml, values.yaml, и шаблоны для Deployment и Service. Используй переменные image.repository и image.tag.»
Пример результата:
# Chart.yaml
apiVersion: v2
name: my-app
description: A Helm chart for my-app
version: 0.1.0
# values.yaml
image:
repository: nginx
tag: latest
replicaCount: 1
# templates/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: {{ .Release.Name }}-deployment
spec:
replicas: {{ .Values.replicaCount }}
selector:
matchLabels:
app: {{ .Release.Name }}
template:
metadata:
labels:
app: {{ .Release.Name }}
spec:
containers:
- name: {{ .Chart.Name }}
image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
Пояснение: Helm использует Go-шаблоны. Промт задаёт минимальную структуру, которую можно расширять.
7. Промт для деплоя через kubectl apply
Задача: Получить команды для деплоя манифестов из папки.
Промт: «Напиши bash-скрипт, который применяет все YAML-файлы из каталога ./manifests, проверяет статус Pod'ов и выводит логи в случае ошибки.»
Пример результата:
#!/bin/bash
kubectl apply -f ./manifests/
if [ $? -ne 0 ]; then
echo "Error applying manifests"
exit 1
fi
kubectl wait --for=condition=Ready pods --all --timeout=60s
if [ $? -ne 0 ]; then
echo "Pods not ready, fetching logs..."
kubectl logs --all-containers --prefix
fi
Пояснение: Скрипт автоматизирует базовый деплой и отладку.
8. Промт для NetworkPolicy
Задача: Ограничить сетевой трафик между подами.
Промт: «Создай NetworkPolicy, которая разрешает входящий трафик только от подов с меткой role: frontend к подам с меткой app: backend на порт 5432.»
Пример результата:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: backend-policy
spec:
podSelector:
matchLabels:
app: backend
ingress:
- from:
- podSelector:
matchLabels:
role: frontend
ports:
- protocol: TCP
port: 5432
Пояснение: По умолчанию все поды могут общаться — NetworkPolicy вводит ограничения, что критично для безопасности.
9. Промт для StatefulSet с PVC
Задача: Развернуть базу данных PostgreSQL с persistent storage.
Промт: «Создай StatefulSet для PostgreSQL с 3 репликами, каждый под использует PersistentVolumeClaim объёмом 10Gi. Добавь сервис headless для доступа к подам.»
Пример результата:
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: postgres
spec:
serviceName: postgres-headless
replicas: 3
selector:
matchLabels:
app: postgres
template:
metadata:
labels:
app: postgres
spec:
containers:
- name: postgres
image: postgres:15
volumeMounts:
- name: data
mountPath: /var/lib/postgresql/data
volumeClaimTemplates:
- metadata:
name: data
spec:
accessModes: [ "ReadWriteOnce" ]
resources:
requests:
storage: 10Gi
Пояснение: StatefulSet гарантирует уникальные идентификаторы подов, что важно для БД.
10. Промт для Job и CronJob
Задача: Создать задачу для бэкапа базы данных.
Промт: «Напиши YAML для CronJob, который каждый день в 2:00 запускает Pod с образом postgres:15 и выполняет pg_dump в /backup.»
Пример результата:
apiVersion: batch/v1
kind: CronJob
metadata:
name: backup-job
spec:
schedule: "0 2 * * *"
jobTemplate:
spec:
template:
spec:
containers:
- name: backup
image: postgres:15
command: ["pg_dump", "-U", "postgres", "-f", "/backup/dump.sql"]
restartPolicy: OnFailure
Пояснение: CronJob использует стандартное crontab-расписание.
Заключение
Эти 10 промтов покрывают 90% повседневных задач инженера K8s: от простых Pod'ов до продвинутых StatefulSet и Helm. Чтобы получить максимальную пользу, адаптируйте промты под свой контекст — указывайте конкретные версии образов, имена проектов и требования к безопасности. Помните: AI — это инструмент, а не замена экспертизе. Всегда проверяйте сгенерированные манифесты на тестовом кластере перед деплоем в продакшен. Используйте эти промты как отправную точку для автоматизации рутины и сосредоточьтесь на архитектуре вашего приложения.
Комментарии