Материал подготовлен в рамках курса «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». Записаться
Больше бесплатных уроков июня смотрите в дайджесте.