Использование Istio+Kiali для запуска и визуализации Canary деплоя
Статьи этого цикла
- Canary Deployment в Kubernetes #1: Gitlab CI
- Canary Deployment в Kubernetes #2: Argo Rollouts
- (эта статья)
- Canary Deployment используя Jenkins-X Istio Flagger
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/v1alpha3kind: VirtualServicemetadata: name: backend namespace: defaultspec: 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/v1alpha3kind: VirtualServicemetadata: name: backend namespace: defaultspec:... - 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/v1alpha3kind: VirtualServicemetadata: name: backend namespace: defaultspec: 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/v1alpha3kind: VirtualServicemetadata: name: backend namespace: defaultspec: 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-аналитики.
