Средний

8 мин

6.6K

^{Материал подготовлен в рамках курса «DevOps. Экспертный уровень».}

Стандартный Kubernetes Deployment устроен очень просто: при выкате новой версии стартует новый ReplicaSet, постепенно заменяющий старый. Решение «продолжать ли выкат» он принимает только на основании readiness/liveness probes, то есть «контейнер живой и принимает трафик». А что в этом контейнере за версия и не разломала ли она бизнес-логику, Deployment не знает и не интересуется.

В большинстве сетапов этого недостаточно. Хочется выкатывать постепенно (canary), анализировать метрики (latency, error rate, доменные KPI) и автоматически останавливать или откатывать выкат, если метрики просели.

В статье поставим Argo Rollouts, развернём Rollout с пошаговым canary, прикрутим AnalysisTemplate, который ходит за метриками в Prometheus, и настроим автоматический откат при отклонениях. Заодно разберём важный момент про трафик — почему setWeight: 10 без service mesh означает не «десять процентов трафика», а «один под из десяти», и что с этим делать.

Argo Rollouts в двух словах

Argo Rollouts — это контроллер, который добавляет в кластер Kubernetes CRD Rollout, заменяющий стандартный Deployment. У Rollout есть всё то же, что у Deployment (template, replicas, selector), плюс стратегия выката — canary (постепенный сдвиг трафика на новую версию) или blueGreen (параллельный запуск двух версий и потом переключение), с поддержкой ручных promote/abort и автоматического анализа.

Самое полезное — analysis. На любом шаге выката можно запустить AnalysisRun, который выполнит запросы к источнику метрик (Prometheus, Datadog, NewRelic, веб-API, кастомный Job) и решит на основе ответа, продолжать выкат или откатываться.

Установка контроллера и CLI

Минимальный вариант установки в кластер:

kubectl create namespace argo-rollouts
kubectl apply -n argo-rollouts \
  -f https://github.com/argoproj/argo-rollouts/releases/latest/download/install.yaml

CLI-плагин для kubectl:

curl -LO https://github.com/argoproj/argo-rollouts/releases/latest/download/kubectl-argo-rollouts-linux-amd64
chmod +x kubectl-argo-rollouts-linux-amd64
sudo mv kubectl-argo-rollouts-linux-amd64 /usr/local/bin/kubectl-argo-rollouts

Дашборд для визуального наблюдения за выкатами:

kubectl argo rollouts dashboard

После этого открывается http://localhost:3100, на котором видно состояние выкатов вживую — какие шаги пройдены, какие AnalysisRun запущены, какие реплики в canary и stable, и какой текущий weight трафика.

Минимальный Rollout с canary

Заменяем Deployment на Rollout — структура почти идентична, spec.template тот же, что был, добавляется strategy.canary со шагами:

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: api
spec:
  replicas: 10
  selector:
    matchLabels:
      app: api
  template:
    metadata:
      labels:
        app: api
    spec:
      containers:
        - name: api
          image: registry.example.com/api:v1.0.0
          ports:
            - containerPort: 8080
  strategy:
    canary:
      steps:
        - setWeight: 10
        - pause: { duration: 5m }
        - setWeight: 25
        - pause: { duration: 5m }
        - setWeight: 50
        - pause: { duration: 5m }
        - setWeight: 100

При выкате новой версии Argo Rollouts создаёт canary ReplicaSet сначала с одним подом из десяти, держит пять минут, потом тремя подами, и так далее. После каждого шага можно вмешаться вручную через kubectl argo rollouts promote или abort.

Управление трафиком: реплики против trafficRouting

Здесь важный момент, который часто понимают неправильно. Без блока trafficRouting в Rollout контроллер не управляет трафиком напрямую — он только меняет соотношение подов canary и stable. Если у вас один Kubernetes Service, который селектит обе версии по общему лейблу, kube-proxy распределяет соединения между подами примерно равномерно. То есть setWeight: 10 при десяти репликах означает: один под новой версии получит примерно десять процентов соединений просто потому, что он один из десяти.

Но если у вас, например, две реплики и нужен честный пятипроцентный canary, replica-based подход не сработает — два пода дают деление по 50/50 минимум. Для precise traffic split нужно дополнить Rollout блоком trafficRouting, который интегрирует Argo Rollouts с ingress-контроллером или service mesh: Istio, NGINX Ingress, AWS ALB, Traefik, SMI, Kong, Apache APISIX.

