Istio — Примеры

Пример 1 — Десятая часть трафика на новую версию

Новая версия checkout развёрнута рядом со старой, и команда хочет, чтобы фиксированная доля живых запросов попадала в неё, с мгновенным путём назад. Изменение доли не должно требовать развёртывания. Ниже правило, которое сейчас в силе.

apiVersion: networking.istio.io/v1
kind: VirtualService
metadata: { name: checkout }
spec:
  hosts: ["checkout"]
  http:
    - route:
        - destination: { host: checkout, subset: old }

Решение

  http:
    - route:
        - destination: { host: checkout, subset: old }
          weight: 90
        - destination: { host: checkout, subset: new }
          weight: 10

запрос к checkout после изменения: GET /checkout/quote
направлен прокси рядом с каждой рабочей нагрузкой — код приложения не менялся, нагрузка не перезапускалась
откат: верните веса обратно на старый subset

Поскольку прокси рядом с каждой рабочей нагрузкой несёт вызовы, доля — это изменение конфигурации, а не релиз, и возврат обоих весов назад — это весь откат. То же правило может маршрутизировать по заголовку, чтобы тестировщики попадали на новый subset, а все остальные — нет. Обычная ошибка — развернуть новую версию под существующим именем сервиса, из-за чего выбрать между ними становится нечем.

Пример 2 — Повторы, умножающие нагрузку

Checkout стал медленным, и на каждый неудачный вызов к нему настроили пять повторов. Теперь он падает сильнее под нагрузкой, и одна медленная зависимость тянет вниз каждого вызывающего. Ниже правило, которое сейчас в силе. Ограничьте повторы и задайте вызову срок.

  http:
    - route:
        - destination: { host: checkout }
      retries: { attempts: 5 }

Решение

  http:
    - route:
        - destination: { host: checkout }
      timeout: 2s
      retries:
        attempts: 2
        perTryTimeout: 800ms
        retryOn: 5xx

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