🥇 کوبرنیٹس کو بڑھانا اور اس کی تکمیل کرنا (جائزہ اور ویڈیو رپورٹ)

8 اپریل کو کانفرنس میں سینٹ ہائی لوڈ++ 2019, "DevOps اور آپریشنز" سیکشن کے حصے کے طور پر، "Kubernetes کی توسیع اور تکمیل" کی ایک رپورٹ دی گئی، جس کی تخلیق میں Flant کمپنی کے تین ملازمین نے حصہ لیا۔ اس میں، ہم متعدد حالات کے بارے میں بات کرتے ہیں جن میں ہم Kubernetes کی صلاحیتوں کو بڑھانا اور ان کی تکمیل کرنا چاہتے تھے، لیکن جن کے لیے ہمیں کوئی تیار شدہ اور آسان حل نہیں ملا۔ ہمارے پاس اوپن سورس پروجیکٹس کی شکل میں ضروری حل موجود ہیں، اور یہ تقریر بھی ان کے لیے وقف ہے۔

روایت کے مطابق، ہم پیش کرنے کے لئے خوش ہیں رپورٹ کی ویڈیو (50 منٹ، مضمون سے کہیں زیادہ معلوماتی) اور متن کی شکل میں مرکزی خلاصہ۔ جاؤ!

K8s میں بنیادی اور اضافے

Kubernetes صنعت اور انتظامیہ کے نقطہ نظر کو تبدیل کر رہا ہے جو طویل عرصے سے قائم ہیں:

اس کا شکریہ۔ خلاصہ، ہم اب کنفیگریشن ترتیب دینے یا کمانڈ چلانے جیسے تصورات کے ساتھ کام نہیں کرتے ہیں (شیف، جوابدہ...)، لیکن کنٹینرز، خدمات وغیرہ کی گروپ بندی کا استعمال کرتے ہیں۔
کی باریکیوں کے بارے میں سوچے بغیر ہم درخواستیں تیار کر سکتے ہیں۔ مخصوص سائٹ، جس پر اسے لانچ کیا جائے گا: ننگی دھات، فراہم کنندگان میں سے ایک کا بادل، وغیرہ۔
K8s کے ساتھ آپ کبھی بھی زیادہ قابل رسائی نہیں رہے۔ بہترین پریکٹس بنیادی ڈھانچے کو منظم کرنے پر: اسکیلنگ تکنیک، خود شفا یابی، غلطی رواداری، وغیرہ۔

تاہم، یقینا، سب کچھ اتنا ہموار نہیں ہے: کبرنیٹس نے اپنے نئے چیلنجز بھی لائے۔

Kubernetes کوئی ایک ایسا کمبائن ہے جو تمام صارفین کے تمام مسائل حل کرتا ہے۔ کور Kubernetes صرف ان کم از کم ضروری افعال کے ایک سیٹ کے لیے ذمہ دار ہے جو اس میں موجود ہیں۔ ہر کوئی جھرمٹ:

Kubernetes کور کنٹینرز کو گروپ کرنے، ٹریفک کا انتظام کرنے اور اسی طرح کے بنیادی مجموعوں کی وضاحت کرتا ہے۔ ہم نے ان کے بارے میں مزید تفصیل سے بات کی۔ 2 سال پہلے کی رپورٹ.

دوسری طرف، K8s دستیاب فنکشنز کو بڑھانے کے لیے بہترین مواقع فراہم کرتا ہے، جو دوسروں کو بند کرنے میں مدد کرتا ہے۔ مخصوص - صارف کی ضروریات۔ Kubernetes میں اضافہ کلسٹر ایڈمنسٹریٹرز کی ذمہ داری ہے، جنہیں اپنے کلسٹر کو "صحیح شکل میں" حاصل کرنے کے لیے ضروری ہر چیز کو انسٹال اور کنفیگر کرنا چاہیے [ان کے مخصوص مسائل کو حل کرنے کے لیے]۔ یہ کس قسم کے اضافے ہیں؟ آئیے کچھ مثالیں دیکھتے ہیں۔

ایڈ آنز کی مثالیں۔

