Kubernetes #3 میں کینری تعیناتی: Istio

کینری تعیناتی کو شروع کرنے اور اسے دیکھنے کے لیے Istio+Kiali کا استعمال کرنا

اس سلسلے میں مضامین

1. Kubernetes #1 میں کینری تعیناتی: Gitlab CI
2. Kubernetes #2 میں کینری تعیناتی: آرگو رول آؤٹ
3. (اس مضمون)
4. جینکنز-ایکس اسٹیو فلیگر کا استعمال کرتے ہوئے کینری تعیناتی۔

کینری تعیناتی۔

ہمیں امید ہے کہ آپ پڑھیں گے۔ پہلا حصہ، جہاں ہم نے مختصر طور پر وضاحت کی کہ کینری تعیناتیاں کیا ہیں اور یہ دکھایا کہ معیاری Kubernetes وسائل کا استعمال کرتے ہوئے انہیں کیسے نافذ کیا جائے۔

Istio

اور ہم فرض کرتے ہیں کہ اس مضمون کو پڑھ کر آپ کو پہلے ہی معلوم ہو گیا ہے کہ Istio کیا ہے۔ اگر نہیں، تو آپ اس کے بارے میں پڑھ سکتے ہیں۔ یہاں.

ٹیسٹ کے لیے درخواست

ہر پوڈ میں دو کنٹینرز ہوتے ہیں: ہماری درخواست اور اسٹیو پراکسی۔

ہم فرنٹ اینڈ اینجینکس اور بیک اینڈ پائتھن پوڈز کے ساتھ ایک سادہ ٹیسٹ ایپلیکیشن استعمال کریں گے۔ nginx پوڈ آسانی سے ہر درخواست کو بیک اینڈ پوڈ پر بھیجے گا اور ایک پراکسی کے طور پر کام کرے گا۔ تفصیلات درج ذیل یاملوں میں مل سکتی ہیں:

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

ٹیسٹ ایپلیکیشن خود چلانا

اگر آپ میری مثال پر عمل کرنا چاہتے ہیں اور اس ٹیسٹ ایپلی کیشن کو خود استعمال کرنا چاہتے ہیں تو دیکھیں پروجیکٹ ریڈمی.

ابتدائی تعیناتی۔

جب ہم پہلی تعیناتی کا آغاز کرتے ہیں، تو ہم دیکھتے ہیں کہ ہماری ایپلی کیشن کے پوڈز میں صرف 2 کنٹینرز ہیں، یعنی Istio sidecar کو ابھی لاگو کیا جا رہا ہے:

اور ہم نام کی جگہ میں Istio Gateway Loadbalancer بھی دیکھتے ہیں۔ istio-system:

ٹریفک کی نسل

ہم ٹریفک پیدا کرنے کے لیے درج ذیل آئی پی کا استعمال کریں گے جو فرنٹ اینڈ پوڈز کو موصول ہوگا اور بیک اینڈ پوڈز کو فارورڈ کیا جائے گا۔

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

ہم بھی شامل کریں گے۔ frontend.istio-test ہماری میزبان فائل میں۔

کیالی کے ذریعے میش دیکھیں

ہم نے Tracing، Grafana، Prometheus اور Kiali (تفصیلات کے لیے نیچے دیکھیں) کے ساتھ ٹیسٹ ایپلیکیشن اور Istio انسٹال کیا۔ پروجیکٹ ریڈمی)۔ لہذا ہم Kiali استعمال کر سکتے ہیں بذریعہ:

istioctl dashboard kiali # admin:admin

کیالی میش کے ذریعے موجودہ ٹریفک کا تصور کرتا ہے۔

جیسا کہ ہم دیکھ سکتے ہیں، ٹریفک کا 100% فرنٹ اینڈ سروس پر جاتا ہے، پھر v1 لیبل والے فرنٹ اینڈ پوڈز پر، کیونکہ ہم ایک سادہ nginx پراکسی استعمال کر رہے ہیں جو درخواستوں کو بیک اینڈ سروس کی طرف ری ڈائریکٹ کرتا ہے، جس کے نتیجے میں انہیں بیک اینڈ پوڈز پر بھیج دیا جاتا ہے۔ لیبل v1 کے ساتھ۔

Kiali Istio کے ساتھ بہت اچھا کام کرتا ہے اور باکسڈ میش رینڈرنگ حل فراہم کرتا ہے۔ بہت اچھا۔

کینری تعیناتی۔

ہمارے بیک اینڈ میں پہلے سے ہی دو k8s تعینات ہیں، ایک v1 کے لیے اور ایک v2 کے لیے۔ اب ہمیں صرف اسٹیو کو یہ بتانے کی ضرورت ہے کہ وہ درخواستوں کا ایک خاص فیصد v2 پر بھیج دیں۔

مرحلہ 1: 10%

اور ہمیں صرف ورچوئل سروس کے وزن کو ایڈجسٹ کرنے کی ضرورت ہے۔ 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 دونوں فارورڈ ٹریفک کو بیک اینڈ v1 اور v10 کے 1/2 کے تناسب سے۔

کیا ہوگا اگر ہمیں ٹریفک کو فرنٹ اینڈ-v2 سے صرف بیک اینڈ-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 بہت اچھا کام کرتا ہے اور اسے Kiali کے ساتھ مل کر استعمال کرنا ایک بہت ہی طاقتور امتزاج بناتا ہے۔ میری دلچسپیوں کی فہرست میں اگلا آٹومیشن اور کینری تجزیات کے لیے Spinnaker کو Istio کے ساتھ ملانا ہے۔

ماخذ: www.habr.com