Когда я впервые запустил свой кластер Kubernetes, я потратил три дня на debugging пода, который не стартовал. Теперь я трачу три минуты — потому что у меня есть набор проверенных промтов, которые делают 80% рутины за меня. В этой подборке — 12 реальных запросов, которые я использую почти каждый день: от генерации манифестов до оптимизации HPA. Они не заменят опыт, но сэкономят часы, которые лучше потратить на архитектуру.
1. Генерация манифеста для StatefulSet с базой данных
Проблема: Написать корректный StatefulSet для PostgreSQL с persistent volumes, headless-сервисом и init-контейнером для прав доступа — это 15 минут копипасты и поиска ошибок.
Промт:
Сгенерируй манифест StatefulSet для PostgreSQL 16 в Kubernetes. Требования:
- 3 реплики, стратегия обновления RollingUpdate с maxUnavailable=0, maxSurge=1
- Headless-сервис для стабильных DNS-имён (postgres-0.postgres.default.svc.cluster.local)
- PVC через StorageClass с reclaimPolicy: Retain
- Init-контейнер: chown -R 999:999 /var/lib/postgresql/data
- Ресурсы: requests (cpu: 500m, memory: 1Gi), limits (cpu: 1, memory: 2Gi)
- Liveness и readiness пробы: pg_isready
- Конфиг через ConfigMap для postgresql.conf
- Используй apiVersion apps/v1
Результат: Полный YAML-манифест, готовый к kubectl apply. Я экономлю минимум 20 минут на каждом новом окружении. Главное — проверяй версии образов и параметры под свою нагрузку.
2. Диагностика CrashLoopBackOff за 30 секунд
Проблема: Под перезапускается, логи путаются, дедлайн горит.
Промт:
Под nginx-7f8b9c5d4e-abc12 в namespace production находится в CrashLoopBackOff. Выполни диагностику:
1. Проверь последние события: kubectl describe pod ... | tail -20
2. Посмотри логи предыдущего контейнера: kubectl logs ... --previous
3. Проверь статус: kubectl get pod -o wide
4. Проверь квоты и лимиты: kubectl describe quota
5. Проверь, не превышен ли memory limit: kubectl top pod
Дай пошаговый план действий на основе типичных причин: неверный command, отсутствие зависимостей, превышение лимитов, ошибка конфигурации.
Результат: Чек-лист из 5 шагов, который я прогоняю автоматически. В 70% случаев проблема в лимитах памяти или неверном command — промт сразу это подсвечивает.
3. Автоскейлинг с HPA: настройка и валидация
Проблема: Настроить HPA так, чтобы он не реагировал на случайные всплески и не убивал прод.
Промт:
Создай HPA для деплоймента api-gateway (namespace prod) на основе custom metrics (Prometheus Adapter). Требования:
- Метрика: http_requests_per_second (rate за 1m)
- targetAverageValue: 100
- minReplicas: 3, maxReplicas: 10
- Поведение: scaleUp стабилизация 60s, политика 100% каждые 15s; scaleDown стабилизация 300s, политика 10% каждые 60s
- Проверь, что метрика доступна: kubectl get --raw /apis/custom.metrics.k8s.io/v1beta1
- Дай команду для проверки текущего статуса: kubectl describe hpa
Результат: YAML HPA с правильными параметрами. Я использую стабилизацию, чтобы избежать флапа. Проверка через custom.metrics API — обязательна, иначе HPA не увидит метрики.
4. Сравнение двух конфигураций Ingress
Проблема: Нужно быстро понять, чем отличаются два Ingress-манифеста, особенно после мержа веток.
Промт:
Сравни два Ingress-манифеста (файлы ingress-old.yaml и ingress-new.yaml). Выведи:
1. Различия в аннотациях (annotations)
2. Различия в правилах маршрутизации (paths, hosts)
3. Различия в TLS-секции
4. Оцени, какие изменения могут привести к простою
5. Дай рекомендации по безопасному переключению (blue-green, canary)
Результат: Структурированный diff + рекомендации. Экономит время на ревью кода, особенно когда кто-то «чуть-чуть поправил» ingress.
5. Оптимизация ресурсов: поиск лишних requests/limits
Проблема: Кластер перегружен, счета растут, а поды стоят без дела.
Промт:
Проанализируй использование ресурсов в кластере Kubernetes:
1. Выведи топ-10 подов по CPU и памяти: kubectl top pods -A --sort-by=cpu
2. Найди поды с requests > фактического использования (больше 3x)
3. Найди поды с отсутствующими limits (риск для узла)
4. Сравни использование с requests и limits, выведи процент использования
5. Дай рекомендации по оптимизации requests/limits для каждого найденного пода
Результат: Список подов, где можно снизить requests без риска. Я регулярно запускаю этот промт и экономлю до 30% стоимости кластера.
6. Безопасность: анализ RBAC на переизбыток прав
Проблема: Слишком широкие права у сервисных аккаунтов — риск безопасности.
Промт:
Проверь RBAC-конфигурацию в кластере:
1. Найди все Role и ClusterRole с правилами, содержащими '*' (все ресурсы и все глаголы)
2. Найди RoleBinding и ClusterRoleBinding, которые привязывают такие роли к сервисным аккаунтам
3. Проверь, не используется ли default service account в подах
4. Дай рекомендации по принципу наименьших привилегий: какие роли заменить, какие удалить
5. Подскажи, как автоматически запретить использование default SA (PodSecurity admission)
Результат: Отчёт + конкретные действия. После применения этого промта я закрыл дыру, где сервисный аккаунт имел доступ ко всем секретам кластера.
7. Автоматизация бэкапов etcd (для kubeadm)
Проблема: Нужен надёжный бэкап etcd, но руки не доходят написать скрипт.
Промт:
Напиши bash-скрипт для бэкапа etcd в кластере kubeadm:
- Используй etcdctl с endpoint https://127.0.0.1:2379
- Сертификаты: /etc/kubernetes/pki/etcd/server.crt, server.key, ca.crt
- Снапшот сохраняй в /backup/etcd-$(date +%Y%m%d-%H%M%S).db
- Храни последние 7 бэкапов, старые удаляй
- Добавь systemd timer для ежедневного запуска в 2:00 AM
- Проверь, что снапшот валиден: etcdctl snapshot status
Результат: Готовый скрипт и юнит systemd. Я запускаю бэкапы автоматически, и теперь восстановление после сбоя — это 10 минут, а не день.
8. Поиск и удаление завершённых подов (Evicted, Completed)
Проблема: Мусорные поды засоряют кластер и мешают читать kubectl get pods.
Промт:
Найди и удали поды в статусе Evicted, Completed или Failed во всех namespace:
1. Команда для поиска: kubectl get pods -A
| grep -E 'Evicted|Completed|Failed'
2. Команда для удаления с подтверждением: kubectl delete pod <name> -n <namespace>
3. Напиши скрипт для автоматической очистки с возрастом > 24h
4. Добавь рекомендации, как избежать появления таких подов (podManagementPolicy, job TTL)
Результат: Чистый кластер. Я запускаю скрипт раз в неделю, и kubectl get pods стал читабельным.
9. Канареечный деплой с Argo Rollouts
Проблема: Страшно выкатывать новую версию на прод без возможности откатиться.
Промт:
Сгенерируй Rollout для Argo Rollouts для деплоймента frontend (nginx):
- Стратегия: canary, шаги: 10% (2 мин), 50% (5 мин), 100%
- Анализ: используй AnalysisTemplate с prometheus-метрикой (error rate > 5% за 2 мин)
- Включи автоматический откат при неудачном анализе
- Дай команды для запуска rollout и ручного продвижения: kubectl argo rollouts promote
- Покажи, как проверить статус: kubectl argo rollouts status
Результат: YAML-манифест с канареечной стратегией. Я больше не боюсь деплоить — если что-то не так, Argo откатит сам.
10. Мониторинг: PromQL-запросы для типичных проблем
Проблема: Нужен быстрый способ проверить здоровье кластера, но не хочется лезть в документацию PromQL.
Промт:
Составь PromQL-запросы для Prometheus, чтобы мониторить Kubernetes:
1. CPU-загрузка узлов: 100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)
2. Память узлов: (1 - sum(node_memory_MemAvailable_bytes) / sum(node_memory_MemTotal_bytes)) * 100
3. Количество подов в CrashLoopBackOff: sum(kube_pod_container_status_restarts_total > 0)
4. Ошибки 5xx в Ingress: sum(rate(nginx_ingress_controller_requests{status=~"5.."}[5m])) by (ingress)
5. Задержка p99: histogram_quantile(0.99, sum(rate(nginx_ingress_controller_request_duration_seconds_bucket[5m])) by (le))
Для каждого запроса дай объяснение, что он показывает и какие пороговые значения считать критическими.
Результат: Набор готовых запросов, которые я вставляю в Grafana-дашборд. Экономит часы на изучение PromQL.
11. Troubleshooting сети: диагностика Service и Endpoints
Проблема: Сервис не отвечает, а DNS резолвится, но трафик не идёт.
Промт:
Помоги диагностировать проблему с сетевым доступом к сервису my-service (namespace default):
1. Команды для проверки: kubectl get endpoints my-service, kubectl describe svc my-service
2. Проверь, что поды имеют нужные label: kubectl get pods --show-labels | grep my-app
3. Проверь targetPort: совпадает ли с портом контейнера (kubectl describe pod)
4. Проверь kube-proxy: kubectl logs -n kube-system kube-proxy-<pod>
5. Если используется NetworkPolicy — проверь, что ingress/egress разрешён
Дай пошаговый алгоритм, начиная с самой вероятной причины.
Результат: Алгоритм из 5 шагов. В 90% случаев проблема в selector. Промт сразу это проверяет.
12. Генерация Dockerfile для приложения на Go
Проблема: Нужен оптимизированный Dockerfile, но не хочется вспоминать все best practices.
Промт:
Создай Dockerfile для Go-приложения (входная точка main.go) с требованиями:
- Многоступенчатая сборка: golang:1.22-alpine для билда, alpine:3.20 для рантайма
- Используй модули, кэшируй зависимости через go mod download
- Скопируй только необходимые файлы, используй .dockerignore
- Собери бинарник с CGO_ENABLED=0, флаг -ldflags "-s -w"
- Запускай от пользователя nobody (UID 65534)
- HEALTHCHECK: wget -qO- http://localhost:8080/health || exit 1
- Ресурсы: минимальный образ, без лишних пакетов
Результат: Dockerfile, который я использую как шаблон для всех Go-сервисов. Размер образа снизился с 800 МБ до 20 МБ.
Этот набор промтов — не серебряная пуля, но он реально ускоряет рутину. Я держу их в заметках и адаптирую под конкретную задачу. Главное — всегда проверяй сгенерированный код: промт может быть отличным черновиком, но финальное слово за тобой. Начни с одного-двух промтов, которые чаще всего нужны, и постепенно расширяй свой арсенал. А если у тебя есть свой любимый промт для Kubernetes — делись в комментариях, я всегда собираю новые идеи.
Комментарии