Внедряване на Canary в Kubernetes #3: Istio

Използване на Istio+Kiali за стартиране и визуализиране на внедряване на Canary

Статии от тази серия

1. Внедряване на Canary в Kubernetes #1: Gitlab CI
2. Внедряване на Canary в Kubernetes #2: Внедряване на Argo
3. (Тази статия)
4. Внедряване на Canary с помощта на Jenkins-X Istio Flagger

Разгръщане на Canary

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

Истио

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

Заявление за тестове

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

Ще използваме просто тестово приложение с frontend-nginx и backend python pods. Nginx pod просто ще пренасочи всяка заявка към backend pod и ще работи като прокси. Подробности можете да намерите в следните yaml:

• интерфейс.yaml
• backend.yaml
• istio.yaml

Изпълнете сами тестовото приложение

Ако искате да последвате примера ми и сами да използвате това тестово приложение, вижте проект readme.

Първоначално внедряване

Когато стартираме първото внедряване, виждаме, че модулите на нашето приложение имат само 2 контейнера, тоест Istio sidecar току-що се внедрява:

И също така виждаме Istio Gateway Loadbalancer в пространството на имената istio-system:

Генериране на трафик

Ще използваме следния IP за генериране на трафик, който ще бъде получен от фронтенд модулите и препратен към задните модули:

while true; do curl -s --resolve 'frontend.istio-test:80:35.242.202.152' frontend.istio-test; sleep 0.1; done

Ние също ще добавим frontend.istio-test към нашия хост файл.

Вижте Mesh чрез Kiali

Инсталирахме тестовото приложение и Istio заедно с Tracing, Grafana, Prometheus и Kiali (вижте по-долу за подробности). проект readme). Следователно можем да използваме Kiali чрез:

istioctl dashboard kiali # admin:admin

Kiali визуализира текущия трафик чрез Mesh

Както виждаме, 100% от трафика отива към фронтенд услугата, след това към фронтенд подовете с етикет v1, тъй като ние използваме обикновен nginx прокси, който пренасочва заявките към бекенд услугата, която от своя страна ги пренасочва към бекенд подовете с етикет v1.

Kiali работи чудесно с Istio и предоставя решение за рендиране на Mesh в кутия. Просто страхотно.

Разгръщане на Canary

Нашият бекенд вече има две внедрявания на k8s, едно за 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 може да се счита за завършено и целият трафик се пренасочва към v2:

Ръчно тестване на Canary

Да кажем, че сега изпращаме 2% от всички заявки към бекенда v10. Ами ако искаме ръчно да тестваме 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 както за фронтенд, така и за бекенд. И за двете уточнихме, че 10% от трафика трябва да отива към v2:

Виждаме, че фронтенд v1 и v2 препращат трафик в съотношение 1/10 към бекенд v1 и v2.

Какво ще стане, ако трябва да препратим трафик от frontend-v2 само към backend-v2, защото не е съвместим с v1? За да направим това, ще зададем съотношение 1/10 за интерфейса, който контролира какъв трафик достига до бекенда-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 ръчно, като също използвахме две внедрявания на k8s. Там контролирахме съотношението на заявките, като променяхме броя на репликите. Този подход работи, но има сериозни недостатъци.

Istio дава възможност да се определи съотношението на заявките, независимо от броя на репликите. Това означава например, че можем да използваме HPA (Horizontal Pod Autoscalers) и не е необходимо да бъдем конфигурирани според текущото състояние на внедряването на Canary.

Общо

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

Източник: www.habr.com