Kubernetes без боли: 12 промтов, которые превратят вас в DevOps-мага (и сэкономят 20 часов в месяц)

Kubernetes без боли: 12 промтов, которые превратят вас в DevOps-мага (и сэкономят 20 часов в месяц)

Если вы DevOps-инженер, то знаете: 80% времени уходит не на «магию» оркестрации, а на рутину. Написать манифест, придумать Helm-чарт, найти, почему под падает в CrashLoopBackOff, оптимизировать ресурсы... Руки чешутся автоматизировать это всё. И да, вы правильно думаете: AI-промты могут взять на себя значительную часть этой работы. Я собрал 12 промтов, которые реально использую в своей работе — от написания манифестов до отладки подов. Каждый проверен на практике, каждый экономит мне часы. Погнали.

1. Генерация манифеста Deployment с нуля

Проблема: Каждый раз писать Deployment с нуля — это как заново изобретать велосипед. Особенно когда нужны специфические параметры: liveness-пробы, ресурсы, affinity.

Промт:

Сгенерируй Kubernetes Deployment манифест для приложения на Node.js (образ myapp:latest). Включи:
- 3 реплики
- livenessProbe: HTTP GET /health на порт 3000
- resources: requests: cpu 100m, memory 128Mi; limits: cpu 500m, memory 256Mi
- nodeSelector: disktype=ssd
- стратегия обновления: RollingUpdate с maxUnavailable: 1 и maxSurge: 1

Добавь комментарии к каждому полю, объясняющие его назначение.

Пример использования:
Вы вставили этот промт в ChatGPT — и получили готовый манифест за 10 секунд. Вместо того чтобы вспоминать синтаксис и искать примеры в документации, вы просто копируете результат. Экономия: минимум 15 минут на каждый манифест.

Почему это работает: Модель обучена на огромном количестве примеров из документации Kubernetes и реальных конфигов. Она знает синтаксис и лучшие практики. Вы получаете не просто код, а код с комментариями — это помогает в обучении новичков и ускоряет код-ревью.

2. Написание Helm-чарта для микросервиса

Проблема: Helm-чарты — это мощно, но писать их с нуля — мука. Особенно когда нужно учесть все возможные параметры values.yaml.

Промт:

Создай структуру Helm-чарта для микросервиса user-service. Включи:
- deployment.yaml
- service.yaml (ClusterIP)
- hpa.yaml (HorizontalPodAutoscaler, min: 2, max: 10, targetCPU: 70%)
- values.yaml с параметрами: replicaCount, image.repository, image.tag, service.port, resources, autoscaling
- В шаблонах используй .Values для всех параметров

Объясни, что делает каждый файл.

Пример использования:
Вы получили полный каркас чарта с правильными шаблонами и values. Останется только подставить свои значения. Это экономит не 15 минут, а пару часов — особенно если вы не пишете чарты каждый день.

3. Оптимизация Dockerfile для уменьшения размера образа

Проблема: Образы раздуваются, деплой тормозит, все недовольны.

Промт:

Вот Dockerfile для Python-приложения:

FROM python:3.11
WORKDIR /app
COPY requirements.txt .
RUN pip install -r requirements.txt
COPY . .
CMD ["python", "app.py"]

Предложи оптимизации для уменьшения размера образа: используй multi-stage build, выбери более легкий базовый образ (например, python:3.11-slim или alpine), очисти кэш pip. Дай итоговый Dockerfile и объясни, почему каждая оптимизация помогает.

Пример использования:
Модель предложит использовать python:3.11-slim, добавить .dockerignore, объединить RUN команды. В итоге образ уменьшился с 1.2GB до 350MB — деплой стал заметно быстрее.

4. Диагностика пода в статусе CrashLoopBackOff

Проблема: Под падает, логи не очевидны, вы тратите часы на дебаг.

Промт:

Мой под в Kubernetes падает с CrashLoopBackOff. Логи:

