Canary Deployment у Kubernetes #3: Istio

Выкарыстанне Istio+Kiali для запуску і візуалізацыі Canary дэплою

Артыкулы гэтага цыклу

1. Canary Deployment у Kubernetes #1: Gitlab CI
2. Canary Deployment у Kubernetes #2: Argo Rollouts
3. (гэты артыкул)
4. Canary Deployment выкарыстоўваючы Jenkins-X Istio Flagger

Канарскае разгортванне

Спадзяемся, што вы чыталі першую частку, дзе мы коратка тлумачылі што такое Canary deployments і паказвалі як яго рэалізаваць пры дапамозе стандартных рэсурсаў Kubernetes.

Ісціё

І мы мяркуем, што чытаючы гэты артыкул, вы ўжо ведаеце што такое Istio. Калі не, то вы можаце пачытаць пра яго тут.

Прыкладанне для тэстаў

Кожны пад змяшчае два кантэйнера: наша дадатак і 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. Проста цудоўна.

Канарскае разгортванне

Наш бэкенд ужо мае 8 k1s deployments, адзін для v2 і адзін для v2. Цяпер нам трэба проста сказаць Istio перанакіроўваць пэўны працэнт запытаў на vXNUMX.

Крок 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 ўручную, таксама выкарыстоўваючы 8 kXNUMXs deployments. Там мы кіравалі суадносінамі запытаў, змяняючы колькасць рэплік. Такі падыход працуе, але мае сур'ёзныя недахопы.

Istio дае магчымасць вызначаць суадносіны запытаў незалежна ад колькасці рэплік. Гэта значыць, да прыкладу, што мы можам выкарыстоўваць HPAs (Horizontal Pod Autoscalers – гарызантальнае маштабаванне подаў) і яго не трэба наладжваць у адпаведнасці з бягучым станам Canary дэплою.

Вынік

Istio працуе выдатна і выкарыстоўваючы яго разам з Kiali атрымліваем вельмі магутную камбінацыю. Наступны ў маім спісе інтарэсаў гэта камбінацыя Spinnaker з Istio для аўтаматызацыі і Canary-аналітыкі.

Крыніца: habr.com