НОВОСТИ [Перевод] Canary Deployment в Kubernetes #3: Istio

[NewsBot]

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

Статьи этого цикла

1. You must be registered for see links
2. You must be registered for see links
3. (эта статья)
4. Canary Deployment используя Jenkins-X Istio Flagger

Canary Deployment



Надеемся, что вы читали

You must be registered for see links

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

Istio



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

You must be registered for see links

.

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

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


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

• You must be registered for see links
• You must be registered for see links
• You must be registered for see links

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



Если вы хотите последовать моему примеру и использовать данное тестовое приложение самостоятельно, см.

You must be registered for see links

.

Начальный 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 (подробнее см.

You must be registered for see links

). Следовательно, мы можем использовать 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 в

You must be registered for see links

:


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-аналитики.