Error: failed to start container "my-container": Error response from daemon: OCI runtime create failed: container_linux.go:345: starting container process caused "exec: \"/app/start.sh\": stat /app/start.sh: no such file or directory"

Что может быть причиной? Как исправить? Дай команды для диагностики.

Пример использования:
Модель сразу скажет: скорее всего, в Dockerfile не скопирован start.sh или неверный путь. Подскажет проверить kubectl describe pod, kubectl logs, и даст пример исправления. Экономия: час дебага превращается в 10 минут.

5. Написание Kubernetes-оператора на Python

Проблема: Нужно автоматизировать управление кастомным ресурсом, но с нуля писать оператор — это дни работы.

Промт:

Напиши простой Kubernetes-оператор на Python с использованием kopf. Оператор должен:
- Слушать события для CRD "MyResource" (группа example.com, версия v1)
- При создании MyResource создавать Deployment с именем из spec.name и образом из spec.image
- При удалении MyResource удалять соответствующий Deployment
- Обновлять статус MyResource: status.deploymentReady = true, когда Deployment готов

Дай полный код оператора и пример CRD YAML.

Пример использования:
Вы получаете рабочий код оператора, который можно сразу адаптировать. Это не просто шаблон, а полноценная реализация. Экономия: дни работы превращаются в часы.

6. Генерация политик NetworkPolicy

Проблема: Нужно ограничить сетевой трафик между сервисами, но правила сложные, и легко ошибиться.

Промт:

Создай NetworkPolicy для namespace "production", которая:
- Разрешает входящий трафик к подам с меткой app: web только с подов с меткой app: api
- Разрешает исходящий трафик от подов с меткой app: api только к подам с меткой app: db (порт 5432)
- Запрещает весь остальной трафик
- Дай YAML и объясни, как это работает.

Пример использования:
Вы получаете готовый YAML, который можно применить. Модель объяснит, что NetworkPolicy — это allowlist, и покажет, как правильно комбинировать правила. Меньше ошибок — больше безопасности.

7. Поиск утечек памяти в Java-приложении в Kubernetes

Проблема: Приложение в Kubernetes потребляет всё больше памяти, пока не убьют OOMKiller.

Промт:

У меня Java-приложение в Kubernetes, память растет неограниченно. Как найти утечку памяти? Дай пошаговый план:
1. Как собрать heap dump (jmap) и thread dump (jstack) из запущенного контейнера
2. Как проанализировать heap dump с помощью Eclipse MAT
3. Какие параметры JVM добавить для ограничения памяти (например, -XX:MaxRAMPercentage)
4. Как настроить livenessProbe на основе метрик JVM

Дай конкретные команды.

Пример использования:
Модель даст команды kubectl exec, jmap, jstack, объяснит, как включить JMX-экспортер для Prometheus. Вы сможете быстро локализовать утечку — это сэкономит день работы.

8. Автоматизация бэкапов PostgreSQL в Kubernetes

Проблема: Бэкапы БД — критично, но вручную делать их каждый раз — мука.

Промт:

Напиши Kubernetes CronJob для бэкапа PostgreSQL. Используй образ postgres:13-alpine. Задание должно:
- Выполняться каждый день в 2:00 (cron: "0 2 * * *")
- Создавать dump базы данных mydb (используя pg_dump)
- Сжимать его в gzip
- Загружать в S3-совместимое хранилище (например, MinIO) с помощью aws cli
- Хранить бэкапы 7 дней (удалять старые)
- Иметь ресурсы: requests: cpu 200m, memory 256Mi; limits: cpu 500m, memory 512Mi

Дай полный YAML манифест.

Пример использования:
Вы получаете готовый CronJob, который можно сразу применить. Останется только настроить секреты и эндпоинт S3. Экономия: несколько часов на написание и отладку.

9. Создание ServiceAccount и RBAC для CI/CD

Проблема: Нужно дать CI/CD (например, GitLab CI) права на деплой в кластер, но не переборщить с правами.

Промт:

