مختلف ڈیٹا سینٹرز میں کبرنیٹس کلسٹرز کو کیسے جوڑیں۔

ہماری Kubernetes Quick Start سیریز میں خوش آمدید۔ یہ ایک باقاعدہ کالم ہے جس میں سب سے دلچسپ سوالات ہیں جو ہمیں آن لائن اور ہماری تربیت میں موصول ہوتے ہیں۔ Kubernetes ماہر جوابات۔

آج کا ماہر ڈینیئل پولینچک ہے (ڈینیئل پولینسک)۔ ڈینیئل میں ایک انسٹرکٹر اور سافٹ ویئر ڈویلپر کے طور پر کام کرتا ہے۔ Learnk8s.

اگر آپ اپنے سوال کا جواب اگلی پوسٹ میں چاہتے ہیں، ای میل کے ذریعے ہم سے رابطہ کریں۔ یا ٹویٹر: @learnk8s.

پچھلی پوسٹس چھوٹ گئی؟ انہیں یہاں تلاش کریں۔.

مختلف ڈیٹا سینٹرز میں کبرنیٹس کلسٹرز کو کیسے جوڑیں؟

مختصراً: Kubefed v2 جلد آرہا ہے۔، اور میں اس کے بارے میں پڑھنے کی بھی سفارش کرتا ہوں۔ کاپر и ملٹی کلسٹر شیڈیولر پروجیکٹ.

اکثر، بنیادی ڈھانچے کو نقل کیا جاتا ہے اور مختلف علاقوں میں تقسیم کیا جاتا ہے، خاص طور پر کنٹرول شدہ ماحول میں۔

اگر ایک خطہ دستیاب نہیں ہے، تو رکاوٹوں سے بچنے کے لیے ٹریفک کو دوسرے علاقے میں بھیج دیا جاتا ہے۔

Kubernetes کے ساتھ، آپ ایک جیسی حکمت عملی استعمال کر سکتے ہیں اور کام کے بوجھ کو مختلف علاقوں میں تقسیم کر سکتے ہیں۔

آپ کے پاس فی ٹیم، علاقہ، ماحول، یا ان عناصر کا مجموعہ ایک یا زیادہ کلسٹرز ہو سکتے ہیں۔

آپ کے کلسٹرز کو مختلف کلاؤڈز اور آن پریمیسس میں ہوسٹ کیا جا سکتا ہے۔

لیکن آپ اس طرح کے جغرافیائی پھیلاؤ کے لیے انفراسٹرکچر کی منصوبہ بندی کیسے کرتے ہیں؟
کیا آپ کو ایک نیٹ ورک پر کئی کلاؤڈ ماحول کے لیے ایک بڑا کلسٹر بنانے کی ضرورت ہے؟
یا بہت سے چھوٹے کلسٹرز ہیں اور ان کو کنٹرول کرنے اور ہم آہنگ کرنے کا کوئی طریقہ تلاش کریں؟

ایک لیڈر شپ کلسٹر

ایک نیٹ ورک پر ایک کلسٹر بنانا اتنا آسان نہیں ہے۔

تصور کریں کہ آپ کو حادثہ پیش آیا ہے، کلسٹر سیگمنٹس کے درمیان رابطہ ختم ہو گیا ہے۔

اگر آپ کے پاس ایک ماسٹر سرور ہے، تو آدھے وسائل نئے کمانڈز حاصل کرنے کے قابل نہیں ہوں گے کیونکہ وہ ماسٹر سے رابطہ نہیں کر سکیں گے۔

اور اسی وقت آپ کے پاس پرانی روٹنگ ٹیبلز ہیں (kube-proxy نئے ڈاؤن لوڈ نہیں کر سکتے ہیں) اور کوئی اضافی پوڈ (کبلیٹ اپ ڈیٹ کی درخواست نہیں کر سکتے ہیں)۔

معاملات کو مزید خراب کرنے کے لیے، اگر Kubernetes کو کوئی نوڈ نظر نہیں آتا ہے، تو یہ اسے یتیم کے طور پر نشان زد کرتا ہے اور غائب پوڈز کو موجودہ نوڈس میں تقسیم کرتا ہے۔

نتیجے کے طور پر، آپ کے پاس دو گنا زیادہ پھلیاں ہیں۔