Kubernetes کو انسٹال کرنے کے بعد، ہم حیران ہوسکتے ہیں کہ وہ نیٹ ورکنگ جو نوڈ کے اندر اور نوڈس کے درمیان پوڈز کے تعامل کے لیے بہت ضروری ہے، خود کام نہیں کرتی ہے۔ Kubernetes کرنل ضروری کنکشن کی ضمانت نہیں دیتا؛ اس کے بجائے، یہ نیٹ ورک کا تعین کرتا ہے۔ انٹرفیس (CNI) تیسرے فریق کے اضافے کے لیے۔ ہمیں ان میں سے ایک ایڈ آن انسٹال کرنا چاہیے، جو نیٹ ورک کنفیگریشن کے لیے ذمہ دار ہوگا۔

ایک قریبی مثال ڈیٹا سٹوریج سلوشنز (لوکل ڈسک، نیٹ ورک بلاک ڈیوائس، سیف...) ہے۔ ابتدائی طور پر وہ بنیادی میں تھے، لیکن آمد کے ساتھ CSI صورت حال پہلے سے بیان کی گئی چیز سے ملتی جلتی ہے: انٹرفیس Kubernetes میں ہے، اور اس کا نفاذ تیسرے فریق کے ماڈیولز میں ہے۔

دیگر مثالوں میں شامل ہیں:

لاگ ان-کنٹرولرز (ان کا جائزہ دیکھیں ہمارا حالیہ مضمون).
سند مینیجر:
آپریٹرز ایڈ آنز کی ایک پوری کلاس ہے (جس میں ذکر کردہ سرٹیفکیٹ مینیجر بھی شامل ہے)، وہ پرائمیٹو اور کنٹرولر کی وضاحت کرتے ہیں۔ ان کے کام کی منطق صرف ہمارے تخیل تک محدود ہے اور ہمیں بنیادی ڈھانچے کے ریڈی میڈ اجزاء (مثال کے طور پر ڈی بی ایم ایس) کو پرائمیٹوز میں تبدیل کرنے کی اجازت دیتی ہے، جن کے ساتھ کام کرنا بہت آسان ہے (کنٹینرز کے سیٹ اور ان کی ترتیبات کے مقابلے میں)۔ آپریٹرز کی ایک بڑی تعداد لکھی گئی ہے - یہاں تک کہ اگر ان میں سے بہت سے ابھی تک پیداوار کے لئے تیار نہیں ہیں، یہ صرف وقت کی بات ہے:
میٹرکس - اس کی ایک اور مثال کہ کس طرح کبرنیٹس نے انٹرفیس (میٹرکس API) کو نفاذ سے الگ کیا (تیسرے فریق کے ایڈ آنز جیسے پرومیتھیس اڈاپٹر، ڈیٹا ڈوگ کلسٹر ایجنٹ...)۔
کے لیے نگرانی اور شماریات، جہاں عملی طور پر نہ صرف ضرورت ہے۔ پرومیتھیس اور گرافانا، بلکہ kube-state-metrics، node-exporter، وغیرہ۔

اور یہ اضافے کی مکمل فہرست نہیں ہے... مثال کے طور پر، فلانٹ کمپنی میں ہم فی الحال انسٹال کر رہے ہیں۔ 29 اضافے (یہ سب کل 249 Kubernetes اشیاء بناتے ہیں)۔ سیدھے الفاظ میں، ہم اضافہ کے بغیر کلسٹر کی زندگی کو نہیں دیکھ سکتے۔

آٹومیشن

آپریٹرز کو معمول کی کارروائیوں کو خودکار بنانے کے لیے ڈیزائن کیا گیا ہے جن کا ہم ہر روز سامنا کرتے ہیں۔ یہاں حقیقی زندگی کی مثالیں ہیں جن کے لیے آپریٹر لکھنا ایک بہترین حل ہوگا۔

