Implementarea Canary în Kubernetes #3: Istio

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

Articole din această serie

1. Implementarea Canary în Kubernetes #1: Gitlab CI
2. Implementare Canary în Kubernetes #2: Lansări Argo
3. (Acest articol)
4. Canary Deployment используя Jenkins-X Istio Flagger

Desfăşurare Canary

Надеемся, что вы читали Prima parte, где мы кратко объясняли что такое Canary deployments и показывали как его реализовать при помощи стандартных ресурсов Kubernetes.

Istio

И мы предполагаем, что читая эту статью, вы уже знаете что такое Istio. Если нет, то вы можете почитать о нем aici.

Приложение для тестов

Каждый под содержит два контейнера: наше приложение и istio-proxy.

Мы будем использовать простое тестовое приложение с подами frontend-nginx и backend на python. Под с nginx будет просто перенаправлять каждый запрос на под с backend и работать как прокси. Детали можно посмотреть подробнее в следующих yamls:

• frontend.yaml
• backend.yaml
• istio.yaml

Запуск тестового приложения самостоятельно

Если вы хотите последовать моему примеру и использовать данное тестовое приложение самостоятельно, см. 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. Просто прекрасно.

Desfăşurare Canary

Наш бекенд уже имеет два 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 подхода

В prima parte мы выполняли Canary deployment вручную, также используя два k8s deployments. Там мы управляли соотношением запросов, изменяя количество реплик. Такой подход работает, но имеет серьезные недостатки.

Istio дает возможность определять соотношение запросов вне зависимости от количества реплик. Это значит, к примеру, что мы можем использовать HPAs (Horizontal Pod Autoscalers — горизонтальное масштабирование подов) и его не нужно настраивать в соответствии с текущем состоянием Canary деплоя.

Total

Istio работает отлично и используя его вместе с Kiali получаем очень мощную комбинацию. Следующий в моем списке интересов это комбинация Spinnaker с Istio для автоматизации и Canary-аналитики.

Sursa: www.habr.com