GitOps и Helm без боли: 25 промтов для LLM, которые закрывают деплой, автомасштабирование и секреты в Kubernetes

Промты для Kubernetes и CI/CD: как настроить деплой, HPA и секреты без ночных дежурств

Ночные дежурства — бич DevOps-инженеров. Падающие пайплайны, неверные манифесты, секреты в открытом виде, HPA, который не масштабирует, — всё это требует времени и нервов. Но что, если превратить рутину в диалог с LLM? В этой подборке — проверенные промты, которые помогают писать манифесты, настраивать CI/CD, управлять секретами и чинить пайплайны. Каждый промт — с примером и пояснением.

1. Генерация Deployment и Service для нового микросервиса

Проблема: Нужно быстро создать манифесты для нового сервиса на Python с портом 8000, но не хочется вспоминать все поля.

Промт:

Ты — опытный DevOps-инженер. Сгенерируй Kubernetes Deployment и Service для микросервиса на Python (FastAPI), который слушает порт 8000. Требования:
- 3 реплики
- образ myregistry/myapp:v1.2.3
- liveness и readiness пробу на /health
- requests: cpu 100m, memory 128Mi; limits: cpu 500m, memory 256Mi
- Service типа ClusterIP
Выведи YAML с комментариями.

Пример вывода:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp
        image: myregistry/myapp:v1.2.3
        ports:
        - containerPort: 8000
        livenessProbe:
          httpGet:
            path: /health
            port: 8000
        readinessProbe:
          httpGet:
            path: /health
            port: 8000
        resources:
          requests:
            cpu: 100m
            memory: 128Mi
          limits:
            cpu: 500m
            memory: 256Mi
---
apiVersion: v1
kind: Service
metadata:
  name: myapp
spec:
  selector:
    app: myapp
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8000
  type: ClusterIP

Результат: Экономия 15–20 минут на написание и отладку.

2. Настройка HPA с кастомными метриками

Проблема: HPA не масштабирует, потому что метрики CPU недостаточно. Нужно масштабировать по количеству запросов в секунду (RPS).

Промт:

Настрой Horizontal Pod Autoscaler для Deployment myapp. Требуется масштабирование по кастомной метрике http_requests_per_second (целевое значение 1000 RPS). Используй Prometheus Adapter. Опиши шаги: установка адаптера, создание правила, манифест HPA.

Пример вывода (сокращённо):
1. Установка Prometheus Adapter через Helm.
2. ConfigMap с правилом:

rules:
- seriesQuery: 'http_requests_total{namespace!="",pod!=""}'
  resources:
    overrides:
      namespace: {resource: "namespace"}
      pod: {resource: "pod"}
  name:
    matches: "^(.*)_total"
    as: "${1}_per_second"
  metricsQuery: 'sum(rate(<<.Series>>{<<.LabelMatchers>>}[2m])) by (<<.GroupBy>>)'

1. HPA:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: myapp-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: myapp
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Pods
    pods:
      metric:
        name: http_requests_per_second
      target:
        type: AverageValue
        averageValue: 1000

Результат: HPA работает корректно, масштабирование происходит плавно.

3. Безопасное управление секретами через External Secrets Operator

Проблема: Секреты хранятся в Git в base64 — это небезопасно. Нужно интегрировать с HashiCorp Vault.

Промт:

Настрой External Secrets Operator для синхронизации секретов из Vault в Kubernetes. Приложение myapp требует секреты: DB_PASSWORD, API_KEY. Опиши установку ESO, создание SecretStore и ExternalSecret.

Пример вывода:

apiVersion: external-secrets.io/v1beta1
kind: SecretStore
metadata:
  name: vault-backend
spec:
  provider:
    vault:
      server: "https://vault.example.com"
      path: "secret"
      version: "v2"
      auth:
        kubernetes:
          mountPath: "kubernetes"
          role: "myapp-role"
---
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: myapp-secrets
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: vault-backend
    kind: SecretStore
  target:
    name: myapp-secret
  data:
  - secretKey: DB_PASSWORD
    remoteRef:
      key: secret/data/myapp
      property: db_password
  - secretKey: API_KEY
    remoteRef:
      key: secret/data/myapp
      property: api_key

Результат: Секреты не попадают в Git, автоматически обновляются.

4. Отладка падающего пайплайна GitHub Actions

Проблема: Пайплайн падает на шаге сборки Docker-образа с ошибкой "permission denied".

Промт:

Мой GitHub Actions пайплайн падает на шаге docker build с ошибкой "permission denied while trying to connect to the Docker daemon socket". Как исправить? Вот фрагмент workflow: ...

Пример вывода:
Ошибка возникает, потому что runner не имеет прав на сокет Docker. Решение: добавить шаг с sudo chmod 666 /var/run/docker.sock или использовать docker/setup-buildx-action. Также можно запускать сборку через docker buildx.

Результат: Пайплайн починен, деплой проходит.

5. GitOps с Argo CD: автоматическая синхронизация

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

Промт:

Настрой Argo CD для синхронизации приложения из репозитория https://github.com/myorg/myapp-manifests. Приложение должно автоматически синхронизироваться при коммите в ветку main. Опиши установку Argo CD, создание Application.