درخواست کے لیے تصاویر کے ساتھ ایک پرائیویٹ (یعنی لاگ ان کی ضرورت) رجسٹری ہے۔ یہ فرض کیا جاتا ہے کہ ہر پوڈ کو ایک خاص راز تفویض کیا جاتا ہے جو رجسٹری میں تصدیق کی اجازت دیتا ہے۔ ہمارا کام اس بات کو یقینی بنانا ہے کہ یہ راز نام کی جگہ میں پایا جائے تاکہ پوڈ تصاویر ڈاؤن لوڈ کر سکیں۔ بہت ساری ایپلی کیشنز ہوسکتی ہیں (جن میں سے ہر ایک کو راز کی ضرورت ہوتی ہے)، اور رازوں کو باقاعدگی سے اپ ڈیٹ کرنا مفید ہے، اس لیے ہاتھ سے رازوں کو چھپانے کا آپشن ختم ہوجاتا ہے۔ یہ وہ جگہ ہے جہاں آپریٹر بچاؤ کے لیے آتا ہے: ہم ایک کنٹرولر بناتے ہیں جو نام کی جگہ کے ظاہر ہونے کا انتظار کرے گا اور، اس ایونٹ کی بنیاد پر، نام کی جگہ میں ایک راز کا اضافہ کرے گا۔
پوڈز سے انٹرنیٹ تک پہلے سے طے شدہ رسائی ممنوع ہے۔ لیکن بعض اوقات اس کی ضرورت پڑ سکتی ہے: رسائی کی اجازت کے طریقہ کار کے لیے یہ منطقی ہے کہ مخصوص مہارتوں کی ضرورت کے بغیر، مثال کے طور پر، نام کی جگہ میں ایک مخصوص لیبل کی موجودگی سے، محض کام کرنا۔ آپریٹر یہاں ہماری مدد کیسے کر سکتا ہے؟ ایک کنٹرولر بنایا گیا ہے جو نام کی جگہ میں لیبل کے ظاہر ہونے کا انتظار کرتا ہے اور انٹرنیٹ تک رسائی کے لیے مناسب پالیسی شامل کرتا ہے۔
اسی طرح کی صورتحال: فرض کریں کہ ہمیں ایک خاص شامل کرنے کی ضرورت ہے۔ داغدار، اگر اس کا ایک جیسا لیبل ہے (کسی قسم کے سابقہ کے ساتھ)۔ آپریٹر کے ساتھ کارروائیاں واضح ہیں...

کسی بھی کلسٹر میں، معمول کے کاموں کو حل کرنا ضروری ہے، اور صحیح طریقے سے یہ آپریٹرز کا استعمال کرتے ہوئے کیا جا سکتا ہے.

بیان کردہ تمام کہانیوں کا خلاصہ کرتے ہوئے، ہم اس نتیجے پر پہنچے کہ Kubernetes میں آرام دہ کام کے لیے آپ کی ضرورت ہے۔:A) ایڈ آنز انسٹال کریں۔، ب) آپریٹرز کی ترقی (روزمرہ کے منتظم کے کاموں کو حل کرنے کے لیے)۔

Kubernetes کے لیے بیان کیسے لکھیں؟

عام طور پر، اسکیم آسان ہے:

لیکن پھر پتہ چلا کہ:

Kubernetes API ایک غیر معمولی چیز ہے جس میں مہارت حاصل کرنے میں کافی وقت لگتا ہے۔
پروگرامنگ بھی ہر کسی کے لیے نہیں ہے (گو زبان کو ترجیحی زبان کے طور پر منتخب کیا گیا تھا کیونکہ اس کے لیے ایک خاص فریم ورک موجود ہے - آپریٹر SDK);
صورتحال خود فریم ورک کے ساتھ بھی ایسی ہی ہے۔

نیچے لائن: کنٹرولر لکھنا (آپریٹر) کو کرنا ہے۔ اہم وسائل خرچ کریں مواد کا مطالعہ کرنے کے لئے. یہ "بڑے" آپریٹرز کے لیے جائز ہو گا - کہتے ہیں، MySQL DBMS کے لیے۔ لیکن اگر ہم اوپر بیان کی گئی مثالیں یاد رکھیں (راز کھولنا، انٹرنیٹ تک پوڈز تک رسائی...)، جسے ہم صحیح طریقے سے کرنا بھی چاہتے ہیں، تو ہم سمجھیں گے کہ خرچ کی گئی کوشش اس نتیجہ سے کہیں زیادہ ہوگی جس کی ہمیں ابھی ضرورت ہے:

