Маршрутизация трафика в service mesh: canary, A/B и blue-green на практике

Короткий ответ: какую стратегию релиза выбрать в service mesh

Service mesh управляет направлением запросов независимо от выкладки Pod. Canary deployment снижает риск новой версии постепенным увеличением доли трафика. A/B-тестирование сравнивает поведение выбранных сегментов аудитории. Blue-green deployment переключает трафик между двумя подготовленными средами с быстрым возвратом. Выбор зависит от цели: оценка надежности, продуктовый эксперимент или моментальное переключение версии.

В этой статье практические примеры строятся вокруг Istio, где правила маршрутизации описываются отдельно от Kubernetes Service. Вы настроите весовые коэффициенты, маршрутизацию по заголовкам и правилам, поэтапное увеличение доли запросов на новую версию с возможностью быстрого отката.

Canary, A/B и blue-green: различия в одной таблице

Canary, A/B-тестирование и blue-green решают разные задачи. Canary проверяет техническую надежность новой версии на реальном трафике. A/B-тестирование проверяет продуктовую гипотезу на изолированной группе пользователей. Blue-green переключает окружение целиком после полной проверки.

Критерий	Canary	A/B-тестирование	Blue-green
Принцип распределения	Постепенное увеличение веса новой версии	Маршрутизация по признакам пользователя	Мгновенное переключение 100% трафика
Тип гипотезы	Техническая надежность	Продуктовая ценность	Готовность новой среды
Длительность релиза	Часы или дни	Дни или недели	Минуты
Требования к состоянию	Обе версии работают одновременно	Обе версии работают одновременно	Две полные среды
Механизм rollback	Уменьшение веса до 0	Прекращение маршрутизации на вариант	Переключение обратно на blue
Инфраструктурная стоимость	Низкая	Низкая	Высокая (двойные ресурсы)

Не используйте A/B-тестирование как замену canary или blue-green для постепенного выката. A/B-тестирование не проверяет надежность, а canary не отвечает на продуктовые вопросы.

Когда не нужно начинать с service mesh

Service mesh добавляет операционную сложность. Не внедряйте mesh, если у вас один сервис без требований к L7-правилам, редкие релизы, отсутствуют метрики и трассировка, нет возможности поддерживать control plane. Mesh не компенсирует отсутствие readiness probes, тестов, мониторинга и процедуры отката.

Для простых случаев достаточно стандартного Kubernetes Deployment и ingress-контроллера. Например, для одного сервиса с редкими обновлениями можно использовать стратегию RollingUpdate в Deployment. Если нужны только базовые проверки, ingress-контроллер с canary-аннотациями может покрыть сценарий.

Перед внедрением mesh убедитесь, что у вас есть:

Несколько микросервисов, требующих управления трафиком на L7.
Команда, готовая поддерживать control plane и sidecar.
Настроенный мониторинг и логирование.
Процедуры отката конфигураций.

Если этих условий нет, начните с улучшения observability и автоматизации деплоя. Service mesh не решит проблемы процесса.

Что подготовить перед маршрутизацией трафика в service mesh

Перед применением YAML-манифестов подготовьте платформу. Иначе трафик не разделится из-за неверных labels, отсутствующих метрик или неподготовленной платформы.

Разметка версий сервиса: stable и canary

Создайте соглашение по labels для Deployment и Pod. Например, используйте labels app: my-service и version: stable или version: canary. Названия subsets в DestinationRule должны совпадать со значениями labels. Фактические Pod должны иметь соответствующие labels.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-service-stable
spec:
  selector:
    matchLabels:
      app: my-service
      version: stable
  template:
    metadata:
      labels:
        app: my-service
        version: stable
    spec:
      containers:
      - name: app
        image: my-service:1.0.0
        readinessProbe:
          httpGet:
            path: /health
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 10

Обе версии должны проходить readiness probe до получения пользовательского трафика. Иначе mesh направит запросы в неготовый Pod.

Минимальный набор наблюдаемости перед релизом

Решение о продвижении версии должно основываться на метриках, а не на ручных проверках. Настройте сбор следующих сигналов для каждой версии:

Доля HTTP 4xx и 5xx ответов.
p95 или p99 задержки.
Насыщение ресурсов (CPU, memory).
Перезапуски Pod.
Бизнес-метрика критического сценария (например, успешные оформления заказа).

Разделяйте метрики stable- и новой версии по labels, destination subset или telemetry-атрибутам. В Istio метрики автоматически содержат destination_version или destination_canonical_revision, если настроены соответствующие labels.

Граница маршрутизации: ingress-трафик и вызовы между сервисами

Определите, на каком участке пути запроса применять правило. Внешний входящий трафик проходит через Gateway и VirtualService. Внутренние вызовы service-to-service также управляются VirtualService. Проверьте фоновые задачи, очереди, cron-задачи и другие потоки, которые не проходят через HTTP-маршрутизацию mesh. Например, если сервис читает сообщения из очереди, canary-версия может обрабатывать их без весового распределения.

