Цанари имплементација у Кубернетес #3: Истио

Коришћење Истио+Киали-а за покретање и визуелизацију примене Цанари

Цанари имплементација у Кубернетес #3: Истио

Чланци у овој серији

  1. Цанари имплементација у Кубернетес #1: Гитлаб ЦИ
  2. Цанари имплементација у Кубернетес #2: Арго Роллоутс
  3. (Овај чланак)
  4. Цанари Деплоимент користећи Јенкинс-Кс Истио Флаггер

Цанари Деплоимент

Надамо се да сте прочитали Први део, где смо укратко објаснили шта су Цанари имплементације и показали како их имплементирати користећи стандардне Кубернетес ресурсе.

Истио

И претпостављамо да читајући овај чланак већ знате шта је Истио. Ако не, онда можете прочитати о томе овде.

Пријава за тестове

Цанари имплементација у Кубернетес #3: Истио

Сваки под садржи два контејнера: нашу апликацију и истио-прокси.

Користићемо једноставну апликацију за тестирање са фронтенд-нгинк и бацкенд питхон подовима. Нгинк под ће једноставно преусмерити сваки захтев на позадински под и радити као прокси. Детаљи се могу наћи у следећим иамл-овима:

Покрените тестну апликацију сами

Ако желите да следите мој пример и сами користите ову тест апликацију, погледајте пројецт реадме.

Инитиал Деплоимент

Када покренемо прву имплементацију, видимо да подови наше апликације имају само 2 контејнера, односно Истио сидецар се управо имплементира:

Цанари имплементација у Кубернетес #3: Истио

Такође видимо Истио Гатеваи Лоадбаланцер у именском простору istio-system:

Цанари имплементација у Кубернетес #3: Истио

Генерисање саобраћаја

Користићемо следећу ИП адресу да генеришемо саобраћај који ће примати фронтенд модули и прослеђивати позадинским подовима:

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

Такође ћемо додати frontend.istio-test у нашу датотеку домаћина.

Погледајте Месх преко Киали

Инсталирали смо тестну апликацију и Истио заједно са Трацинг, Графана, Прометхеус и Киали (погледајте доле за детаље). пројецт реадме). Стога можемо користити Киали преко:

istioctl dashboard kiali # admin:admin

Цанари имплементација у Кубернетес #3: Истио

Киали визуализује тренутни саобраћај кроз Месх

Као што видимо, 100% саобраћаја иде на фронтенд сервис, затим на фронтенд подове са ознаком в1, пошто користимо једноставан нгинк проки који преусмерава захтеве на бацкенд сервис, који их заузврат преусмерава на позадинске подове са ознаком в1.

Киали одлично ради са Истиом и пружа решење за рендеровање мреже у кутији. Сјајно.

Цанари Деплоимент

Наш бацкенд већ има две примене к8с, једну за в1 и једну за в2. Сада само треба да кажемо Истио-у да проследи одређени проценат захтева в2.

Корак 1: 10%

И све што треба да урадимо је да прилагодимо тежину ВиртуалСервице-а истио.иамл:

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

Цанари имплементација у Кубернетес #3: Истио

Видимо да је 10% захтева преусмерено на в2.

Корак 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: Истио

Корак 3: 100%

Сада се постављање Цанари може сматрати завршеним и сав саобраћај је преусмерен на в2:

Цанари имплементација у Кубернетес #3: Истио

Ручно тестирање Цанари-а

Рецимо да сада шаљемо 2% свих захтева бацкенд-у в10. Шта ако желимо да ручно тестирамо в2 да бисмо били сигурни да све функционише како очекујемо?

Можемо додати посебно правило подударања на основу ХТТП заглавља:

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

Сада користећи цурл можемо форсирати в2 захтев слањем заглавља:

Цанари имплементација у Кубернетес #3: Истио

Захтеви без заглавља ће и даље бити вођени односом 1/10:

Цанари имплементација у Кубернетес #3: Истио

Цанари за две зависне верзије

Сада ћемо размотрити опцију где имамо верзију в2 и за фронтенд и за бацкенд. За оба смо навели да 10% саобраћаја треба да иде на в2:

Цанари имплементација у Кубернетес #3: Истио

Видимо да фронтенд в1 и в2 унапред саобраћају у односу 1/10 према бацкенд в1 и в2.

Шта ако је потребно да проследимо саобраћај са фронтенд-в2 само на бацкенд-в2 јер није компатибилан са в1? Да бисмо то урадили, поставићемо однос 1/10 за фронтенд, који контролише који саобраћај стиже до бацкенд-в2 користећи преговарање 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

Као резултат, добијамо оно што нам је потребно:

Цанари имплементација у Кубернетес #3: Истио

Разлике у односу на мануелни канарски приступ

В први део Ручно смо извели Цанари примену, такође користећи два к8с распоређивања. Тамо смо контролисали однос захтева променом броја реплика. Овај приступ функционише, али има озбиљне недостатке.

Истио омогућава одређивање односа захтева без обзира на број реплика. То значи, на пример, да можемо да користимо ХПА (Хоризонтал Под Аутосцалерс) и да не морамо да будемо конфигурисани према тренутном стању примене Цанари.

Укупан

Истио одлично функционише и коришћење заједно са Киалијем чини веома моћну комбинацију. Следеће на мојој листи интересовања је комбиновање Спиннакера са Истиом за аутоматизацију и Цанари аналитику.

Извор: ввв.хабр.цом

Додај коментар