عام طور پر، ایک مخمصہ پیدا ہوتا ہے: بہت سارے وسائل خرچ کریں اور بیانات لکھنے کے لیے صحیح ٹول تلاش کریں، یا اسے پرانے زمانے کے طریقے سے کریں (لیکن جلدی)۔ اسے حل کرنے کے لیے - ان انتہاؤں کے درمیان سمجھوتہ کرنے کے لیے - ہم نے اپنا پروجیکٹ بنایا: شیل آپریٹر (اس کا بھی دیکھیں حالیہ اعلان مرکز پر).

شیل آپریٹر

وہ کیسے کام کرتا ہے؟ کلسٹر میں ایک پوڈ ہے جس میں شیل آپریٹر کے ساتھ گو بائنری ہے۔ اس کے آگے ایک سیٹ ہے۔ ہکس (ان کے بارے میں مزید تفصیلات - نیچے دیکھیں). شیل آپریٹر خود کچھ کو سبسکرائب کرتا ہے۔ رفت Kubernetes API میں، جس کی موجودگی پر یہ متعلقہ ہکس لانچ کرتا ہے۔

شیل آپریٹر کو کیسے پتہ چلے گا کہ کون سے ہکس کو کن واقعات پر کال کرنا ہے؟ یہ معلومات شیل آپریٹر کو خود ہکس کے ذریعے منتقل کی جاتی ہیں، اور وہ اسے بہت آسانی سے کرتے ہیں۔

ہک ایک باش اسکرپٹ یا کوئی دوسری قابل عمل فائل ہے جو ایک دلیل کو قبول کرتی ہے۔ --config اور JSON کے ساتھ جواب دیتا ہے۔ مؤخر الذکر اس بات کا تعین کرتا ہے کہ کون سی اشیاء اس میں دلچسپی رکھتی ہیں اور کن واقعات (ان اشیاء کے لیے) کا جواب دیا جانا چاہیے:

میں اپنی مثالوں میں سے ایک کے شیل آپریٹر پر عمل درآمد کی وضاحت کروں گا - ایپلیکیشن امیجز کے ساتھ نجی رجسٹری تک رسائی کے راز کو گلنا۔ یہ دو مراحل پر مشتمل ہے۔

مشق: 1. ایک ہک لکھیں۔

سب سے پہلے، ہک میں ہم عمل کریں گے --config، اس بات کا اشارہ کرتے ہوئے کہ ہم نام کی جگہوں میں دلچسپی رکھتے ہیں، اور خاص طور پر، ان کی تخلیق کے لمحے:

[[ $1 == "--config" ]] ; then
  cat << EOF
{
  "onKubernetesEvent": [
    {
      "kind": "namespace",
      "event": ["add"]
    }
  ]
}
EOF
…

منطق کیسی نظر آئے گی؟ یہ بھی کافی آسان:

…
else
  createdNamespace=$(jq -r '.[0].resourceName' $BINDING_CONTEXT_PATH)
  kubectl create -n ${createdNamespace} -f - << EOF
Kind: Secret
...
EOF
fi

پہلا مرحلہ یہ معلوم کرنا ہے کہ کون سی نام کی جگہ بنائی گئی ہے، اور دوسرا اسے استعمال کرتے ہوئے تخلیق کرنا ہے۔ kubectl اس نام کی جگہ کا راز۔

مشق: 2. تصویر کو جمع کرنا

جو کچھ باقی ہے وہ شیل آپریٹر کو بنائے گئے ہک کو منتقل کرنا ہے - یہ کیسے کریں؟ شیل آپریٹر بذات خود ایک ڈاکر امیج کے طور پر آتا ہے، لہذا ہمارا کام اس امیج میں ایک خصوصی ڈائرکٹری میں ہک کو شامل کرنا ہے۔

FROM flant/shell-operator:v1.0.0-beta.1
ADD my-handler.sh /hooks

جو کچھ باقی ہے اسے جمع کرنا اور اسے دبانا ہے:

$ docker build -t registry.example.com/my-operator:v1 .
$ docker push registry.example.com/my-operator:v1

آخری ٹچ تصویر کو کلسٹر میں تعینات کرنا ہے۔ ایسا کرنے کے لئے، چلو لکھتے ہیں تعیناتی:

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: my-operator
spec:
  template:
    spec:
      containers:
      - name: my-operator
        image: registry.example.com/my-operator:v1 # 1
      serviceAccountName: my-operator              # 2

