Промты для Kubernetes и CI/CD: как деплоить, масштабировать и тушить инциденты в проде через диалог с ИИ
В 3:47 ночи падает прод. kubectl get pods показывает CrashLoopBackOff, а Slack уже горит. Раньше я открывал документацию, гуглил, гадал. Теперь я формулирую промт — и через 30 секунд получаю гипотезу, план диагностики и готовые команды. Эта статья — не рассуждения об ИИ, а рабочий арсенал промтов для DevOps-инженеров, которые деплоят, масштабируют и тушат инциденты в Kubernetes и CI/CD.
Подборка построена по трём уровням: базовые промты (генерация манифестов и пайплайнов), продвинутые (Helm, Terraform, секреты, автоскейлинг) и экспертные (отладка инцидентов, трейсинг, security-аудит). Каждый промт я даю в формате «задача → промт → пример результата», как в реальной работе: без воды, с командами, которые можно скопировать и запустить. Синтаксис Kubernetes и CI/CD-конфигов — настоящий, проверенный на кластерах.
Базовый уровень: генерация манифестов и пайплайнов
1. Генерация Deployment с probes и resources
Задача: быстро получить корректный манифест без типичных ошибок — отсутствующих readinessProbe, лимитов и securityContext.
Промт: «Сгенерируй Kubernetes Deployment для Go-сервиса на порту 8080, образ registry.example.com/api:1.2.3. Добавь readinessProbe и livenessProbe на /healthz, requests/limits CPU и memory, securityContext с runAsNonRoot: true и readOnlyRootFilesystem: true. Объясни каждое поле одной строкой.»
Результат: ИИ выдаёт YAML с resources.requests.cpu: 100m, livenessProbe.initialDelaySeconds: 15 и комментариями. Вы проверяете через kubectl apply --dry-run=server -f deployment.yaml — синтаксис валиден.
2. GitLab CI пайплайн с кэшем и стадиями
Задача: собрать пайплайн build → test → deploy без ручного переписывания .gitlab-ci.yml.
Промт: «Напиши .gitlab-ci.yml для Node.js-приложения: стадии build, test, deploy. Используй cache по node_modules, artifacts для собранного дистрибутива, deploy только на теге v*. Добавь rules вместо only (актуальный синтаксис).»
stages: [build, test, deploy]
build:
stage: build
script: ["npm ci", "npm run build"]
cache:
key: ${CI_COMMIT_REF_SLUG}
paths: [node_modules/]
artifacts:
paths: [dist/]
deploy:
stage: deploy
rules:
- if: $CI_COMMIT_TAG
script: ["kubectl apply -f k8s/"]
3. Dockerfile multi-stage
Задача: уменьшить образ и убрать уязвимости из финального слоя.
Промт: «Собери multi-stage Dockerfile для Python-сервиса на FastAPI. Базовый образ — python:3.12-slim. Установи зависимости через pip install --no-cache-dir. Финальный образ — non-root пользователь, без build-tools.»
Результат: ИИ предлагает FROM python:3.12-slim AS builder и FROM python:3.12-slim с USER app. Размер падает с ~900 МБ до ~150 МБ — это подтверждается docker images.
Продвинутый уровень: Helm, Terraform, секреты
4. Helm-чарт с values-схемой
Задача: параметризовать деплой для трёх окружений (dev/staging/prod).
Промт: «Создай структуру Helm-чарта для микросервиса: Chart.yaml, values.yaml, шаблоны deployment.yaml, service.yaml, ingress.yaml. Добавь values.schema.json для валидации обязательных полей image.tag и replicaCount. Покажи, как переопределить значения через -f values-prod.yaml.»
Результат: команда helm template myapp ./chart -f values-prod.yaml | kubectl apply --dry-run=server -f - подтверждает корректность рендеринга.
5. Terraform-модуль для EKS
Задача: поднять кластер без копипаста из примеров.
Промт: «Напиши Terraform-модуль для AWS EKS: aws_eks_cluster, aws_eks_node_group с managed node group, aws_iam_role для узлов. Используй variables.tf для cluster_name, instance_types, desired_size. Добавь outputs.tf с cluster_endpoint и cluster_ca_certificate.»
Результат: terraform plan показывает ожидаемые ресурсы; модуль переиспользуется для dev и prod с разными terraform.tfvars.
6. Управление секретами без плейнтекста
Задача: не хранить пароли в Git.
Промт: «Покажи два подхода к секретам в Kubernetes: (1) External Secrets Operator с AWS Secrets Manager, (2) Sealed Secrets. Дай пример ExternalSecret манифеста и команду kubeseal. Сравни по сложности и безопасности в таблице.»
| Подход | Плюсы | Минусы |
|---|---|---|
| External Secrets | Секреты не в Git, ротация из vault | Нужен доступ к внешнему хранилищу |
| Sealed Secrets | Всё в Git, шифрование | Ротация вручную, ключ кластера критичен |
7. HPA и VPA для автоскейлинга
Задача: масштабировать по CPU, но не переплачивать.
Промт: «Настрой HorizontalPodAutoscaler для Deployment: min 3, max 20 реплик, target CPU 70%. Добавь behavior.scaleDown.stabilizationWindowSeconds: 300, чтобы избежать флаппинга. Объясни, почему VPA и HPA по CPU нельзя включать одновременно без vpa-updater в режиме Off.»
Результат: kubectl get hpa -w показывает плавный рост реплик под нагрузкой без резких скачков.
Экспертный уровень: инциденты, трейсинг, аудит
8. Отладка CrashLoopBackOff
Задача: за 5 минут найти причину падения пода.
Промт: «Под CrashLoopBackOff. Дай пошаговый чек-лист: kubectl describe pod, kubectl logs --previous, проверка exit code. Для exit code 137 объясни разницу между OOMKilled и SIGKILL. Предложи команды для каждого шага.»
Результат: kubectl logs mypod --previous показывает exit code 137, kubectl describe — Reason: OOMKilled. Вывод: поднять resources.limits.memory с 256Mi до 512Mi.
9. Диагностика ImagePullBackOff
Задача: образ не тянется из приватного registry.
Промт: «ImagePullBackOff на приватном registry. Перечисли причины: неверный imagePullSecrets, истёкший токен, опечатка в теге. Дай команды: kubectl get secret, создание docker-registry secret, проверка через kubectl run --rm -it --image=....»
Результат: kubectl create secret docker-registry regcred --docker-server=... --docker-username=... --docker-password=... — и под стартует.
10. Трейсинг запроса через сервисы
Задача: найти, где деградирует latency.
Промт: «Пользователь жалуется на 2-секундный отклик. Объясни, как через OpenTelemetry и Jaeger найти узкое место: trace_id в логах, span-ы по сервисам. Дай пример kubectl port-forward к Jaeger UI и запрос в Elasticsearch по trace_id.»
11. Аудит RBAC и security
Задача: проверить, не выданы ли лишние права.
Промт: «Составь чек-лист аудита RBAC: поиск ClusterRoleBinding с cluster-admin, pods/exec права для сервисных аккаунтов. Дай команды kubectl get clusterrolebindings -o json | jq и kubectl auth can-i --list --as=system:serviceaccount:default:myapp.»
Результат: находите сервисный аккаунт с cluster-admin — типичная ошибка копипаста из туториалов.
12. Откат деплоя за 60 секунд
Задача: быстро вернуть рабочую версию.
Промт: «Расскажи про kubectl rollout undo deployment/myapp --to-revision=3 и helm rollback myapp 2. Сравни, когда что использовать. Добавь проверку kubectl rollout status после отката.»
Результат: откат занимает меньше минуты, rollout status подтверждает готовность.
13. Постмортем по инциденту
Задача: превратить ночной пожар в системное улучшение.
Промт: «Составь шаблон постмортема: таймлайн, root cause (5 Whys), impact, action items с owner и дедлайном. Дай пример заполнения для инцидента с OOMKilled.»
Результат: документ, который через месяц спасает от повторения той же ошибки.
Что реально экономит время
Промты не заменяют понимание Kubernetes — они убирают рутину: синтаксис манифестов, поиск нужного поля, черновик пайплайна. По данным CNCF Annual Survey, адаптация Kubernetes продолжает расти, и объём конфигурации — одна из главных болей команд. ИИ здесь работает как ускоритель, но финальное решение и kubectl apply --dry-run всегда за вами.
Начните с одного промта — например, генерации Deployment с probes. Прогоните через --dry-run, сравните с тем, что писали руками. Через неделю вы будете формулировать промты для инцидентов так же естественно, как kubectl get pods. А чтобы системно прокачать навыки работы с Kubernetes, CI/CD и Terraform — загляните в материалы asibiont.com: там разбираем реальные сценарии, а не абстрактную теорию.
Комментарии