Пример вывода:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: myapp
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/myorg/myapp-manifests
    targetRevision: main
    path: overlays/prod
  destination:
    server: https://kubernetes.default.svc
    namespace: myapp
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

Результат: GitOps работает, ручные правки исключены.

6. Создание Helm-чарта для типового сервиса

Проблема: Нужно упаковать манифесты в Helm-чарт для переиспользования.

Промт:

Создай Helm-чарт для микросервиса. Включи Deployment, Service, Ingress, HPA. Параметризуй: image.repository, image.tag, replicas, resources, ingress.host. Выведи структуру файлов и содержимое values.yaml и templates/deployment.yaml.

Пример вывода (values.yaml):

replicaCount: 3
image:
  repository: myregistry/myapp
  tag: v1.2.3
  pullPolicy: IfNotPresent
resources:
  requests:
    cpu: 100m
    memory: 128Mi
  limits:
    cpu: 500m
    memory: 256Mi
ingress:
  enabled: true
  host: myapp.example.com

Результат: Чарт готов, можно использовать для разных окружений.

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

Проблема: Под постоянно перезапускается с ошибкой CrashLoopBackOff. Нужно быстро найти причину.

Промт:

Под в Kubernetes падает с CrashLoopBackOff. Как диагностировать? Опиши пошаговый план: какие команды выполнить, на что смотреть в логах и событиях.

Пример вывода:
1. kubectl describe pod <pod> — смотреть Events.
2. kubectl logs <pod> --previous — логи предыдущего запуска.
3. Проверить liveness-пробу: возможно, приложение не успевает стартовать.
4. Проверить ресурсы: нехватка памяти может вызывать OOMKilled.
5. Проверить конфигурацию: секреты, volumes.

Результат: Причина найдена — неверный путь к секрету.

8. Настройка Canary-деплоя с Flagger

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

Промт:

Настрой canary-деплой с Flagger для приложения myapp. Используй Istio для маршрутизации. Опиши установку Flagger, создание Canary-ресурса с шагами: 20% трафика, пауза 5 минут, затем 50%, затем 100%. Автоматический откат при ошибках.

Пример вывода:

apiVersion: flagger.app/v1beta1
kind: Canary
metadata:
  name: myapp
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: myapp
  service:
    port: 80
    gateways:
    - istio-system/public-gateway
    hosts:
    - myapp.example.com
  analysis:
    interval: 1m
    threshold: 5
    stepWeight: 20
    maxWeight: 100
    metrics:
    - name: request-success-rate
      thresholdRange:
        min: 99
      interval: 1m

Результат: Релизы стали безопаснее, откат автоматический.

9. Генерация CI/CD пайплайна для GitLab CI

Проблема: Нужно написать .gitlab-ci.yml с этапами build, test, deploy.

Промт:

Сгенерируй .gitlab-ci.yml для Python-приложения. Этапы: build (сборка Docker-образа), test (запуск pytest), deploy (в Kubernetes через helm). Используй кэширование, окружения staging и production.

Пример вывода (фрагмент):

stages:
  - build
  - test
  - deploy

build:
  stage: build
  script:
    - docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA .
    - docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA

test:
  stage: test
  script:
    - pytest

deploy_staging:
  stage: deploy
  script:
    - helm upgrade --install myapp ./chart --set image.tag=$CI_COMMIT_SHA
  environment:
    name: staging
  only:
    - main

Результат: Пайплайн готов, деплой автоматизирован.

10. Аудит безопасности Kubernetes-манифестов

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

Промт:

Проанализируй мой Deployment на предмет безопасности. Укажи, какие поля отсутствуют: runAsNonRoot, readOnlyRootFilesystem, securityContext, networkPolicy. Предложи исправления.

Пример вывода:
Добавить в spec.template.spec:

securityContext:
  runAsNonRoot: true
  runAsUser: 1000
  readOnlyRootFilesystem: true
  capabilities:
    drop: ["ALL"]

Результат: Манифест соответствует CIS Benchmark.

11. Миграция с Docker Compose на Kubernetes

Проблема: Есть docker-compose.yml, нужно перевести в Kubernetes.

Промт:

Переведи docker-compose.yml в Kubernetes манифесты. Сервисы: web (nginx), db (postgres), redis. Используй Deployment, Service, PersistentVolumeClaim, ConfigMap. Выведи YAML.

Результат: Готовый набор манифестов для запуска в кластере.

12. Автоматическое обновление сертификатов с cert-manager

Проблема: Нужно автоматически получать и обновлять TLS-сертификаты Let's Encrypt.

Промт:

Настрой cert-manager для автоматического получения сертификатов Let's Encrypt. Используй ClusterIssuer с HTTP01 challenge. Опиши установку и создание Ingress с аннотацией.

Пример вывода:

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-prod
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: admin@example.com
    privateKeySecretRef:
      name: letsencrypt-prod
    solvers:
    - http01:
        ingress:
          class: nginx

Результат: Сертификаты обновляются автоматически.

Все эти промты проверены на практике и помогают сократить время на рутину. Главное — не бояться экспериментировать и адаптировать их под свои задачи. Если хотите глубже погрузиться в DevOps и AI, изучите наши курсы на asibiont.com. Помните: автоматизация — ключ к спокойным ночам.