Используйте минимальный тестовый namespace для проверки конфигураций. Применяйте манифесты в порядке: DestinationRule, затем VirtualService. Всегда имейте план возврата к исходным правилам.

Как Istio принимает решение о маршруте запроса

Запрос поступает к сервису или gateway. Istio сопоставляет условия маршрута в VirtualService, выбирает destination и применяет weight. Kubernetes Service обеспечивает обнаружение endpoints, а DestinationRule определяет subsets и политики.

VirtualService: условия и порядок HTTP-правил

VirtualService задает match и route. Match может проверять URI, заголовки, методы и другие признаки запроса. Порядок HTTP-правил влияет на результат: специфичные условия должны проверяться раньше общих.

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: my-service
spec:
  hosts:
  - my-service
  http:
  - match:
    - headers:
        x-user-segment:
          exact: testers
    route:
    - destination:
        host: my-service
        subset: canary
  - route:
    - destination:
        host: my-service
        subset: stable
        weight: 90
    - destination:
        host: my-service
        subset: canary
        weight: 10

В этом примере пользователи с заголовком x-user-segment: testers направляются на canary. Остальной трафик делится 90/10 между stable и canary. Если поставить общее правило первым, оно перехватит весь трафик, и тестировщики не попадут на canary.

DestinationRule и subsets: как привязать маршрут к версии Pod

DestinationRule определяет subsets, которые связываются с labels workload.

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: my-service
spec:
  host: my-service
  subsets:
  - name: stable
    labels:
      version: stable
  - name: canary
    labels:
      version: canary

Поле host должно совпадать с именем Kubernetes Service. Subset stable выбирает Pod с label version: stable. Отсутствие или несовпадение subset приводит к неработающей схеме маршрутизации.

Весовые коэффициенты: что реально означает 90/10

Веса задают целевое распределение запросов. На малом объеме трафика возможны статистические отклонения. Ровно каждый десятый пользователь или сессия не гарантированно попадет на новую версию. Для stateful-сессий, где пользователь должен оставаться на одной версии, требуется продумать sticky session или маршрутизацию по устойчивому признаку (например, cookie или заголовок).

Canary deployment в service mesh: поэтапное увеличение доли трафика

Canary deployment снижает риск новой версии. Вы разворачиваете новую версию, направляете на нее минимальную долю трафика, проверяете метрики и постепенно увеличиваете вес.

Шаг 1. Разверните canary-версию и проверьте ее без общего трафика

Выложите версию canary с корректными labels, readiness и liveness probes. Проверьте работоспособность через отдельный заголовок, тестовый endpoint или внутренний запрос. Проверьте логи, ошибки запуска, подключение к зависимостям и влияние схемы данных.

Пример проверки через заголовок:

curl -H "x-user-segment: testers" http://my-service/health

Убедитесь, что ответ приходит от canary-версии (например, по версии в ответе).

Шаг 2. Направьте 1-5% запросов на новую версию

Примените VirtualService с весами stable/canary. Например, 95/5.

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: my-service
spec:
  hosts:
  - my-service
  http:
  - route:
    - destination:
        host: my-service
        subset: stable
        weight: 95
    - destination:
        host: my-service
        subset: canary
        weight: 5

До применения манифеста откройте дашборды с метриками. Сравните новую версию с базовой линией stable. Наблюдайте результат при характерной для сервиса нагрузке. Обычно достаточно 15-30 минут при стабильном трафике.

Шаг 3. Увеличивайте вес только после контрольной точки

Не повышайте вес формально. Для каждого этапа (например, 5%, 25%, 50%, 100%) проверяйте:

Error rate не превышает baseline.
Latency p95/p99 в допустимых пределах.
Ресурсы Pod не насыщены.
Бизнес-проверка проходит.
Зависимые сервисы работают корректно.

При ухудшении показателей переход к следующему этапу блокируется.

Шаг 4. Откатите canary одним изменением весов

Для отката верните 100% трафика в stable subset.

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: my-service
spec:
  hosts:
  - my-service
  http:
  - route:
    - destination:
        host: my-service
        subset: stable
        weight: 100

Соберите артефакты для анализа: версия образа, diff конфигурации, логи, трассировки и метрики на момент деградации. Не удаляйте canary Pod до восстановления маршрута, если они нужны для диагностики.

A/B-тестирование в Istio: маршрутизация по заголовкам и правилам

A/B-тестирование сравнивает варианты на выбранных сегментах. Цель - проверить продуктовую или техническую гипотезу без случайного перевода всех пользователей на новую версию.

Маршрутизация по заголовкам Istio для тестовой аудитории

Используйте VirtualService с условием на HTTP header. Например, x-user-segment: testers или end-user: internal. Условное правило должно находиться выше общего правила с весами.

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: my-service
spec:
  hosts:
  - my-service
  http:
  - match:
    - headers:
        x-user-segment:
          exact: testers
    route:
    - destination:
        host: my-service
        subset: canary
  - route:
    - destination:
        host: my-service
        subset: stable