توجہ دینے کے لئے دو نکات ہیں:

نئی تخلیق شدہ تصویر کا اشارہ؛
یہ سسٹم کا ایک جزو ہے جسے (کم سے کم) کوبرنیٹس میں ہونے والے واقعات کو سبسکرائب کرنے اور نام کی جگہوں کے راز مختص کرنے کے حقوق کی ضرورت ہوتی ہے، اس لیے ہم ہک کے لیے ایک ServiceAccount (اور قواعد کا ایک مجموعہ) بناتے ہیں۔

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

شیل آپریٹر کی دیگر خصوصیات

آپ کی منتخب کردہ قسم کی اشیاء کو محدود کرنے کے لیے جن کے ساتھ ہک کام کرے گا، وہ فلٹر کیا جا سکتا ہے، مخصوص لیبلز کے مطابق منتخب کرنا (یا استعمال کرنا matchExpressions):

"onKubernetesEvent": [
  {
    "selector": {
      "matchLabels": {
        "foo": "bar",
       },
       "matchExpressions": [
         {
           "key": "allow",
           "operation": "In",
           "values": ["wan", "warehouse"],
         },
       ],
     }
     …
  }
]

فراہم کی ڈپلیکیشن میکانزم، جو - jq فلٹر کا استعمال کرتے ہوئے - آپ کو بڑی JSON اشیاء کو چھوٹی چیزوں میں تبدیل کرنے کی اجازت دیتا ہے، جہاں صرف وہی پیرامیٹرز باقی رہ جاتے ہیں جن کی ہم تبدیلیوں کی نگرانی کرنا چاہتے ہیں۔

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

ہکس کو متحرک کرنے والے واقعات صرف کوبرنیٹس کے واقعات تک ہی محدود نہیں ہیں: شیل آپریٹر اس کے لیے مدد فراہم کرتا ہے۔ وقت کے حساب سے ہکس کو کال کرنا (روایتی شیڈیولر میں کرونٹاب کی طرح) کے ساتھ ساتھ ایک خصوصی تقریب اسٹارٹ اپ پر. ان تمام واقعات کو یکجا کر کے ایک ہی ہک پر تفویض کیا جا سکتا ہے۔

اور شیل آپریٹر کی دو مزید خصوصیات:

یہ کام کرتا ہے متضاد طور پر. چونکہ ایک Kubernetes ایونٹ (جیسے کہ ایک آبجیکٹ بنایا جا رہا ہے) موصول ہوا تھا، اس لیے کلسٹر میں دوسرے واقعات (جیسے کہ ایک ہی چیز کو حذف کیا جانا) ہو سکتا ہے، اور ہکس کو اس کا حساب دینا ہوگا۔ اگر ہک کو غلطی کے ساتھ پھانسی دی گئی تھی، تو یہ پہلے سے طے شدہ ہوگا۔ دوبارہ کال کریں کامیاب تکمیل تک (اس طرز عمل کو تبدیل کیا جا سکتا ہے)۔
برآمد کرتا ہے۔ میٹرکس Prometheus کے لیے، جس سے آپ یہ سمجھ سکتے ہیں کہ آیا شیل آپریٹر کام کر رہا ہے، ہر ہک کے لیے غلطیوں کی تعداد اور موجودہ قطار کے سائز کا پتہ لگائیں۔

رپورٹ کے اس حصے کا خلاصہ کرنے کے لیے:

ایڈ آنز انسٹال کرنا

Kubernetes کے ساتھ آرام دہ کام کے لیے، add-ons انسٹال کرنے کی ضرورت کا بھی ذکر کیا گیا۔ میں آپ کو اس کے بارے میں اپنی کمپنی کے راستے کی مثال کا استعمال کرتے ہوئے بتاؤں گا کہ ہم اسے اب کیسے کرتے ہیں۔

ہم نے کئی کلسٹرز کے ساتھ Kubernetes کے ساتھ کام کرنا شروع کیا، جس میں واحد اضافہ Ingress تھا۔ اسے ہر کلسٹر میں مختلف طریقے سے انسٹال کرنے کی ضرورت تھی، اور ہم نے مختلف ماحول کے لیے کئی YAML کنفیگریشنز بنائے: ننگی دھات، AWS...

