Kubernetes №3-də Kanareyka Yerləşdirməsi: Istio

Canary yerləşdirməsini işə salmaq və vizuallaşdırmaq üçün Istio+Kiali istifadə edin

Bu seriyadakı məqalələr

1. Kubernetes №1-də Canary Yerləşdirmə: Gitlab CI
2. Kubernetes # 2-də Kanar Yerləşdirmə: Argo Rollouts
3. (Bu məqalə)
4. Jenkins-X Istio Flagger istifadə edərək Canary Deployment

Canary Deployment

Oxumağınıza ümid edirik birinci hissə, burada Canary yerləşdirmələrinin nə olduğunu qısaca izah etdik və standart Kubernetes resurslarından istifadə edərək onların necə həyata keçiriləcəyini göstərdik.

İstio

Və güman edirik ki, bu məqaləni oxumaqla siz artıq Istio-nun nə olduğunu bilirsiniz. Yoxdursa, bu barədə oxuya bilərsiniz burada.

Testlər üçün ərizə

Hər podda iki konteyner var: tətbiqimiz və istio-proxy.

Biz frontend-nginx və backend python pods ilə sadə test proqramından istifadə edəcəyik. Nginx podu sadəcə olaraq hər sorğunu arxa panelə yönləndirəcək və proksi kimi işləyəcək. Təfərrüatlar aşağıdakı yamllarda tapıla bilər:

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

Test tətbiqini özünüz işlədin

Mənim nümunəmə əməl etmək və bu test proqramından özünüz istifadə etmək istəyirsinizsə, baxın layihə readme.

İlkin Yerləşdirmə

İlk Yerləşdirməni işə saldıqda, tətbiqimizin podlarında cəmi 2 konteynerin olduğunu görürük, yəni Istio sidecar yenicə həyata keçirilir:

Həm də ad məkanında Istio Gateway Loadbalancer görürük istio-system:

Trafik generasiyası

Biz aşağıdakı IP-dən istifadə edəcəyik ki, bu trafiki frontend bölmələri tərəfindən qəbul ediləcək və arxa panellərə yönləndiriləcək:

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

Biz də əlavə edəcəyik frontend.istio-test host faylımıza.

Kiali vasitəsilə Mesh-ə baxın

Tracing, Grafana, Prometheus və Kiali ilə birlikdə test tətbiqini və Istio-nu quraşdırdıq (ətraflı məlumat üçün aşağıya baxın). layihə readme). Beləliklə, biz Kiali-dən istifadə edə bilərik:

istioctl dashboard kiali # admin:admin

Kiali Mesh vasitəsilə cari trafiki vizuallaşdırır

Gördüyümüz kimi, trafikin 100%-i frontend xidmətinə, daha sonra v1 etiketli frontend bölmələrinə gedir, çünki biz sorğuları backend xidmətinə yönləndirən sadə nginx proxy-dən istifadə edirik və bu da öz növbəsində onları backend podlarına yönləndirir. etiketi ilə v1.

Kiali Istio ilə əla işləyir və qutulu Mesh render həllini təmin edir. Sadəcə əla.

Canary Deployment

Backendimizdə artıq iki k8s yerləşdirməsi var, biri v1, digəri v2 üçün. İndi sadəcə Istio-ya müraciətlərin müəyyən faizini v2-yə yönləndirməsini söyləməliyik.

Addım 1: 10%

Etməli olduğumuz tək şey VirtualService-in çəkisini tənzimləməkdir 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

Sorğuların 10%-nin v2-ə yönləndirildiyini görürük.

Addım 2: 50%

İndi onu 50%-ə çatdırmaq kifayətdir:

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

Addım 3: 100%

İndi Canary yerləşdirilməsi tamamlanmış hesab edilə bilər və bütün trafik v2-yə yönləndirilir:

Canary-nin əl ilə sınaqdan keçirilməsi

Tutaq ki, biz indi bütün sorğuların 2%-ni v10 backend-ə göndəririk. Hər şeyin gözlədiyimiz kimi işlədiyinə əmin olmaq üçün v2-ni əl ilə sınamaq istəsək nə olar?

HTTP başlıqlarına əsaslanan xüsusi uyğunluq qaydası əlavə edə bilərik:

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

İndi curl istifadə edərək başlığı göndərməklə v2 sorğusunu məcbur edə bilərik:

Başlığı olmayan sorğular yenə də 1/10 nisbəti ilə idarə olunacaq:

İki asılı versiya üçün kanareyka

İndi biz həm frontend, həm də backend üçün v2 versiyasının olduğu variantı nəzərdən keçirəcəyik. Hər ikisi üçün trafikin 10%-nin v2-yə getməli olduğunu qeyd etdik:

Biz görürük ki, cəbhə v1 və v2 həm də v1 və v10 arxa hissəyə 1/2 nisbətində irəli trafikdir.

Əgər v2 ilə uyğun olmadığı üçün trafiki frontend-v2-dən yalnız backend-v1-yə yönləndirmək lazım gəlsə nə olar? Bunu etmək üçün, danışıqlardan istifadə edərək, backend-v1-yə hansı trafikin daxil olduğunu idarə edən frontend üçün 10/2 nisbəti təyin edəcəyik. 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

Nəticədə ehtiyacımız olanı alırıq:

Manual Canary yanaşmasından fərqlər

В birinci hissəsində Canary yerləşdirməni əl ilə, həmçinin iki k8s yerləşdirməsindən istifadə etdik. Orada replikaların sayını dəyişdirərək sorğuların nisbətinə nəzarət etdik. Bu yanaşma işləyir, lakin ciddi çatışmazlıqlara malikdir.

Istio, replikaların sayından asılı olmayaraq sorğuların nisbətini təyin etməyə imkan verir. Bu o deməkdir ki, məsələn, biz HPA-lardan (Horizontal Pod Autoscalers) istifadə edə bilərik və Canary yerləşdirməsinin cari vəziyyətinə uyğun olaraq konfiqurasiya olunmağa ehtiyac yoxdur.

Ümumi

Istio əla işləyir və onu Kiali ilə birlikdə istifadə etmək çox güclü kombinasiya yaradır. Maraqlarım siyahısında daha sonra Spinnaker-i avtomatlaşdırma və Canary analitikası üçün Istio ilə birləşdirir.

Mənbə: www.habr.com