ڪبرنيٽس #3 ۾ ڪينري جي تعیناتي: اسٽيو

استعمال ڪندي Istio+Kiali کي لانچ ڪرڻ ۽ تصور ڪرڻ لاءِ ڪينري ڊيپلائيمينٽ

هن سلسلي ۾ آرٽيڪل

1. ڪبرنيٽس #1 ۾ ڪينري جي تعیناتي: Gitlab CI
2. ڪبرنيٽس #2 ۾ ڪينري جي تعیناتي: آرگو رول آئوٽ
3. (هي مضمون)
4. Jenkins-X Istio Flagger استعمال ڪندي ڪينري جي جوڙجڪ

ڪينري لڳائڻ

اسان کي اميد آهي ته توهان پڙهيو پهريون حصو، جتي اسان مختصر طور تي وضاحت ڪئي ته ڪينري ڊيپلائيمينٽس ڇا آهن ۽ ڏيکاريو ته انهن کي ڪيئن لاڳو ڪجي معياري ڪبرنيٽس وسيلن کي استعمال ڪندي.

استيو

۽ اسان سمجهون ٿا ته هي مضمون پڙهڻ سان توهان اڳ ۾ ئي ڄاڻو ٿا ته Istio ڇا آهي. جيڪڏهن نه، ته پوء توهان ان جي باري ۾ پڙهي سگهو ٿا هتي.

ٽيسٽ لاءِ درخواست

هر پوڊ ۾ ٻه ڪنٽينرز شامل آهن: اسان جي ايپليڪيشن ۽ اسٽيو-پراڪسي.

اسان استعمال ڪنداسين هڪ سادي ٽيسٽ ايپليڪيشن فرنٽ اينڊ نينڪس ۽ پسمانده پٿن پوڊس سان. nginx پوڊ آسان طور تي هر درخواست کي پس منظر واري پوڊ ڏانهن منتقل ڪندو ۽ پراکسي طور ڪم ڪندو. تفصيل هيٺ ڏنل yamls ۾ ڳولهي سگهجن ٿا:

• اڳيون. yaml
• backend.yaml
• istio.yaml

آزمائشي ايپليڪيشن پاڻ کي هلائڻ

جيڪڏھن توھان چاھيو ٿا منھنجي مثال تي عمل ڪريو ۽ ھي ٽيسٽ ايپليڪيشن پاڻ استعمال ڪريو، ڏسو پروجيڪٽ پڙهڻ.

شروعاتي لڳائڻ

جڏهن اسان پهرين ڊيپلائيشن شروع ڪندا آهيون، اسان ڏسون ٿا ته اسان جي ايپليڪيشن جا پوڊ صرف 2 ڪنٽينر آهن، اهو آهي، Istio sidecar صرف لاڳو ڪيو پيو وڃي:

۽ اسان پڻ ڏسو Istio Gateway Loadbalancer namespace ۾ 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 ذريعي ڪيولي

اسان انسٽال ڪيو ٽيسٽ ايپليڪيشن ۽ اسٽيو سان گڏ Tracing، Grafana، Prometheus ۽ Kiali (تفصيل لاءِ هيٺ ڏسو). پروجيڪٽ پڙهڻ). تنهن ڪري اسان Kiali ذريعي استعمال ڪري سگهون ٿا:

istioctl dashboard kiali # admin:admin

ڪيلي ميش ذريعي موجوده ٽرئفڪ کي ڏسڻ ۾ اچي ٿو

جيئن اسان ڏسي سگهون ٿا، 100٪ ٽرئفڪ فرنٽ اينڊ سروس ڏانهن وڃي ٿي، پوءِ ليبل v1 سان فرنٽ اينڊ پوڊس ڏانهن، ڇاڪاڻ ته اسان هڪ سادي nginx پراکسي استعمال ڪري رهيا آهيون جيڪا درخواستن کي پس منظر واري خدمت ڏانهن موڪلي ٿي، جنهن جي نتيجي ۾ انهن کي پٺتي پيل پوڊس ڏانهن منتقل ڪيو وڃي ٿو. ليبل سان v1.

Kiali Istio سان وڏو ڪم ڪري ٿو ۽ هڪ باڪس ٿيل ميش رينڊنگ حل فراهم ڪري ٿو. بلڪل زبردست.

ڪينري لڳائڻ

اسان جي پس منظر ۾ اڳ ۾ ئي ٻه 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٪

ھاڻي ڪينري جي ٺاھ جوڙ کي مڪمل سمجھي سگھجي ٿو ۽ سموري ٽرئفڪ کي ريٽائرڊ ڪيو ويو آھي 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 ڏانهن.

ڇا جيڪڏھن اسان کي ٽريفڪ کي فرنٽ-اينڊ-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

نتيجي طور، اسان حاصل ڪريون ٿا جيڪو اسان کي گهرجي:

دستي ڪينري طريقي کان اختلاف

В پهريون حصو اسان دستي طور تي ڪينري جي تعیناتي ڪئي، پڻ ٻه k8s استعمال ڪندي. اتي اسان نقلن جي تعداد کي تبديل ڪندي درخواستن جي تناسب کي سنڀاليو. اهو طريقو ڪم ڪري ٿو، پر ان ۾ سنگين نقصان آهي.

Istio اهو ممڪن بڻائي ٿو ته درخواستن جي تناسب کي طئي ڪرڻ کان سواء ريپليڪس جي تعداد کان سواء. ان جو مطلب، مثال طور، ته اسان HPAs (Horizontal Pod Autoscalers) استعمال ڪري سگھون ٿا ۽ ڪينري ڊيپلائيمينٽ جي موجوده حالت جي مطابق ترتيب ڏيڻ جي ضرورت نه آھي.

نتيجو

Istio عظيم ڪم ڪري ٿو ۽ ان کي استعمال ڪندي ڪيولي سان گڏ هڪ تمام طاقتور ميلاپ ٺاهي ٿو. اڳيان منهنجي دلچسپين جي لسٽ تي اسپنيڪر کي آٽوميشن ۽ ڪينري اينالائيٽڪس لاءِ اسٽيو سان گڏ ڪري رهيو آهي.

جو ذريعو: www.habr.com