جیسا کہ زیادہ کلسٹرز تھے، زیادہ ترتیبیں تھیں۔ اس کے علاوہ، ہم نے خود ان کنفیگریشنز کو بہتر بنایا، جس کے نتیجے میں وہ کافی متضاد بن گئے:

ہر چیز کو ترتیب دینے کے لیے، ہم نے اسکرپٹ (install-ingress.sh)، جس نے ایک دلیل کے طور پر اس قسم کے کلسٹر کو لیا جس میں ہم تعینات کریں گے، ضروری YAML کنفیگریشن تیار کی اور اسے Kubernetes میں رول آؤٹ کیا۔

مختصر یہ کہ ہمارا مزید راستہ اور اس سے جڑے استدلال کچھ یوں تھے۔

YAML کنفیگریشنز کے ساتھ کام کرنے کے لیے، ایک ٹیمپلیٹ انجن کی ضرورت ہے (پہلے مرحلے میں یہ سادہ سیڈ ہے)؛
کلسٹرز کی تعداد میں اضافے کے ساتھ، خودکار اپڈیٹنگ کی ضرورت پیش آئی (پہلا حل یہ تھا کہ اسکرپٹ کو گٹ میں ڈالا جائے، اسے کرون کا استعمال کرکے اپ ڈیٹ کیا جائے اور اسے چلایا جائے)؛
Prometheus (install-prometheus.sh)، تاہم، یہ اس حقیقت کے لیے قابل ذکر ہے کہ اس کے لیے بہت زیادہ ان پٹ ڈیٹا کی ضرورت ہوتی ہے، نیز ان کے اسٹوریج (اچھے طریقے سے - مرکزی اور ایک کلسٹر میں)، اور کچھ ڈیٹا (پاس ورڈز) خود بخود تیار کیے جا سکتے ہیں:
کلسٹرز کی بڑھتی ہوئی تعداد میں کچھ غلط ہونے کا خطرہ مسلسل بڑھ رہا تھا، لہذا ہم نے محسوس کیا کہ انسٹالرز (یعنی دو رسم الخط: Ingress اور Prometheus کے لیے) اسٹیجنگ کی ضرورت تھی (گٹ میں کئی شاخیں، انہیں متعلقہ میں اپ ڈیٹ کرنے کے لیے کئی کرون: مستحکم یا ٹیسٹ کلسٹرز)؛
с kubectl apply اس کے ساتھ کام کرنا مشکل ہو گیا ہے کیونکہ یہ اعلانیہ نہیں ہے اور صرف اشیاء بنا سکتا ہے، لیکن ان کی حیثیت کے بارے میں فیصلہ نہیں کر سکتا/ انہیں حذف کر سکتا ہے۔
ہمارے پاس کچھ فنکشنز موجود نہیں تھے جنہیں ہم نے اس وقت لاگو نہیں کیا تھا:
- کلسٹر اپ ڈیٹس کے نتیجے پر مکمل کنٹرول،
- ڈیٹا کی بنیاد پر کچھ پیرامیٹرز (انسٹالیشن اسکرپٹس کے لیے ان پٹ) کا خودکار تعین جو کلسٹر (دریافت) سے حاصل کیا جا سکتا ہے،
- مسلسل دریافت کی شکل میں اس کی منطقی ترقی۔

ہم نے اپنے دوسرے پروجیکٹ کے فریم ورک کے اندر اس تمام جمع شدہ تجربے کو لاگو کیا - ایڈون آپریٹر.

ایڈون آپریٹر

یہ پہلے ہی ذکر کردہ شیل آپریٹر پر مبنی ہے۔ پورا نظام اس طرح لگتا ہے:

شیل آپریٹر ہکس میں درج ذیل کو شامل کیا گیا ہے۔

اقدار کا ذخیرہ,
ہیلم چارٹ,
جزو کہ ویلیوز اسٹور کی نگرانی کرتا ہے۔ اور - کسی تبدیلی کی صورت میں - ہیلم سے چارٹ کو دوبارہ رول کرنے کو کہتا ہے۔

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

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