Проверьте заголовок через тестовый запрос и подтвердите выбранный destination.

Для стабильности варианта используйте устойчивый признак: header, cookie, JWT claim или path. Признак должен быть защищен от подмены на внешнем входе. Например, если заголовок добавляет gateway после аутентификации, клиент не может его подделать. Учитывайте конфиденциальность пользовательских данных.

Feature flags и сбор результатов эксперимента остаются ответственностью приложения или отдельной платформы экспериментов. Istio только маршрутизирует трафик.

Проверка результата A/B-теста без смешивания технических и продуктовых метрик

Разделяйте технические показатели mesh и продуктовые показатели варианта. Задайте гипотезу, метрику успеха, размер выборки, период теста и условие досрочной остановки при технической деградации. Не принимайте решение о версии только по сетевой статистике.

Blue-green deployment в Istio: переключение трафика между двумя версиями

Blue-green deployment использует две параллельные версии: blue обслуживает production-трафик, green проходит проверку и становится активной после переключения маршрута. Требуется обратная совместимость API, миграции базы данных, очередей и shared state.

Шаг 1. Подготовьте green-версию и проведите изолированную проверку

Запустите green с отдельным subset или labels. Проверьте health checks, smoke-тесты, контрактные тесты и нагрузочные проверки. Убедитесь в доступе к общим зависимостям и совместимости с текущей схемой базы данных.

Шаг 2. Переключите основной маршрут с blue на green

Измените маршрут в VirtualService на 100% направление на green.

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: my-service
spec:
  hosts:
  - my-service
  http:
  - route:
    - destination:
        host: my-service
        subset: green
        weight: 100

До переключения зафиксируйте текущую рабочую конфигурацию. Проверьте, что rollback не требует повторного развертывания blue.

Шаг 3. Подтвердите стабильность и сохраните blue для rollback

Наблюдайте после переключения. Контролируйте метрики и бизнес-проверки. Сохраняйте blue для rollback. После периода стабильности (например, 24 часа) blue можно выводить из эксплуатации. При инциденте переключите маршрут обратно на blue.

Контрольные точки релиза: метрики, SLO и быстрый rollback

Решение о продвижении должно основываться на заранее согласованных порогах, а не на субъективном впечатлении от дашборда. Привяжите rollback к конкретным симптомам и владельцам действий.

Что проверить до изменения маршрута

Текущее состояние stable.
Версии применяемых ресурсов.
Корректность selectors и subsets.
Доступность дашбордов, алертов, логов, трассировок.
Процедура возврата конфигурации.

Какие сигналы требуют остановить продвижение версии

Рост серверных ошибок (HTTP 5xx).
Ухудшение latency (p95/p99).
Увеличение timeouts.
Перезапуски Pod.
Saturation (CPU, memory).
Ошибки зависимостей.
Падение критической бизнес-метрики.

Сравнивайте новую версию со stable и с собственной исторической базовой линией.

Как документировать инцидент после rollback

Зафиксируйте артефакты: время изменения веса, версия образа, хеш манифеста, метрики, trace ID, логи, изменения схемы данных и внешний контекст нагрузки. Добавьте запись в runbook.

Istio, Linkerd, sidecar и ambient: где заканчивается переносимость примеров

YAML из этой статьи рассчитан на Istio. Перед переносом в Linkerd или другую реализацию проверьте актуально поддерживаемые механизмы L7-маршрутизации, API и требования к data plane.

Что остается общим для Istio и Linkerd

Общие эксплуатационные принципы: минимизация blast radius, постепенное продвижение, разделение метрик версий, подготовленный rollback, проверка совместимости состояния и зависимостей.

Что проверить при sidecar и Istio Ambient Mode

Перед внедрением подтвердите доступность требуемого уровня L7-контроля, способ обработки трафика конкретного workload, видимость метрик и трассировок, совместимость используемого режима mesh с правилами маршрутизации. Не утверждайте равенство возможностей режимов без проверки документации версии.

Частые ошибки при маршрутизации релизов в Istio

Трафик не попадает в нужную версию

Проверьте порядок: labels Pod, endpoint-ы Service, совпадение subset labels, host, namespace, порядок правил и фактически примененная конфигурация. Используйте тестовый запрос с наблюдаемыми признаками маршрута.

Новая версия технически здорова, но релиз нельзя продвигать

Успешные health checks не означают готовность к увеличению пользовательского трафика. Возможны деградация latency, ошибки бизнес-операций, проблемы зависимостей, очередей или миграций. Свяжите решение с контрольными метриками и возвратом к предыдущему весу или blue-версии.

Дополнительные материалы по теме:

Для размещения Kubernetes-кластера с Istio можно использовать облачную инфраструктуру Timeweb Cloud.