Каждый раз, когда под падает в CrashLoopBackOff, а kubectl logs показывает пустоту, вспоминаешь одно: хорошо бы рядом был человек, который уже видел эту ошибку. LLM таким напарником становится — но только если дать ему правильную формулировку. Промт «почини мой Kubernetes» возвращает воду. Промт с событиями пода, манифестом и лимитами — конкретный diff.
Ниже — 12 промтов, которые я использую в работе. Каждый проверен на реальных проектах, каждый идёт с примером и ожидаемым результатом. Копируйте, подставляйте свои данные, применяйте.
Сборка образа: от Dockerfile до минимального размера
1. Аудит Dockerfile с расчётом размера слоёв
Промт для случая, когда образ весит 1.5 ГБ, а приложение — 50 МБ кода.
Ты — DevOps-инженер. Проанализируй Dockerfile ниже. Для каждого RUN/COPY/ADD укажи: (1) создаёт ли он новый слой и что в него попадает, (2) что можно объединить или удалить, (3) потенциальный выигрыш в размере. Не предлагай multi-stage, пока не разберёшь текущий. Выведи таблицу: инструкция | проблема | решение | оценка экономии.
Пример: в Dockerfile было RUN apt-get update и отдельно RUN apt-get install -y curl git — кэш apt оставался в слое обновления. LLM указал на это первым пунктом и предложил rm -rf /var/lib/apt/lists/* в той же инструкции. Экономия — десятки мегабайт на ровном месте.
Ожидаемый результат: таблица с приоритетами. Первый пункт чаще всего — не multi-stage, а очистка кэшей пакетных менеджеров.
2. Генерация multi-stage Dockerfile под конкретный стек
Напиши multi-stage Dockerfile для [Python 3.12 / FastAPI / uvicorn]. Требования: builder-стадия ставит зависимости в venv, финальная — slim-образ; пользователь non-root с UID 10001; HEALTHCHECK; кэш pip монтируется через BuildKit (--mount=type=cache). Объясни, почему выбран именно такой базовый образ, и укажи, какие слои инвалидируются при изменении только кода.
Почему это работает: вы просите не просто код, а объяснение инвалидации кэша. LLM отвечает, что COPY requirements.txt идёт до COPY ., — и вы видите, что правки в коде не пересобирают зависимости. Это главный выигрыш multi-stage: время CI падает не от размера образа, а от порядка слоёв.
3. Генерация docker-compose для локального стека
Сгенерируй docker-compose.yml для локальной разработки: [app на Node 20, PostgreSQL 16, Redis 7, MinIO]. Требования: healthcheck для каждого сервиса, depends_on с condition: service_healthy, named volumes для данных, .env-файл для секретов, порты проброшены только на 127.0.0.1. Добавь комментарии, объясняющие каждый параметр healthcheck.
Неочевидный вывод: depends_on без condition: service_healthy гарантирует только порядок запуска контейнеров, а не готовность БД принимать соединения. Приложение стартует, падает на подключении — и в логах это выглядит как ошибка кода. LLM с правильным промтом пишет healthcheck для Postgres через pg_isready — и проблема исчезает.
Kubernetes: манифесты, которые проходят ревью
4. Полный манифест Deployment + Service + Ingress + HPA
Сгенерируй Kubernetes-манифесты для [сервис, образ registry.example.com/app:v1.2.3]: Deployment (3 реплики, requests/limits CPU и memory, securityContext: runAsNonRoot, readOnlyRootFilesystem, drop ALL capabilities), Service ClusterIP, Ingress с TLS, HPA по CPU 70%. Каждый манифест — отдельным YAML-документом с ---. После кода перечисли, какие поля обязательны для production и почему.
Ожидаемый результат: YAML, который проходит kubectl apply --dry-run=server. Второй блок — чеклист: resource requests (без них HPA не работает), readinessProbe (без неё трафик идёт в непрогретый под), securityContext (без него под работает от root).
5. Настройка liveness и readiness-проб
Для приложения [FastAPI, эндпоинт /healthz отвечает за 50 мс, старт занимает ~40 секунд из-за прогрева ML-модели] предложи livenessProbe, readinessProbe и startupProbe. Объясни, почему initialDelaySeconds на liveness — плохая практика и как startupProbe её заменяет. Укажи конкретные значения и расчёт: сколько попыток и за какое время.
Trade-off: агрессивная liveness (periodSeconds: 5, failureThreshold: 3) убивает под через 15 секунд деградации — и вы получаете каскад рестартов под нагрузкой. Мягкая — не замечает зависание. Правильный ответ: liveness редко и терпеливо, readiness часто и строго, startupProbe прикрывает медленный старт.
6. Диагностика CrashLoopBackOff по событиям и логам
Под в CrashLoopBackOff. Вот вывод kubectl describe pod (секция Events) и kubectl logs --previous:
[вставить]
Определи корневую причину. Раздели гипотезы на: (1) проверяемые одной командой, (2) требующие изменения манифеста, (3) требующие изменения образа. Для каждой гипотезы — команда проверки и ожидаемый признак.
Пример: Events показывали OOMKilled с exit code 137. Пользователь думал, что падает приложение. LLM по коду 137 сразу указал на лимит памяти и предложил проверить kubectl top pod и resources.limits.memory. Классика: лимит 256Mi при фактическом потреблении 300Mi.
Важно: kubectl logs --previous — критично. Без флага --previous вы смотрите логи нового контейнера, который ещё не упал, и не видите причину падения старого.
7. Разбор ImagePullBackOff и ErrImagePull
Pod в ImagePullBackOff. Вот describe pod и вывод kubectl get secret [имя] -o yaml (без значений, только типы ключей). Перечисли причины по убыванию вероятности: неверный тег, отсутствие imagePullSecrets, истёкший токен registry, приватный registry без авторизации, несовпадение архитектуры (arm64 vs amd64). Для каждой — команда проверки.
Неочевидно: ImagePullBackOff при правильном теге и рабочем секрете часто означает несовпадение архитектуры. Образ собран на Apple Silicon (arm64), кластер — amd64. В Events это видно как no match for platform in manifest. LLM с полным контекстом называет это в списке, а без контекста — нет.
8. Аудит безопасности контейнера
Проведи аудит безопасности этого манифеста: [вставить]. Проверь по чеклисту: runAsNonRoot, runAsUser, readOnlyRootFilesystem, allowPrivilegeEscalation: false, capabilities drop ALL, seccompProfile, automountServiceAccountToken, secrets не в env. Для каждого нарушения — severity и исправленный фрагмент YAML.
Ожидаемый результат: список с severity. Самое частое — automountServiceAccountToken: true по умолчанию: под получает токен сервис-аккаунта, даже если API ему не нужен. Это лишняя поверхность атаки, которую легко закрыть.
CI/CD и инфраструктура как код
9. GitHub Actions пайплайн с кэшем и матрицей
Напиши GitHub Actions workflow: сборка Docker-образа с BuildKit cache (type=gha), тесты, пуш в registry только на main, тег = git SHA + latest. Матрица по [python 3.11, 3.12]. Объясни, почему кэш BuildKit через actions/cache не работает так же эффективно, как через gha-бэкенд.
Trade-off: кэш через actions/cache экономит время, но растёт в размере и упирается в лимиты хранилища GitHub. type=gha для BuildKit работает на уровне слоёв — эффективнее, но привязан к платформе. Для GitLab CI аналог — cache:docker или registry-based кэш.
10. GitLab CI с ручным gate на production
Сгенерируй .gitlab-ci.yml: стадии build/test/deploy, deploy на staging автоматически, deploy на production — manual. Используй rules вместо only/except. Секреты — через CI/CD variables. Добавь комментарии, объясняющие, почему выбран manual gate и как настроить protected environments.
11. Terraform-модуль для кластера
Напиши Terraform-модуль для [EKS/GKE] кластера: inputs (region, cluster_name, node_count, instance_type), outputs (cluster_endpoint, kubeconfig_command). Используй переменные с validation-блоками. Не включай провайдер-конфигурацию в модуль — только ресурсы. Объясни, почему модуль не должен содержать provider block.
Почему это важно: provider block внутри модуля ломает переиспользование — модуль нельзя подключить с другим провайдером или регионом. LLM без этого указания почти всегда добавляет provider в модуль.
12. Ревью манифестов перед мержем
Ты — ревьюер Kubernetes-манифестов. Вот diff PR: [вставить]. Найди: отсутствующие requests/limits, пробелы без timeout, latest-теги, секреты в plaintext, отсутствие PodDisruptionBudget для multi-replica сервиса. Для каждого замечания — строка и предложенное исправление.
Ожидаемый результат: список замечаний, отсортированный по критичности. Отсутствие PDB — частая находка: при обновлении ноды все поды сервиса эвакуируются одновременно, и сервис недоступен.
Что в итоге
Промт — это не заклинание, а контракт. Чем точнее вы описываете контекст (стек, версии, ограничения, ожидаемый формат ответа), тем меньше итераций. Все 12 формулировок выше объединяет одно: они просят не только код, но и объяснение — почему так, что инвалидируется, чем платим. Именно объяснение превращает LLM из генератора сниппетов в напарника, с которым можно спорить.
Начните с одного промта — например, аудита текущего Dockerfile. Скорее всего, первый же ответ покажет пару лишних слоёв. А если хочется системно разобраться с контейнерами и оркестрацией — посмотрите, как устроены AWS Certified Solutions Architect Professional (SAP-C02): FinOps на практике — как теги, Savings Plans, Compute Optimizer и Graviton обеспечивают реальную оптимизацию затрат AWS и смежные материалы по инфраструктуре в блоге.