12 промтов для ChatGPT, с которыми DevOps укрощает кластер: kubectl, Helm и DevSecOps без ночных разборов CrashLoopBackOff

Kubernetes — мощный, но сложный инструмент. Даже опытные DevOps-инженеры тратят часы на написание манифестов, разбор ошибок подов и настройку политик безопасности. ChatGPT (или любой другой LLM) может стать вашим вторым пилотом: он не заменит знание Kubernetes, но ускорит рутину и поможет избежать глупых ошибок. В этой подборке — 12 проверенных промтов, которые я сам использую в работе. Каждый промт — с примером запроса и ожидаемым результатом. Вы сможете адаптировать их под свои задачи и сэкономить время на деплое, отладке и безопасности.

Важно: LLM не всегда даёт идеальный код. Всегда проверяйте сгенерированные манифесты и команды в тестовом кластере. Но даже с этой оговоркой промты ниже экономят мне несколько часов в неделю. Поехали.

1. Генерация Deployment и Service для нового приложения

Промт:

Ты — опытный DevOps-инженер. Напиши манифесты Kubernetes для деплоя приложения: Deployment (3 реплики, образ nginx:1.25, порт 80, ресурсы: requests cpu 100m memory 128Mi, limits cpu 500m memory 256Mi) и Service типа ClusterIP. Добавь liveness и readiness probes на путь /healthz порт 80. Выведи YAML с комментариями.

Ожидаемый результат: Готовый YAML с Deployment и Service, включая пробы. Пример фрагмента:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.25
        ports:
        - containerPort: 80
        resources:
          requests:
            cpu: 100m
            memory: 128Mi
          limits:
            cpu: 500m
            memory: 256Mi
        livenessProbe:
          httpGet:
            path: /healthz
            port: 80
          initialDelaySeconds: 5
          periodSeconds: 10
        readinessProbe:
          httpGet:
            path: /healthz
            port: 80
          initialDelaySeconds: 5
          periodSeconds: 10
---
apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  selector:
    app: nginx
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
  type: ClusterIP

Совет: Уточняйте версию образа и ресурсы — LLM может подставить устаревшие теги.

2. Разбор CrashLoopBackOff: почему под падает?

Промт:

Мой под в Kubernetes постоянно перезапускается с ошибкой CrashLoopBackOff. Вот вывод `kubectl describe pod my-pod-xyz` и `kubectl logs my-pod-xyz --previous`. Проанализируй и предложи шаги для устранения. [вставьте вывод]

Ожидаемый результат: Список возможных причин (нехватка памяти, ошибка в конфиге, отсутствие зависимостей) и конкретные команды для диагностики (например, kubectl exec для проверки файлов). LLM часто указывает на типичные проблемы: неправильный command, отсутствующие env-переменные, ошибки в liveness-пробе.

Пример из практики: Однажды под падал из-за того, что livenessProbe проверял /health слишком часто, а приложение не успевало запуститься. ChatGPT подсказал увеличить initialDelaySeconds. Помогло.

3. Настройка Horizontal Pod Autoscaler (HPA)

Промт:

Сгенерируй манифест HPA для Deployment my-app. Минимальное количество реплик — 2, максимальное — 10. Масштабирование по CPU: целевая загрузка 70%. Также добавь аннотации для сбора метрик Prometheus.

Результат: YAML с apiVersion: autoscaling/v2, metrics типа Resource. Пример:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: my-app-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-app
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70

Важно: HPA требует установленного metrics-server. Проверьте, что он работает.

4. Создание NetworkPolicy для ограничения трафика

Промт:

Напиши NetworkPolicy, которая разрешает входящий трафик к подам с меткой app=backend только от подов с меткой app=frontend на порт 8080. Весь остальной входящий трафик запрещён. Пространство имён — production.

Результат: Манифест с podSelector, ingress.from и ports. Пример:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: backend-allow-frontend
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - protocol: TCP
      port: 8080

Совет: NetworkPolicy работает только если в кластере есть CNI с поддержкой политик (Calico, Cilium, Weave Net).

5. Генерация Helm-чарта с нуля

Промт:

Создай структуру Helm-чарта для приложения на Python (Flask). Включи Deployment, Service, Ingress и ConfigMap. Параметризуй образ, тег, реплики и ресурсы через values.yaml. Выведи список файлов и их содержимое.

Результат: LLM выдаст дерево файлов (Chart.yaml, values.yaml, templates/deployment.yaml и т.д.) и их содержимое. Вы сможете скопировать и доработать. Не забудьте проверить helm lint.

Пример: Я использовал этот промт для быстрого старта нового микросервиса — сэкономил около часа на бойлерплейте.

6. Проверка манифеста на уязвимости (DevSecOps)