Пример с Istio:

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: api
spec:
  strategy:
    canary:
      canaryService: api-canary    # отдельный Service на canary-поды
      stableService: api-stable    # отдельный Service на stable-поды
      trafficRouting:
        istio:
          virtualService:
            name: api-vsvc
            routes:
              - primary
      steps:
        - setWeight: 5
        - pause: { duration: 10m }
        - setWeight: 25
        - pause: { duration: 10m }
        - setWeight: 50

В этом сценарии Argo Rollouts на каждом setWeight обновляет веса в Istio VirtualService, и пять процентов реального трафика идут на canary независимо от числа подов. Для NGINX Ingress модель похожая, только вместо VirtualService создаётся отдельный canary Ingress с аннотациями nginx.ingress.kubernetes.io/canary: true и canary-weight: 5, которые контроллер обновляет автоматически.

Какой подход выбрать — зависит от инфраструктуры. Если service mesh уже стоит, имеет смысл сразу использовать его trafficRouting. Если нет, replica-based достаточно для большинства задач, особенно при репликах от десяти и выше.

AnalysisTemplate с запросом в Prometheus

Допустим, главная продуктовая метрика — error rate, доля 5xx-ответов среди всех запросов. Хочется автоматически проваливать выкат, если error rate в новой версии превышает один процент.

AnalysisTemplate описывает один шаблон анализа: что мерять, как мерять, что считать успехом и провалом:

apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
  name: success-rate-prometheus
spec:
  args:
    - name: service-name
  metrics:
    - name: error-rate
      interval: 30s
      count: 10
      successCondition: isNaN(result[0]) || result[0] <= 0.01
      failureCondition: result[0] > 0.05
      failureLimit: 2
      provider:
        prometheus:
          address: http://prometheus.monitoring:9090
          timeout: 40
          query: |
            sum(rate(http_requests_total{
                service="{{ args.service-name }}",
                status_code=~"5.."
            }[1m]))
            /
            sum(rate(http_requests_total{
                service="{{ args.service-name }}"
            }[1m]))

Параметр interval: 30s задаёт частоту запросов — метрика запрашивается каждые тридцать секунд, а count: 10 означает, что всего будет десять измерений, то есть пять минут наблюдения. Условие successCondition помечает измерение успешным, если error rate меньше или равен одному проценту. Условие failureCondition помечает измерение провальным, если error rate больше пяти процентов, и это явная проблема, на которой даже одно измерение откатывает выкат. Параметр failureLimit: 2 означает, что два провальных измерения считаются общим провалом AnalysisRun.

Отдельная функция isNaN(result[0]) в successCondition — защита от деления на ноль. Если в окне [1m] вообще нет запросов (ночь, низкий трафик), знаменатель PromQL-выражения равен нулю, Prometheus возвращает NaN, и без явной обработки AnalysisRun уйдёт в inconclusive — статус, в котором ни одно из условий не сработало. Аналогично есть isInf(result[0]) для обработки бесконечности. Если ни successCondition, ни failureCondition не сработают, Argo Rollouts либо отметит шаг как inconclusive и остановит выкат, либо потребует ручного promote — поведение зависит от настроек.

Поля timeout и headers в провайдере полезны в двух случаях: timeout задаёт лимит на медленные PromQL-запросы, а headers нужен для multi-tenant Prometheus (например, Mimir или Cortex), где запрос требует заголовка X-Scope-OrgID:

provider:
  prometheus:
    address: http://prometheus.monitoring:9090
    timeout: 40
    headers:
      - key: X-Scope-OrgID
        value: tenant-a
    query: |
      ...

Подставляем AnalysisTemplate в Rollout:

spec:
  strategy:
    canary:
      steps:
        - setWeight: 10
        - pause: { duration: 2m }
        - setWeight: 25
        - analysis:
            templates:
              - templateName: success-rate-prometheus
            args:
              - name: service-name
                value: api
        - setWeight: 50
        - analysis:
            templates:
              - templateName: success-rate-prometheus
            args:
              - name: service-name
                value: api
        - setWeight: 100

Теперь после установки двадцати пяти и пятидесяти процентов запускается AnalysisRun, который пять минут наблюдает error rate. Если условие failureCondition сработало более двух раз, Rollout автоматически откатывается, canary ReplicaSet удаляется, прежняя версия остаётся в проде.