اگر آپ ہر علاقے کے لیے ایک ماسٹر سرور بناتے ہیں، تو etcd ڈیٹا بیس میں متفقہ الگورتھم کے ساتھ مسائل ہوں گے۔ (تقریبا. ایڈ — درحقیقت، etcd ڈیٹا بیس کا ماسٹر سرورز پر واقع ہونا ضروری نہیں ہے۔ اسے ایک ہی علاقے میں سرورز کے الگ گروپ پر چلایا جا سکتا ہے۔ سچ ہے، ایک ہی وقت میں کلسٹر کی ناکامی کا ایک نقطہ ہو رہا ہے. لیکن جلدی۔)

etcd استعمال کرتا ہے۔ بیڑا الگورتھمڈسک پر لکھنے سے پہلے قیمت پر گفت و شنید کرنا۔
یعنی، ریاست کو etcd پر لکھے جانے سے پہلے زیادہ تر مثالوں کو اتفاق رائے تک پہنچنا چاہیے۔

اگر etcd مثالوں کے درمیان لیٹنسی ڈرامائی طور پر بڑھ جاتی ہے، جیسا کہ مختلف خطوں میں تین etcd مثالوں کے ساتھ ہوتا ہے، تو کسی قدر کو گفت و شنید کرنے اور اسے ڈسک پر لکھنے میں کافی وقت لگتا ہے۔
یہ کبرنیٹس کنٹرولرز میں ظاہر ہوتا ہے۔

کنٹرولر مینیجر کو تبدیلی کے بارے میں جاننے اور ڈیٹا بیس پر جواب لکھنے کے لیے مزید وقت درکار ہے۔

اور چونکہ ایک کنٹرولر نہیں ہے، بلکہ کئی، ایک سلسلہ ردعمل کا نتیجہ ہوتا ہے اور پورا کلسٹر بہت آہستہ سے کام کرنا شروع کر دیتا ہے۔.

etcd اتنی تاخیر سے حساس ہے۔ سرکاری دستاویزات میں باقاعدہ ہارڈ ڈرائیوز کے بجائے SSDs استعمال کرنے کی سفارش کی گئی ہے۔.

فی الحال ایک کلسٹر کے لیے بڑے نیٹ ورک کی کوئی اچھی مثالیں نہیں ہیں۔

بنیادی طور پر، ڈویلپر کمیونٹی اور SIG-کلسٹر گروپ یہ جاننے کی کوشش کر رہے ہیں کہ کس طرح کلسٹرز کو آرکیسٹریٹ کیا جائے جس طرح Kubernetes آرکیسٹریٹس کنٹینرز کرتا ہے۔

آپشن 1: کلسٹر فیڈریشن کیوب فیڈ کے ساتھ

SIG-کلسٹر کی طرف سے سرکاری جواب - kubefed2، اصل کیوب فیڈریشن کلائنٹ اور آپریٹر کا ایک نیا ورژن.

پہلی بار، ہم نے کیوب فیڈریشن ٹول کا استعمال کرتے ہوئے کلسٹرز کے مجموعے کو ایک واحد چیز کے طور پر منظم کرنے کی کوشش کی۔

آغاز اچھا تھا لیکن آخر میں کیوب فیڈریشن کبھی مقبول نہیں ہوسکی کیونکہ اس نے تمام وسائل کا ساتھ نہیں دیا۔

اس نے وفاق کی فراہمی اور خدمات کی حمایت کی، لیکن اسٹیٹفول سیٹس کی نہیں، مثال کے طور پر۔
نیز، فیڈریشن کی ترتیب تشریحات کی شکل میں منتقل کی گئی تھی اور لچکدار نہیں تھی۔

تصور کریں کہ آپ صرف تشریحات کا استعمال کرتے ہوئے فیڈریشن میں ہر کلسٹر کے لئے نقل کی تقسیم کو کیسے بیان کرسکتے ہیں۔

یہ ایک مکمل گڑبڑ تھی۔

SIG-cluster نے kubefed v1 کے بعد کافی کام کیا اور ایک مختلف زاویے سے مسئلہ سے رجوع کرنے کا فیصلہ کیا۔