اب، جب Kubernetes میں کچھ ہوتا ہے، تو ہم عالمی ہک کا استعمال کرتے ہوئے اس پر ردعمل ظاہر کر سکتے ہیں اور عالمی اسٹور میں کچھ تبدیل کر سکتے ہیں۔ اس تبدیلی کو دیکھا جائے گا اور اس کی وجہ سے کلسٹر میں موجود تمام ماڈیولز کو رول آؤٹ کیا جائے گا:

یہ اسکیم ایڈ آنز انسٹال کرنے کے لیے ان تمام تقاضوں کو پورا کرتی ہے جو اوپر بیان کیے گئے ہیں:

ہیلم ٹیمپلیٹنگ اور اعلانیہ کے لئے ذمہ دار ہے۔
آٹو اپ ڈیٹ کے مسئلے کو عالمی ہک کا استعمال کرتے ہوئے حل کیا گیا تھا، جو ایک شیڈول کے مطابق رجسٹری میں جاتا ہے اور، اگر اسے وہاں ایک نیا سسٹم امیج نظر آتا ہے، تو اسے رول آؤٹ کر دیتا ہے (یعنی "خود")۔
کلسٹر میں ذخیرہ کرنے کی ترتیبات کو استعمال کرتے ہوئے لاگو کیا جاتا ہے۔ کنفیگ میپ، جس میں سٹوریجز کے لیے بنیادی ڈیٹا ہوتا ہے (اسٹارٹ اپ میں وہ سٹوریجز میں لوڈ ہوتے ہیں)۔
پاس ورڈ کی تیاری، دریافت اور مسلسل دریافت کے مسائل کو ہکس کا استعمال کرتے ہوئے حل کیا گیا۔
اسٹیجنگ ٹیگز کی بدولت حاصل کی جاتی ہے، جسے ڈاکر باکس سے باہر سپورٹ کرتا ہے۔
نتائج کو میٹرکس کا استعمال کرتے ہوئے مانیٹر کیا جاتا ہے جس کے ذریعے ہم حیثیت کو سمجھ سکتے ہیں۔

یہ پورا سسٹم گو میں سنگل بائنری کی شکل میں لاگو ہوتا ہے جسے ایڈون آپریٹر کہتے ہیں۔ اس سے خاکہ آسان نظر آتا ہے:

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

"Flant" استعمال کرتا ہے ایڈون آپریٹر 70+ Kubernetes کلسٹرز پر۔ موجودہ صورت حال - الفا ورژن. اب ہم بیٹا کو جاری کرنے کے لیے دستاویزات تیار کر رہے ہیں، لیکن ابھی کے لیے مخزن میں مثالیں دستیاب ہیںجس کی بنیاد پر آپ اپنا ایڈون بنا سکتے ہیں۔

میں ایڈون آپریٹر کے ماڈیول کہاں سے حاصل کرسکتا ہوں؟ ہماری لائبریری کی اشاعت ہمارے لیے اگلا مرحلہ ہے؛ ہم اسے گرمیوں میں کرنے کا ارادہ رکھتے ہیں۔

ویڈیوز اور سلائیڈز

کارکردگی سے ویڈیو (~50 منٹ):

رپورٹ کی پیشکش:

PS

ہمارے بلاگ پر دیگر رپورٹس:

«ڈیٹا بیس اور کبرنیٹس؛ " (دمتری اسٹولیاروف؛ 8 نومبر 2018 ہائی لوڈ++ پر);
«نگرانی اور Kubernetes؛ " (دمتری اسٹولیاروف؛ 28 مئی 2018 کو روٹ کانف میں);
«Kubernetes اور GitLab کے ساتھ CI/CD بہترین طرز عمل؛ " (دمتری اسٹولیاروف؛ 7 نومبر 2017 ہائی لوڈ++ پر);
«چھوٹے منصوبوں میں Kubernetes کے ساتھ ہمارا تجربہ؛ " (دمتری اسٹولیاروف؛ 6 جون، 2017 روٹ کانف میں).

آپ کو درج ذیل اشاعتوں میں بھی دلچسپی ہو سکتی ہے:

«شیل آپریٹر کا تعارف: کبرنیٹس کے لیے آپریٹرز بنانا آسان ہو گیا ہے۔'.

ماخذ: www.habr.com

Kubernetes کی توسیع اور تکمیل (جائزہ اور ویڈیو رپورٹ)