Если шаблон нужно использовать в нескольких неймспейсах, рядом с AnalysisTemplate (namespace-scoped) есть ClusterAnalysisTemplate (cluster-scoped) — тот же синтаксис, но ресурс глобальный, и на него можно ссылаться из любого Rollout через clusterScope: true в шаге анализа:

- analysis:
    templates:
      - templateName: success-rate-prometheus
        clusterScope: true

Окна метрик и низкий трафик

Запрос rate(...)[1m] берёт скорость за последнюю минуту. Если scrape interval Prometheus равен пятнадцати секундам, в окне будет всего четыре точки — этого мало для статистически осмысленного решения, особенно при низком трафике, когда одно случайное падение даёт большой относительный скачок error rate.

Лечится либо увеличением окна до [5m], либо увеличением count и interval в AnalysisTemplate, либо переходом на квантильную метрику вроде histogram_quantile, которая стабильнее обычного отношения.

Отдельный случай — низкий трафик в стейджинге или ночью на проде. Если из двух запросов один ошибочный, error rate уже пятьдесят процентов, и любое разумное failureCondition сработает по чисто статистической причине. Здесь имеет смысл либо добавить в PromQL условие минимальной интенсивности (and on() sum(rate(http_requests_total[1m])) > 1), либо синтетически генерировать трафик во время выката, либо использовать отдельный, более мягкий AnalysisTemplate для нерабочих часов.

Фоновый анализ вместо шагов

В шаговом режиме AnalysisRun запускается на конкретном шаге и блокирует выкат до своего завершения. Если шаг анализа занимает десять минут, общий выкат растягивается. Альтернатива — backgroundAnalysis, который идёт параллельно всем шагам и может зарубить выкат в любой момент:

strategy:
  canary:
    analysis:
      templates:
        - templateName: success-rate-prometheus
      args:
        - name: service-name
          value: api
      startingStep: 2   # запускать с шага 2 (после первого setWeight)
    steps:
      - setWeight: 10
      - pause: { duration: 2m }
      - setWeight: 25
      - setWeight: 50
      - setWeight: 100

Поле startingStep: 2 означает, что фоновый анализ стартует после второго шага — когда уже есть какой-то реальный трафик на canary, и метрики имеют смысл. Если выкат пройдёт быстрее, чем count × interval, фоновый анализ может не успеть отработать.

Итого

С Argo Rollouts вы определяете, какие метрики важны, какие пороги допустимы, как часто их проверять, и контроллер сам останавливает или откатывает выкат при отклонениях.

Главное при этом понимать, что автоматизация анализа не заменяет понимания метрик. Если successCondition написан без учёта суточных циклов трафика, особенностей низкого трафика или специфики продукта, получите либо постоянные ложные откаты, либо ложные зелёные на реально сломанных выкатах. Argo Rollouts даёт механизм, а за смысл порогов и метрик отвечает команда.

Плюсом Argo Rollouts хорошо интегрируется с Argo CD: в GitOps-сценарии Rollout это обычный манифест, который Argo CD синхронизирует, а дальше жизненным циклом выката управляет Rollouts-контроллер. Если в проекте уже используется Argo CD, добавить к нему Rollouts — естественный следующий шаг, не требующий пересборки CI/CD-конвейера.

Canary, Rollouts, Prometheus и Argo CD хорошо работают только тогда, когда понятна вся цепочка: от деплоя до наблюдаемости и отката. Проверить себя можно во вступительном тесте по DevOps — он подсветит темы, которые стоит подтянуть перед более глубоким погружением.

Argo Rollouts хорошо ложится в GitOps-подход, но сам по себе не решает весь пласт вопросов вокруг платформенной инженерии: кто создаёт окружения, как разработчики получают инфраструктуру, где проходит граница ответственности DevOps и как сделать процессы менее ручными. Эти темы можно будет продолжить на бесплатных уроках — заодно познакомиться с экспертами, посмотреть формат обучения и задать свои вопросы.

• 3 июня в 20:00. «Internal Developer Platform: self-service-инфраструктура за один вечер». Записаться

• 22 июня в 20:00. «Роль и задачи DevOps в современном IT». Записаться

Больше бесплатных уроков июня смотрите в дайджесте.