Промт:

Проанализируй YAML манифеста Kubernetes на предмет типичных уязвимостей: запуск от root, отсутствие readOnlyRootFilesystem, избыточные capabilities, отсутствие securityContext. Предложи исправления. [вставьте YAML]

Ожидаемый результат: Список проблем и рекомендации: добавить securityContext: { runAsNonRoot: true, readOnlyRootFilesystem: true, capabilities: { drop: ["ALL"] } }. LLM может указать на отсутствие allowPrivilegeEscalation: false.

Ссылка: Официальные рекомендации по безопасности — Kubernetes Security Best Practices.

7. Отладка сети: почему сервис недоступен?

Промт:

Сервис в Kubernetes не отвечает на запросы. Под запущен, но при обращении к ClusterIP получаю timeout. Опиши пошаговый план диагностики с командами kubectl. Учти, что NetworkPolicy может блокировать трафик.

Результат: Пошаговый чек-лист: проверить endpoints (kubectl get endpoints), логи пода, DNS (kubectl run -it --rm debug --image=busybox -- nslookup my-service), правила NetworkPolicy. LLM напомнит про kubectl port-forward для локальной проверки.

8. Написание CI/CD пайплайна для деплоя в Kubernetes

Промт:

Напиши пример пайплайна GitHub Actions для сборки Docker-образа, пуша в Docker Hub и деплоя в Kubernetes (используй kubectl apply). Учти, что kubeconfig хранится в секретах GitHub. Добавь шаг с ожиданием успешного деплоя (kubectl rollout status).

Результат: YAML пайплайна с шагами: checkout, docker build/push, kubectl apply, rollout status. LLM может предложить использовать helm upgrade --install.

Важно: Не храните kubeconfig в открытом виде — используйте секреты.

9. Создание CronJob для периодических задач

Промт:

Сгенерируй манифест CronJob, который каждый час запускает контейнер с образом curlimages/curl и выполняет GET-запрос к http://my-service/api/health. Задача должна завершаться не позднее чем через 5 минут, история хранится 3 успешных и 1 неудачный запуск.

Результат: YAML с schedule: "0 * * * *", activeDeadlineSeconds: 300, successfulJobsHistoryLimit: 3, failedJobsHistoryLimit: 1.

10. Настройка ResourceQuota и LimitRange для namespace

Промт:

Создай ResourceQuota для namespace production, ограничивающую суммарные запросы CPU — 4 ядра, память — 8Gi. Также создай LimitRange с дефолтными лимитами для контейнеров: cpu 500m, memory 512Mi. Выведи два манифеста.

Результат: Два YAML-файла. ResourceQuota контролирует суммарное потребление, LimitRange задаёт дефолты для подов без явных лимитов.

Совет: Без LimitRange поды могут не иметь лимитов, что приведёт к перерасходу ресурсов.

11. Генерация StatefulSet для базы данных

Промт:

Напиши StatefulSet для PostgreSQL 15 с тремя репликами. Используй volumeClaimTemplates для хранения данных (5Gi). Добавь headless Service для доступа к подам. Опиши, как настроить репликацию.

Результат: StatefulSet с serviceName, volumeClaimTemplates, headless Service. LLM может дать базовые инструкции по настройке потоковой репликации (через env-переменные или конфиг).

Важно: StatefulSet требует тщательной настройки, особенно для баз данных. Проверяйте сгенерированное в тестовой среде.

12. Аудит безопасности кластера с помощью промта

Промт:

Ты — аудитор Kubernetes. Перечисли 10 наиболее критичных настроек безопасности, которые часто упускают в production-кластерах. Для каждой дай команду kubectl для проверки или пример манифеста, который исправляет проблему.

Ожидаемый результат: Список: включён ли RBAC, отключён ли анонимный доступ к API, используются ли NetworkPolicy, сканируются ли образы на уязвимости, настроен ли PodSecurityPolicy (или Pod Security Standards), ограничены ли права сервисных аккаунтов и т.д. С конкретными командами, например kubectl auth can-i --list.

Ссылка: CIS Kubernetes Benchmark — авторитетный источник по безопасности.

Эти 12 промтов покрывают основные задачи DevOps при работе с Kubernetes. Они не заменят глубокого понимания системы, но помогут быстрее писать манифесты, находить ошибки и закрывать дыры в безопасности. Главное — всегда проверяйте результат в тестовом кластере и не давайте LLM слепо управлять production. Используйте промты как ускоритель, а не как замену инженерному мышлению.

Попробуйте внедрить хотя бы пару из них в свой ежедневный workflow — и вы заметите, как освобождается время для более интересных задач. А если у вас есть свои проверенные промты для Kubernetes — делитесь в комментариях.