Kubernetes №3-тегі канарларды орналастыру: Istio

Canary орналастыруын іске қосу және визуализациялау үшін Istio+Kiali пайдалану

Осы сериядағы мақалалар

1. Kubernetes №1 жүйесінде канарларды орналастыру: Gitlab CI
2. Kubernetes №2-де канарларды орналастыру: Argo Rollouts
3. (Бұл мақала)
4. Jenkins-X Istio Flagger көмегімен Canary Deployment

Canary Deployment

Сіз оқисыз деп үміттенеміз бірінші бөлім, мұнда біз Canary орналастыруларының не екенін қысқаша түсіндірдік және стандартты Kubernetes ресурстарын пайдалану арқылы оларды қалай жүзеге асыру керектігін көрсеттік.

Istio

Осы мақаланы оқу арқылы сіз Istio деген не екенін білесіз деп ойлаймыз. Егер жоқ болса, онда сіз бұл туралы оқи аласыз осында.

Тесттерге өтініш

Әрбір бөлім екі контейнерден тұрады: біздің қолданба және istio-proxy.

Біз frontend-nginx және backend python қосқыштары бар қарапайым сынақ қолданбасын қолданамыз. Nginx қосқышы жай ғана әр сұрауды серверлік қосқышқа қайта бағыттайды және прокси ретінде жұмыс істейді. Толық ақпаратты келесі ямлдардан табуға болады:

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

Сынақ қолданбасын өзіңіз іске қосу

Егер сіз менің үлгісіме еріп, осы сынақ қолданбасын өзіңіз пайдаланғыңыз келсе, қараңыз жоба мені.

Бастапқы орналастыру

Бірінші Орналастыруды іске қосқан кезде, біз қолданбамыздың бөлімшелерінде тек 2 контейнер бар екенін көреміз, яғни Istio бүйірлік құралы енді ғана іске асырылуда:

Сондай-ақ біз аттар кеңістігінде 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 біздің хосттар файлымызға.

Kiali арқылы торды қараңыз

Біз сынақ қосымшасын және Istio-ны Tracing, Grafana, Prometheus және Kiali-мен бірге орнаттық (толығырақ ақпаратты төменде қараңыз). жоба мені). Сондықтан біз Kiali пайдалана аламыз:

istioctl dashboard kiali # admin:admin

Kiali Mesh арқылы ағымдағы трафикті бейнелейді

Көріп отырғанымыздай, трафиктің 100%-ы фронтондық қызметке, содан кейін v1 жапсырмасы бар фронтондық бөлімдерге өтеді, өйткені біз сұрауларды серверлік қызметке қайта бағыттайтын қарапайым nginx проксиін пайдаланып жатырмыз, ол өз кезегінде оларды серверлік бөлімдерге қайта бағыттайды. v1 белгісімен.

Kiali Istio-мен тамаша жұмыс істейді және торды бейнелеуге арналған қораптық шешімді ұсынады. Тек тамаша.

Canary Deployment

Біздің серверде екі 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 нұсқасына қайта бағытталады:

Канарияны қолмен сынау

Енді біз барлық сұраулардың 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 қатынасына негізделеді:

Екі тәуелді нұсқаға арналған канар

Енді біз фронт пен сервер үшін v2 нұсқасы бар опцияны қарастырамыз. Екеуі үшін де трафиктің 10% v2-ге өтуі керек екенін анықтадық:

Біз v1 және v2 фронттары 1/10 серверіне v1 және v2 қатынасында алға трафикті көреміз.

Егер трафикті frontend-v2-ден тек backend-v2-ге бағыттау қажет болса ше, себебі ол v1-мен үйлесімді емес? Мұны істеу үшін біз келіссөздер арқылы backend-v1-ге қандай трафиктің түсетінін басқаратын фронтенд үшін 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

Нәтижесінде біз қажет нәрсені аламыз:

Қолмен Canary тәсілінен айырмашылығы

В Бірінші бөлім Біз Canary орналастыруды қолмен орындадық, сонымен қатар екі k8s қолдану арқылы. Онда біз көшірмелердің санын өзгерту арқылы сұраныстардың арақатынасын бақылап отырдық. Бұл әдіс жұмыс істейді, бірақ елеулі кемшіліктері бар.

Istio репликалар санына қарамастан сұраулардың арақатынасын анықтауға мүмкіндік береді. Бұл, мысалы, HPAs (горизонтальды Pod Autoscalers) пайдалана алатынымызды және Canary орналастыруының ағымдағы күйіне сәйкес конфигурациялаудың қажеті жоқ дегенді білдіреді.

Нәтиже

Istio тамаша жұмыс істейді және оны Kiali-мен бірге пайдалану өте күшті комбинацияны жасайды. Келесі қызығушылықтар тізімінде автоматтандыру және Canary аналитикасы үшін Spinnaker-ті Istio-мен біріктіру.

Ақпарат көзі: www.habr.com