تشریحات کے بجائے، انہوں نے ایک کنٹرولر جاری کرنے کا فیصلہ کیا جو کلسٹرز پر نصب ہے۔ اسے کسٹم ریسورس ڈیفینیشنز (CRDs) کا استعمال کرتے ہوئے اپنی مرضی کے مطابق بنایا جا سکتا ہے۔

ہر ایک وسائل کے لیے جو فیڈریشن کا حصہ ہو گا، آپ کے پاس تین حصوں کے ساتھ ایک حسب ضرورت CRD تعریف ہے:

• وسائل کی معیاری تعریف، مثال کے طور پر تعیناتی؛
• سیکشن placementجہاں آپ وضاحت کرتے ہیں کہ وفاق میں وسائل کی تقسیم کیسے کی جائے گی۔
• سیکشن override، جہاں ایک مخصوص وسائل کے لیے آپ پلیسمنٹ سے وزن اور پیرامیٹرز کو اوور رائیڈ کر سکتے ہیں۔

پلیسمنٹ اور اوور رائڈ سیکشنز کے ساتھ مشترکہ ڈیلیوری کی ایک مثال یہ ہے۔

apiVersion: types.federation.k8s.io/v1alpha1
kind: FederatedDeployment
metadata:
  name: test-deployment
  namespace: test-namespace
spec:
  template:
    metadata:
      labels:
        app: nginx
    spec:
      replicas: 3
      selector:
        matchLabels:
          app: nginx
      template:
        metadata:
          labels:
            app: nginx
        spec:
          containers:
            - image: nginx
              name: nginx
  placement:
    clusterNames:
      - cluster2
      - cluster1
  overrides:
    - clusterName: cluster2
      clusterOverrides:
        - path: spec.replicas
          value: 5

جیسا کہ آپ دیکھ سکتے ہیں، سپلائی کو دو کلسٹروں میں تقسیم کیا جاتا ہے: cluster1 и cluster2.

پہلا کلسٹر تین نقلیں فراہم کرتا ہے، اور دوسرا 5 پر سیٹ کیا گیا ہے۔

اگر آپ کو نقل کی تعداد پر مزید کنٹرول کی ضرورت ہے تو، kubefed2 ایک نیا ReplicaSchedulingPreference آبجیکٹ فراہم کرتا ہے جہاں نقلیں وزن کی جا سکتی ہیں:

apiVersion: scheduling.federation.k8s.io/v1alpha1
kind: ReplicaSchedulingPreference
metadata:
  name: test-deployment
  namespace: test-ns
spec:
  targetKind: FederatedDeployment
  totalReplicas: 9
  clusters:
    A:
      weight: 1
    B:
      weight: 2

CRD کا ڈھانچہ اور API ابھی تک مکمل طور پر تیار نہیں ہے، اور سرکاری پروجیکٹ کے ذخیرے میں فعال کام جاری ہے۔

kubefed2 پر نظر رکھیں، لیکن یاد رکھیں کہ یہ ابھی تک پیداوار کے لیے موزوں نہیں ہے۔

سے kubefed2 کے بارے میں مزید جانیں۔ kubefed2 کے بارے میں سرکاری مضمون Kubernetes کے بارے میں بلاگ میں اور میں kubefed پروجیکٹ کا سرکاری ذخیرہ.

آپشن 2: Booking.com کے انداز میں کلسٹرز کو یکجا کرنا

Booking.com کے ڈویلپرز نے kubefed v2 پر کام نہیں کیا، لیکن وہ Shipper کے ساتھ آئے - ایک آپریٹر جو کئی کلسٹرز، کئی علاقوں اور کئی بادلوں میں ڈیلیوری کے لیے ہے۔

کاپر کچھ حد تک kubefed2 سے ملتا جلتا ہے۔

دونوں ٹولز آپ کو اپنی ملٹی کلسٹر تعیناتی کی حکمت عملی کو اپنی مرضی کے مطابق کرنے کی اجازت دیتے ہیں (کون سے کلسٹرز استعمال ہوتے ہیں اور ان کی کتنی نقلیں ہیں)۔

لیکن شپپر کا مقصد ترسیل کے دوران غلطیوں کے خطرے کو کم کرنا ہے۔

