Регистрация

[IT-инфраструктура, Тестирование веб-сервисов, DevOps, Kubernetes] Canary Deployment в Kubernetes #3: Istio (перевод)

Ответить на тему
Автор Сообщение
news_bot ®

Стаж: 6 лет 9 месяцев
Сообщений: 27286

Создавать темы news_bot ® написал(а)
03-Авг-2020 16:33
Цитировать

Использование Istio+Kiali для запуска и визуализации Canary деплоя

Статьи этого цикла
Canary Deployment
Надеемся, что вы читали первую часть, где мы кратко объясняли что такое Canary deployments и показывали как его реализовать при помощи стандартных ресурсов Kubernetes.
Istio
И мы предполагаем, что читая эту статью, вы уже знаете что такое Istio. Если нет, то вы можете почитать о нем здесь.
Приложение для тестов

Каждый под содержит два контейнера: наше приложение и istio-proxy.
Мы будем использовать простое тестовое приложение с подами frontend-nginx и backend на python. Под с nginx будет просто перенаправлять каждый запрос на под с backend и работать как прокси. Детали можно посмотреть подробнее в следующих yamls:
Запуск тестового приложения самостоятельно
Если вы хотите последовать моему примеру и использовать данное тестовое приложение самостоятельно, см. readme проекта.
Начальный Deployment
При запуске первого Deployment видим, что поды нашего приложения имеют всего по 2 контейнера, то есть Istio sidecar пока только внедряется:

И также видим Istio Gateway Loadbalancer в namespace istio-system:

Создание трафика
Мы будем использовать следующий IP, что бы сгенерировать трафик, который будет принят frontend подами и перенаправлен на backend поды:
while true; do curl -s --resolve 'frontend.istio-test:80:35.242.202.152' frontend.istio-test; sleep 0.1; done
Мы так же добавим frontend.istio-test в наш hosts файл.
Просмотр Mesh через Kiali
Мы установили тестовое приложение и Istio вместе с Tracing, Grafana, Prometheus и Kiali (подробнее см. readme проекта). Следовательно, мы можем использовать Kiali через:
istioctl dashboard kiali # admin:admin

Kiali визуализирует текущий трафик через Mesh
Как мы видим, 100% трафика попадает на frontend service, затем на под фронтенда с label v1, так как мы используем простой nginx-прокси, который перенаправляет запросы на backend service, который в свою очередь перенаправляет их на backend поды с label v1.
Kiali работает отлично вместе с Istio и предоставляет коробочное решение для визуализации Mesh. Просто прекрасно.
Canary Deployment
Наш бекенд уже имеет два k8s deployments, один для v1 и один для v2. Теперь нам нужно просто сказать Istio перенаправлять определенный процент запросов на v2.
Шаг 1: 10%
И все что нам нужно сделать это отрегулировать вес VirtualService в istio.yaml:
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: backend
  namespace: default
spec:
  gateways: []
  hosts:
  - "backend.default.svc.cluster.local"
  http:
  - match:
    - {}
    route:
    - destination:
        host: backend.default.svc.cluster.local
        subset: v1
        port:
          number: 80
      weight: 90
    - destination:
        host: backend.default.svc.cluster.local
        subset: v2
        port:
          number: 80
      weight: 10


Мы видим, что 10% запросов перенаправлено на v2.
Шаг 2: 50%
И теперь достаточно просто увеличить его до 50%:
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: backend
  namespace: default
spec:
...
    - destination:
        host: backend.default.svc.cluster.local
        subset: v1
        port:
          number: 80
      weight: 50
    - destination:
        host: backend.default.svc.cluster.local
        subset: v2
        port:
          number: 80
      weight: 50


Шаг 3: 100%
Теперь Canary deployment может считаться завершенным и весь трафик перенаправляется на v2:

Тестирование Canary вручную
Допустим, сейчас мы отправляем на бэкэнд v2 10% от всех запросов. Что, если мы хотим вручную протестировать v2, чтобы убедиться, что все работает как мы ожидаем?
Мы можем добавить специальное соответствующее правило, основанное на HTTP заголовках:
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: backend
  namespace: default
spec:
  gateways: []
  hosts:
  - "backend.default.svc.cluster.local"
  http:
  - match:
    - headers:
        canary:
          exact: "canary-tester"
    route:
    - destination:
        host: backend.default.svc.cluster.local
        subset: v2
        port:
          number: 80
      weight: 100
  - match:
    - {}
    route:
    - destination:
        host: backend.default.svc.cluster.local
        subset: v1
        port:
          number: 80
      weight: 90
    - destination:
        host: backend.default.svc.cluster.local
        subset: v2
        port:
          number: 80
      weight: 10

Теперь используя curl мы можем принудительно запросить v2 отправив заголовок:

Запросы без заголовка все еще будут управляться соотношением 1/10:

Canary для двух зависимых версий
Теперь мы рассмотрим вариант, где у нас есть версия v2 и для frontend и для backend. Для обоих мы указали, что 10% трафика должно идти к v2:

Мы видим, что frontend v1 и v2 оба пересылают трафик в соотношении 1/10 на backend v1 и v2.
А что если бы мы нам было нужно пересылать трафик с frontend-v2 только на backend-v2, потому что он не совместим с v1? Для этого мы установим 1/10 соотношение для frontend, который контролирует какой трафик попадает на backend-v2 используя согласование по sourceLabels :
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: backend
  namespace: default
spec:
  gateways: []
  hosts:
  - "backend.default.svc.cluster.local"
  http:
...
  - match:
    - sourceLabels:
        app: frontend
        version: v2
    route:
    - destination:
        host: backend.default.svc.cluster.local
        subset: v2
        port:
          number: 80
      weight: 100

В результате получаем то, что нужно:

Отличия от ручного Canary подхода
В первой части мы выполняли Canary deployment вручную, также используя два k8s deployments. Там мы управляли соотношением запросов, изменяя количество реплик. Такой подход работает, но имеет серьезные недостатки.
Istio дает возможность определять соотношение запросов вне зависимости от количества реплик. Это значит, к примеру, что мы можем использовать HPAs (Horizontal Pod Autoscalers — горизонтальное масштабирование подов) и его не нужно настраивать в соответствии с текущем состоянием Canary деплоя.
Итог
Istio работает отлично и используя его вместе с Kiali получаем очень мощную комбинацию. Следующий в моем списке интересов это комбинация Spinnaker с Istio для автоматизации и Canary-аналитики.
 ===========
 Источник:
habr.com
===========
 ===========
 Автор оригинала: Kim Wuestkamp
===========Похожие новости: Теги для поиска: #_itinfrastruktura (IT-инфраструктура), #_testirovanie_vebservisov (Тестирование веб-сервисов), #_devops, #_kubernetes, #_canary, #_k8s, #_kubernetes, #_testing, #_istio, #_blog_kompanii_nixys (
Блог компании Nixys
), #_itinfrastruktura (
IT-инфраструктура
), #_testirovanie_vebservisov (
Тестирование веб-сервисов
), #_devops, #_kubernetes
Профиль  ЛС 
Показать сообщения:     
Ответить на тему

Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы

Текущее время: 22-Ноя 23:29
Часовой пояс: UTC + 5