Kubernetes и Terraform в связке с ИИ: 12 промтов, которые спасли мой прод от ночных пожаров
Три часа ночи. Телефон разрывается от алертов: CrashLoopBackOff в проде, Terraform state рассинхронизирован, а ArgoCD показывает OutOfSync. Знакомо? Ещё год назад я тушил такие пожары вручную, пока не начал использовать LLM для генерации и ревью инфраструктурного кода. Сегодня делюсь 12 промтами, которые превратили хаос в предсказуемый GitOps-процесс.
Статья не про «магию ИИ», а про конкретную рутину: от написания манифестов до дебага сетевых политик. Все примеры проверены на реальных кластерах (EKS 1.29, GKE 1.30) и Terraform 1.8+. Под каждым промтом — пояснение, какую задачу он закрывает и что вы получите на выходе.
1. Генерация Deployment с probes и resource limits
Задача: Быстро создать production-ready манифест, не забыв про liveness/readiness probes и requests/limits.
Промт:
Ты — Senior DevOps. Сгенерируй Kubernetes Deployment для приложения на Go (образ myapp:1.2.3).
Требования:
- 3 реплики, стратегия RollingUpdate с maxSurge=1, maxUnavailable=0
- Liveness probe: HTTP GET /healthz на порту 8080, initialDelaySeconds=10
- Readiness probe: HTTP GET /ready на порту 8080, periodSeconds=5
- Resources: requests cpu=100m, memory=128Mi; limits cpu=500m, memory=256Mi
- Env из ConfigMap myapp-config и Secret myapp-secret
- SecurityContext: runAsNonRoot, readOnlyRootFilesystem
Верни только YAML без пояснений.
Результат: Готовый deployment.yaml, который проходит kube-score без замечаний. Экономит 15–20 минут ручного копирования из документации.
2. Ревью манифеста и поиск антипаттернов
Задача: Проверить существующий YAML на типичные ошибки: отсутствие limits, latest тег, hostNetwork: true.
Промт:
Проанализируй манифест ниже как эксперт по Kubernetes Security.
Найди минимум 3 проблемы, связанные с безопасностью и надёжностью.
Для каждой укажи строку, риск и как исправить.
---
<вставьте YAML>
Результат: Список замечаний с приоритетами. Например: «Строка 12: образ с тегом latest — риск неконтролируемого обновления. Исправьте на конкретный digest».
3. Terraform-модуль для VPC с best practices
Задача: Написать переиспользуемый модуль VPC для AWS, соответствующий требованиям CIS Benchmark.
Промт:
Создай Terraform-модуль (AWS provider >= 5.0) для VPC со следующими параметрами:
- 3 public подсети и 3 private подсети в разных AZ
- NAT Gateway только в одной AZ (экономия)
- Flow Logs в CloudWatch с retention 14 дней
- Теги: Environment, Project, Owner
Входные переменные: cidr_block, env, project.
Выходные: vpc_id, private_subnet_ids.
Используй модульную структуру: main.tf, variables.tf, outputs.tf.
Результат: Код, который можно переиспользовать в 10 проектах, не переписывая с нуля. Экономит часы на ревью.
4. Дебаг CrashLoopBackOff по логам
Задача: Быстро понять, почему под падает в цикле, и получить гипотезы для исправления.
Промт:
Под в CrashLoopBackOff. Вот вывод `kubectl describe pod my-pod` и последние 50 строк логов.
Предложи 3 наиболее вероятные причины и команды для проверки каждой.
---
<вставьте describe и логи>
Результат: Список гипотез: «1. OOMKilled — проверьте kubectl get pod my-pod -o jsonpath='{.status.containerStatuses[0].lastState.terminated.reason}'. 2. Ошибка подключения к БД — проверьте секреты». Позволяет сократить время диагностики с 30 до 5 минут.
5. Helm-чарт с values для разных окружений
Задача: Сгенерировать структуру Helm-чарта с параметризацией под dev/staging/prod.
Промт:
Создай Helm-чарт для веб-приложения (nginx + sidecar-контейнер для метрик).
Структура: Chart.yaml, values.yaml, templates/deployment.yaml, templates/service.yaml, templates/ingress.yaml.
Параметризуй: replicaCount, image.tag, ingress.host, resources.
Сделай values-dev.yaml, values-prod.yaml с разными ресурсами.
Используй Helm 3 синтаксис.
Результат: Готовый чарт, который разворачивается одной командой helm install -f values-prod.yaml. Убирает копипаст между окружениями.
6. Настройка ArgoCD Application для GitOps
Задача: Описать Application-манифест для автоматической синхронизации из Git-репозитория.
Промт:
Напиши ArgoCD Application (apiVersion: argoproj.io/v1alpha1) для деплоя приложения из репозитория https://github.com/myorg/k8s-manifests, путь overlays/prod.
Требования:
- Автоматическая синхронизация с prune=true, selfHeal=true
- Игнорировать различия в полях: spec.replicas
- SyncPolicy: CreateNamespace=true
- Проект: default
Результат: Манифест, который ArgoCD подхватит и будет поддерживать состояние кластера в соответствии с Git. Больше никаких ручных kubectl apply.
7. Генерация CI/CD пайплайна для GitHub Actions
Задача: Собрать пайплайн: тесты, сборка Docker-образа, пуш в registry, обновление тега в GitOps-репозитории.
Промт:
Создай GitHub Actions workflow для Go-приложения:
- Триггер: push в main
- Шаги: checkout, setup-go 1.22, go test ./..., сборка образа с тегом ${{ github.sha }}, пуш в ghcr.io
- После пуша: обновить image tag в отдельном репозитории myorg/gitops-config (файл apps/myapp/deployment.yaml) через git commit и push
- Использовать secrets: GITOPS_TOKEN
Результат: Пайплайн, который автоматически обновляет GitOps-репозиторий, а ArgoCD подхватывает изменения. Полный цикл без ручного вмешательства.
8. Диагностика Terraform state lock
Задача: Разблокировать state после падения apply, не сломав инфраструктуру.
Промт:
Terraform apply упал, state заблокирован. Ошибка: «Error acquiring the state lock».
Вот вывод `terraform force-unlock -help` и ID блокировки: 12345.
Опиши пошагово, как безопасно снять блокировку и проверить целостность state.
Результат: Инструкция: «1. Убедитесь, что нет активных операций. 2. Выполните terraform force-unlock 12345. 3. Проверьте terraform plan на расхождения». Снижает риск повреждения state.
9. Написание NetworkPolicy для ограничения трафика
Задача: Разрешить трафик только между конкретными подами, запретив остальное.
Промт:
Сгенерируй NetworkPolicy для namespace backend:
- Разрешить входящий трафик только от подов с меткой app=frontend на порт 8080
- Разрешить исходящий только к подам с меткой app=postgres на порт 5432
- Запретить весь остальной трафик
Результат: YAML с podSelector и namespaceSelector. Помогает закрыть дыры в безопасности без ручного перебора правил.
10. Оптимизация resource requests через VPA-рекомендации
Задача: Снизить затраты, подобрав адекватные requests на основе исторических данных.
Промт:
У меня есть вывод `kubectl top pods` за последние 7 дней. Проанализируй и предложи оптимальные requests/limits для каждого пода, исходя из 95-го перцентиля потребления.
---
<вставьте данные>
Результат: Таблица с рекомендациями: «pod1: requests cpu=200m (было 500m) — экономия 60%». Часто снижает счёт за облако на 20–30%.
11. Генерация Kustomize overlay для мультиокружения
Задача: Собрать базовый манифест и оверлеи для dev/prod без дублирования.
Промт:
Создай структуру Kustomize: base/deployment.yaml, base/service.yaml, overlays/dev/kustomization.yaml, overlays/prod/kustomization.yaml.
В dev: 1 реплика, образ tag dev-latest.
В prod: 3 реплики, образ tag v1.2.3, добавь tolerations для выделенных нод.
Результат: Чистая структура, где изменения в base автоматически подхватываются всеми окружениями. Упрощает поддержку.
12. Настройка Prometheus-алертов на основе SLO
Задача: Создать алерты, которые срабатывают при нарушении SLO, а не по каждому чиху.
Промт:
Напиши PrometheusRule для SLO: 99.9% успешных запросов за 30 дней.
Алерт: если error budget burn rate > 14.4 за 1 час — критический.
Используй метрики: http_requests_total{status=~"5.."} и http_requests_total.
Результат: Правило, которое будит только при реальной деградации. Убирает ночные ложные срабатывания.
Все эти промты я собрал в процессе миграции на GitOps. Они не заменяют инженера, но берут на себя рутину: генерацию шаблонов, первичный ревью, диагностику. Главное — всегда проверяйте вывод ИИ, особенно в Terraform, где ошибка может стоить дорого. Начните с одного-двух промтов, интегрируйте в свой workflow, и вы заметите, как ночные алерты превращаются в редких гостей. А если хотите глубже — изучайте официальную документацию Kubernetes, Terraform и ArgoCD: ИИ лишь ускоряет, но не отменяет понимания.
Комментарии