شپپر میں، آپ ان اقدامات کی ایک سیریز کی وضاحت کر سکتے ہیں جو پچھلی اور موجودہ تعیناتی اور آنے والی ٹریفک کے حجم کے درمیان نقل کی تقسیم کو بیان کرتے ہیں۔

جب آپ کسی وسیلہ کو کسی کلسٹر کی طرف دھکیلتے ہیں، تو Shipper کنٹرولر بتدریج اس تبدیلی کو تمام جوائنڈ کلسٹروں میں رول آؤٹ کرتا ہے۔

اس کے علاوہ، شپر بہت محدود ہے.

مثال کے طور پر، یہ ہیلم چارٹس کو بطور ان پٹ قبول کرتا ہے۔ اور ونیلا وسائل کی حمایت نہیں کرتا ہے۔
عام اصطلاحات میں، شپپر اس طرح کام کرتا ہے۔

معیاری ترسیل کے بجائے، آپ کو ایک ایپلیکیشن وسیلہ بنانے کی ضرورت ہے جس میں ہیلم چارٹ شامل ہو:

apiVersion: shipper.booking.com/v1alpha1
kind: Application
metadata:
  name: super-server
spec:
  revisionHistoryLimit: 3
  template:
    chart:
      name: nginx
      repoUrl: https://storage.googleapis.com/shipper-demo
      version: 0.0.1
    clusterRequirements:
      regions:
        - name: local
    strategy:
      steps:
        - capacity:
            contender: 1
            incumbent: 100
          name: staging
          traffic:
            contender: 0
            incumbent: 100
        - capacity:
            contender: 100
            incumbent: 0
          name: full on
          traffic:
            contender: 100
            incumbent: 0
    values:
      replicaCount: 3

ایک سے زیادہ کلسٹرز کے انتظام کے لیے شپپر ایک اچھا آپشن ہے، لیکن ہیلم کے ساتھ اس کا قریبی تعلق ہی راستے میں آتا ہے۔

کیا ہوگا اگر ہم سب ہیلم سے سوئچ کریں۔ اپنی مرضی کے مطابق بنائیں یا کیپیٹن?

شپپر اور اس کے فلسفہ کے بارے میں مزید معلومات حاصل کریں۔ یہ سرکاری پریس ریلیز.

اگر آپ کوڈ میں کھودنا چاہتے ہیں، سرکاری پروجیکٹ کے ذخیرے کی طرف جائیں۔.

آپشن 3: "جادو" کلسٹر کا انضمام

Kubefed v2 اور Shipper کلسٹر فیڈریشن کے ساتھ کام کرتے ہیں، حسب ضرورت وسائل کی تعریف کے ذریعے کلسٹرز کو نئے وسائل فراہم کرتے ہیں۔

لیکن کیا ہوگا اگر آپ تمام ڈیلیوریز، اسٹیٹفول سیٹس، ڈیمن سیٹس وغیرہ کو ضم کرنے کے لیے دوبارہ نہیں لکھنا چاہتے؟

YAML کو تبدیل کیے بغیر فیڈریشن میں موجودہ کلسٹر کو کیسے شامل کیا جائے؟

ملٹی کلسٹر شیڈیولر ایک ایڈمرلٹی پروجیکٹ ہے۔، جو کلسٹرز پر کام کے بوجھ کو شیڈول کرنے سے متعلق ہے۔

لیکن کلسٹر کے ساتھ تعامل کرنے اور وسائل کو حسب ضرورت تعریفوں میں لپیٹنے کے لیے ایک نئے طریقے کے ساتھ آنے کے بجائے، ملٹی کلسٹر-شیڈیولر معیاری Kubernetes لائف سائیکل میں سرایت کرتا ہے اور پوڈز بنانے والی تمام کالوں کو روکتا ہے۔

ہر تخلیق شدہ پوڈ کو فوری طور پر ایک ڈمی سے تبدیل کیا جاتا ہے۔

ملٹی کلسٹر شیڈیولر استعمال کرتا ہے۔ رسائی میں ترمیم کے لیے ویب ہکسکال کو روکنے اور ایک بیکار ڈمی پوڈ بنانے کے لیے۔