Создай ServiceAccount "ci-deployer" в namespace "production" и RoleBinding, которые дают права:
- get, list, watch, create, update, patch, delete для deployments, services, pods, configmaps, secrets
- get, list, watch для namespaces

Дай YAML для ServiceAccount, Role, RoleBinding. Объясни, почему лучше использовать Role, а не ClusterRole, если деплой только в один namespace.

Пример использования:
Вы получаете минимально необходимые права для CI/CD. Модель объяснит принцип наименьших привилегий. Безопасность — на уровне.

10. Оптимизация ресурсов в кластере: анализ requests и limits

Проблема: Многие поды выставляют requests слишком высокими, кластер перегружен, а реальное потребление низкое.

Промт:

У меня есть список подов в кластере с их requests и limits. Как проанализировать, какие поды переоценивают ресурсы? Дай команды для получения данных из Prometheus (например, container_cpu_usage_seconds_total, container_memory_working_set_bytes) и SQL-запросы для сравнения с requests. Также посоветуй инструменты для автоматической рекомендации requests (например, Vertical Pod Autoscaler, Goldilocks).

Пример использования:
Вы получаете конкретные PromQL-запросы, которые показывают реальное потребление. Модель подскажет, как настроить VPA в режиме recommendation. Вы снижаете requests на 30% — кластер вздыхает свободно.

11. Написание скрипта для очистки старых образов в Harbor/ECR

Проблема: Реестр образов забит старыми тегами, нужно их почистить, но делать это руками — ад.

Промт:

Напиши bash-скрипт для очистки старых образов в Amazon ECR. Скрипт должен:
- Получить список репозиториев (aws ecr describe-repositories)
- Для каждого репозитория получить список тегов с датами (aws ecr list-images, describe-images)
- Удалить теги старше 30 дней (используя aws ecr batch-delete-image)
- Логировать удаленные теги

Дай полный скрипт с обработкой ошибок.

Пример использования:
Вы получаете скрипт, который можно запускать по cron. Он удалит старые образы, освободив место в реестре. Экономия: час ручной работы каждую неделю.

12. Генерация документации по кластеру Kubernetes

Проблема: Нужно составить документацию по кластеру для коллег или аудита, а собирать информацию вручную — долго.

Промт:

Собери информацию о моем Kubernetes-кластере и сгенерируй Markdown-документацию:
- Версия кластера (kubectl version)
- Список нод с их статусом, ролями, версиями kubelet
- Список namespace и количество подов в каждом
- Используемые StorageClass
- Сетевые политики (если есть)

Представь это в виде таблиц и кратких описаний. Если данных нет, укажи это.

Пример использования:
Вы запускаете промт, модель выдает готовый документ, который можно вставить в wiki. Конечно, модель не подключена к кластеру, но она знает, какие команды выполнить, и структурирует вывод. Вы просто выполняете команды и подставляете результаты. Экономия: час на написание структуры.

Бонус: Как я использую эти промты в реальной работе

Теперь немного о том, как встроить эти промты в ваш ежедневный процесс. Я храню их в Notion и просто копирую нужный, когда возникает задача. Для сложных промтов с несколькими шагами я добавляю уточнения: «используй последнюю версию API», «учти, что у нас используется Istio». Это повышает точность ответа.

Ещё один лайфхак: я использую эти промты не только в ChatGPT, но и в других AI-инструментах, таких как Claude или локальные модели. Иногда результат отличается, но базовые принципы работают везде.

Выводы

Эти 12 промтов — не панацея, но они реально экономят мне по 20 часов в месяц. Они помогают быстрее писать манифесты, отлаживать поды и автоматизировать рутину. Главное — не бойтесь экспериментировать и адаптировать промты под свои задачи. Чем точнее вы сформулируете запрос, тем лучше будет результат. Начните с одного промта, попробуйте его в деле — и вы почувствуете разницу.

А какие промты используете вы? Делитесь в комментариях — давайте соберем базу лучших практик!