اصل پوڈ ایک اور منصوبہ بندی کے چکر سے گزرتا ہے جہاں، پوری فیڈریشن کی پولنگ کے بعد، تقرری کا فیصلہ کیا جاتا ہے۔

آخر میں، پوڈ کو ٹارگٹ کلسٹر تک پہنچایا جاتا ہے۔

نتیجے کے طور پر، آپ کے پاس ایک اضافی پوڈ ہے جو کچھ نہیں کرتا، صرف جگہ لیتا ہے۔

فائدہ یہ ہے کہ آپ کو سپلائی کو یکجا کرنے کے لیے نئے وسائل لکھنے کی ضرورت نہیں تھی۔

ہر وسیلہ جو پوڈ بناتا ہے خود بخود ضم ہونے کے لیے تیار ہے۔

یہ دلچسپ ہے، کیونکہ اچانک آپ کو کئی علاقوں میں سپلائیز تقسیم کر دی گئیں، اور آپ نے محسوس بھی نہیں کیا۔ تاہم، یہ کافی خطرناک ہے، کیونکہ یہاں سب کچھ جادو پر منحصر ہے۔

لیکن جب شپپر زیادہ تر ترسیل کے اثرات کو کم کرنے کی کوشش کر رہا ہے، ملٹی کلسٹر-شیڈیولر زیادہ عام کاموں کو سنبھالتا ہے اور شاید بیچ کی ملازمتوں کے لیے بہتر موزوں ہے۔

اس میں بتدریج ڈیلیوری کا جدید طریقہ کار نہیں ہے۔

ملٹی کلسٹر شیڈیولر کے بارے میں مزید یہاں پر پایا جا سکتا ہے۔ سرکاری ذخیرہ کا صفحہ.

اگر آپ ایکشن میں ملٹی کلسٹر شیڈیولر کے بارے میں پڑھنا چاہتے ہیں تو ایڈمرلٹی کے پاس ہے۔ Argo کے ساتھ استعمال کا دلچسپ معاملہ - ورک فلو، ایونٹس، سی آئی اور سی ڈی کبرنیٹس۔

دوسرے ٹولز اور حل

متعدد کلسٹرز کو جوڑنا اور ان کا انتظام کرنا ایک پیچیدہ کام ہے، اور اس کا کوئی عالمگیر حل نہیں ہے۔

اگر آپ اس موضوع کو مزید دریافت کرنا چاہتے ہیں، تو یہاں کچھ وسائل ہیں:

• رینچر کے ذریعہ آبدوز ایک ٹول ہے جو مختلف Kubernetes کلسٹرز کے اوورلے نیٹ ورکس کو جوڑتا ہے۔
• ریٹیل چین کا ہدف استعمال کرتا ہے۔ Unimatrix Spinnaker کے ساتھ مل کر متعدد کلسٹروں میں تعیناتی کو آرکیسٹریٹ کرتا ہے۔.
• IPV6 اور استعمال کرنے کی کوشش کریں۔ کئی علاقوں میں واحد نیٹ ورک.
• مثال کے طور پر آپ سروس میش استعمال کر سکتے ہیں۔ ایک سے زیادہ کلسٹرز کو جوڑنے کے لیے Istio.
• Cilium، ایک کنٹینر نیٹ ورک انٹرفیس پلگ ان پیش کرتا ہے۔ کلسٹر میش فنکشن، جو آپ کو کئی کلسٹرز کو یکجا کرنے کی اجازت دیتا ہے۔

آج کیلئے بس اتنا ہی

آخر تک پڑھنے کے لیے آپ کا شکریہ!

اگر آپ جانتے ہیں کہ ایک سے زیادہ کلسٹرز کو زیادہ مؤثر طریقے سے کیسے جوڑنا ہے، ہمیں بتاو.

ہم آپ کا طریقہ لنکس میں شامل کریں گے۔

کرس نیسبٹ اسمتھ کا خصوصی شکریہ (کرس نیسبٹ اسمتھ) اور ونسنٹ ڈی سمی (ونسنٹ ڈی سمیٹ) (ریلیبلٹی انجینئر ان swatmobile.ioمضمون کو پڑھنے اور فیڈریشن کے کام کرنے کے بارے میں مفید معلومات شیئر کرنے کے لیے۔

ماخذ: www.habr.com