رپورٹ Kubernetes میں ایک آپریٹر تیار کرنے، اس کے فن تعمیر اور آپریشن کے بنیادی اصولوں کو ڈیزائن کرنے کے عملی مسائل کے لیے وقف ہے۔
رپورٹ کے پہلے حصے میں، ہم غور کریں گے:
- Kubernetes میں آپریٹر کیا ہے اور اس کی ضرورت کیوں ہے؛
- آپریٹر پیچیدہ نظاموں کے انتظام کو کس طرح آسان بناتا ہے۔
- آپریٹر کیا کرسکتا ہے اور آپریٹر کیا نہیں کرسکتا۔
اگلا، ہم آپریٹر کے اندرونی ڈھانچے کی بحث کی طرف رجوع کرتے ہیں۔ قدم بہ قدم آپریٹر کے فن تعمیر اور آپریشن پر غور کریں۔ آئیے تفصیل سے تجزیہ کرتے ہیں:
- آپریٹر اور Kubernetes کے درمیان تعامل؛
- آپریٹر کون سے کام کرتا ہے اور کبرنیٹس کو کیا ڈیلیگیٹ کرتا ہے۔
Kubernetes میں شارڈز اور ڈیٹا بیس کی نقلوں کے انتظام پر غور کریں۔
اگلا، ہم ڈیٹا اسٹوریج کے مسائل پر بات کریں گے:
- آپریٹر کے نقطہ نظر سے پرسسٹنٹ اسٹوریج کے ساتھ کیسے کام کیا جائے؛
- مقامی اسٹوریج کے استعمال کے نقصانات۔
رپورٹ کے آخری حصے میں، ہم درخواست کی عملی مثالوں پر غور کریں گے۔ ایمیزون یا گوگل کلاؤڈ سروس کے ساتھ۔ رپورٹ ClickHouse کے آپریٹر کی ترقی اور آپریٹنگ تجربے کی مثال پر مبنی ہے۔
ویڈیو:
میرا نام ولادیسلاو کلیمینکو ہے۔ آج میں آپریٹر کو تیار کرنے اور چلانے کے اپنے تجربے کے بارے میں بات کرنا چاہتا تھا، اور یہ ڈیٹا بیس کلسٹرز کے انتظام کے لیے ایک خصوصی آپریٹر ہے۔ مثال کے طور پر کلک ہاؤس کلسٹر کو منظم کرنے کے لیے۔
ہمارے پاس آپریٹر اور ClickHouse کے بارے میں بات کرنے کا موقع کیوں ہے؟
- ہم کلک ہاؤس کی حمایت اور ترقی کرتے ہیں۔
- اس وقت، ہم آہستہ آہستہ ClickHouse کی ترقی میں اپنا حصہ ڈالنے کی کوشش کر رہے ہیں۔ اور کلک ہاؤس میں تبدیلیوں کی مقدار کے لحاظ سے ہم Yandex کے بعد دوسرے نمبر پر ہیں۔
- ہم کلک ہاؤس ماحولیاتی نظام کے لیے اضافی منصوبے بنانے کی کوشش کر رہے ہیں۔
میں ان منصوبوں میں سے ایک کے بارے میں بات کرنا چاہوں گا۔ یہ Kubernetes کے ClickHouse-آپریٹر کے بارے میں ہے۔
اپنی رپورٹ میں، میں دو موضوعات پر بات کرنا چاہوں گا:
- پہلا موضوع یہ ہے کہ ہمارا ClickHouse ڈیٹا بیس آپریٹر Kubernetes میں کیسے کام کرتا ہے۔
- دوسرا موضوع یہ ہے کہ کوئی بھی آپریٹر کیسے کام کرتا ہے، یعنی یہ Kubernetes کے ساتھ کیسے تعامل کرتا ہے۔
تاہم، یہ دو سوالات میری پوری رپورٹ میں ایک دوسرے کو آپس میں جوڑیں گے۔
میں جو کچھ کہنا چاہ رہا ہوں اسے سننے میں کون دلچسپی لے گا؟
- سب سے زیادہ دلچسپ وہ لوگ ہوں گے جو آپریٹرز کا استحصال کرتے ہیں۔
- یا ان لوگوں کے لیے جو اپنا بنانا چاہتے ہیں تاکہ یہ سمجھ سکیں کہ یہ اندر کیسے کام کرتا ہے، آپریٹر کبرنیٹس کے ساتھ کیسے تعامل کرتا ہے، اور کیا نقصانات ظاہر ہو سکتے ہیں۔
آج ہم جس بات پر بات کرنے جا رہے ہیں اسے بہتر طور پر سمجھنے کے لیے، یہ جاننا اچھا ہو گا کہ Kubernetes کیسے کام کرتا ہے اور کلاؤڈ کمپیوٹنگ میں اس کا بنیادی پس منظر ہے۔
ClickHouse کیا ہے؟ یہ ایک کالم ڈیٹا بیس ہے جس میں تجزیاتی سوالات کی آن لائن پروسیسنگ کی تفصیلات ہیں۔ اور یہ مکمل طور پر اوپن سورس ہے۔
اور ہمیں صرف دو چیزیں جاننے کی ضرورت ہے۔ آپ کو یہ جاننے کی ضرورت ہے کہ یہ ایک ڈیٹا بیس ہے، اس لیے جو میں آپ کو بتاؤں گا وہ تقریباً کسی بھی ڈیٹا بیس پر لاگو ہوگا۔ اور حقیقت یہ ہے کہ ClickHouse DBMS اسکیل بہت اچھی طرح سے اسکیل ایبلٹی کو تقریباً لکیری دیتا ہے۔ اور اس وجہ سے، کلسٹر کی حالت ClickHouse کے لیے ایک قدرتی حالت ہے۔ اور ہم سب سے زیادہ اس بات پر بحث کرنے میں دلچسپی رکھتے ہیں کہ Kubernetes میں ClickHouse کلسٹر کی خدمت کیسے کی جائے۔
اس کی وہاں ضرورت کیوں ہے؟ ہم اسے خود کیوں نہیں چلا سکتے؟ اور جوابات جزوی طور پر تکنیکی اور جزوی طور پر تنظیمی ہیں۔
- عملی طور پر، زیادہ سے زیادہ اکثر ہم ایسی صورت حال کا سامنا کرتے ہیں جب بڑی کمپنیوں میں تقریبا تمام اجزاء پہلے سے ہی Kubernetes میں ہوتے ہیں. ڈیٹا بیس کے باہر رہیں۔
- اور زیادہ سے زیادہ اکثر یہ سوال پوچھا جاتا ہے: "کیا اسے اندر رکھا جا سکتا ہے؟"۔ لہذا، بڑی کمپنیاں اپنے ڈیٹا گوداموں کو تیزی سے منظم کرنے کے قابل ہونے کے لیے انتظام کی زیادہ سے زیادہ یکجہتی پیدا کرنے کی کوشش کر رہی ہیں۔
- اور یہ خاص طور پر مدد کرتا ہے اگر آپ کو ایک ہی چیز کو کسی نئی جگہ پر دہرانے کے زیادہ سے زیادہ موقع کی ضرورت ہو، یعنی زیادہ سے زیادہ پورٹیبلٹی۔
یہ کتنا آسان یا مشکل ہے؟ یہ، یقینا، ہاتھ سے کیا جا سکتا ہے. لیکن یہ اتنا آسان نہیں ہے، کیونکہ ہم خود Kubernetes کے انتظام کی پیچیدگیوں کو جوڑتے ہیں، لیکن ساتھ ہی ClickHouse کی تفصیلات بھی عائد کی جاتی ہیں۔ اور یہ اس طرح کی ایک جمع باہر کر دیتا ہے.
اور سب مل کر، یہ ٹیکنالوجیز کا کافی بڑا مجموعہ فراہم کرتا ہے، جس کا انتظام کرنا پہلے سے ہی کافی مشکل ہوتا جا رہا ہے، کیونکہ Kubernetes اپنے روزمرہ کے مسائل کو کام میں لاتا ہے، اور ClickHouse اپنے مسائل کو روزمرہ کے کام میں لاتا ہے۔ خاص طور پر اگر ہمارے پاس کئی کلک ہاؤسز ہیں، اور ہمیں ان کے ساتھ مسلسل کچھ کرنے کی ضرورت ہے۔
متحرک کنفیگریشن والے ClickHouse میں کافی بڑی تعداد میں مسائل ہیں جو DevOps پر مستقل بوجھ پیدا کرتے ہیں:
- جب ہم کلک ہاؤس میں کچھ تبدیل کرنا چاہتے ہیں، مثال کے طور پر، ایک ریپلیکا، ایک شارڈ شامل کریں، تو ہمیں کنفیگریشن کو منظم کرنے کی ضرورت ہے۔
- پھر ڈیٹا سکیم کو تبدیل کریں، کیونکہ ClickHouse میں شارڈنگ کا ایک مخصوص طریقہ ہے۔ وہاں ڈیٹا سکیم کو ترتیب دینا، ترتیب دینا ضروری ہے۔
- آپ کو نگرانی قائم کرنے کی ضرورت ہے۔
- نئے شارڈز کے لیے نوشتہ جات کا مجموعہ، نئی نقلوں کے لیے۔
- بحالی کا خیال رکھیں۔
- اور دوبارہ شروع کریں۔
یہ اس طرح کے معمول کے کام ہیں جن کو چلانے میں میں بہت آسانی کرنا چاہوں گا۔
Kubernetes خود آپریشن میں بہت مدد کرتا ہے، لیکن بنیادی نظام چیزوں پر.
Kubernetes چیزوں کو آسان بنانے اور خودکار کرنے میں بہت اچھا ہے جیسے:
- بازیابی۔
- دوبارہ شروع کریں.
- اسٹوریج مینجمنٹ۔
یہ اچھی بات ہے، یہ صحیح سمت ہے، لیکن وہ ڈیٹا بیس کلسٹر کو چلانے کے طریقہ سے مکمل طور پر باہر ہے۔
میں مزید چاہتا ہوں، میں چاہتا ہوں کہ پورا ڈیٹا بیس ہمارے لیے Kubernetes میں کام کرے۔
میں ایک بڑے جادوئی سرخ بٹن کی طرح کچھ حاصل کرنا چاہوں گا جسے آپ دباتے ہیں اور آپ کے پاس ایک کلسٹر تعینات ہوتا ہے اور پوری زندگی کے چکر میں روزمرہ کے کاموں کے ساتھ برقرار رہتا ہے جن کو حل کرنے کی ضرورت ہوتی ہے۔ Kubernetes میں کلک ہاؤس کلسٹر۔
اور ہم نے ایک ایسا حل نکالنے کی کوشش کی جس سے کام کو آسان بنانے میں مدد ملے۔ یہ Altinity سے Kubernetes کے لیے ClickHouse-آپریٹر ہے۔
ایک آپریٹر ایک پروگرام ہے جس کا بنیادی کام دوسرے پروگراموں کو منظم کرنا ہے، یعنی یہ ایک مینیجر ہے۔
اور اس میں رویے کے نمونے ہیں۔ آپ اسے موضوع کے علاقے کے بارے میں کوڈفائیڈ علم کہہ سکتے ہیں۔
اور اس کا بنیادی کام DevOps کے لیے زندگی کو آسان بنانا اور مائیکرو مینیجمنٹ کو کم کرنا ہے تاکہ وہ (DevOps) پہلے سے ہی اعلیٰ سطح کی شرائط میں سوچے، یعنی، تاکہ وہ (DevOps) مائیکرو مینیج نہ کرے، تاکہ وہ دستی طور پر تمام انتظامات کو ترتیب نہ دے سکے۔ تفصیلات
اور صرف آپریٹر ایک روبوٹ اسسٹنٹ ہے جو مائیکرو ٹاسک کے ساتھ جدوجہد کرتا ہے اور DevOps کی مدد کرتا ہے۔
آپریٹر کی ضرورت کیوں ہے؟ وہ دو شعبوں میں بہترین ہے:
- جب کلک ہاؤس کے ماہر کے پاس کافی تجربہ نہیں ہوتا ہے، لیکن کلک ہاؤس کو چلانے کے لیے پہلے سے ہی ضروری ہوتا ہے، تو آپریٹر آپریشن میں سہولت فراہم کرتا ہے اور آپ کو ایک پیچیدہ ترتیب کے ساتھ کلک ہاؤس کلسٹر کو چلانے کی اجازت دیتا ہے، جب کہ اس کے اندر یہ سب کیسے کام کرتا ہے، اس بارے میں زیادہ تفصیل میں نہیں جانا چاہیے۔ . آپ اسے صرف اعلیٰ سطح کے کام دیتے ہیں، اور یہ کام کرتا ہے۔
- اور دوسرا کام جس میں یہ خود کو سب سے اچھی طرح سے ظاہر کرتا ہے وہ ہے جب بڑی تعداد میں عام کاموں کو خودکار کرنا ضروری ہوتا ہے۔ sysadmins سے مائیکرو ٹاسک کو ہٹاتا ہے۔
اس کی سب سے زیادہ ضرورت یا تو ان لوگوں کو ہے جو ابھی اپنا سفر شروع کر رہے ہیں، یا ان لوگوں کو جنہیں بہت زیادہ آٹومیشن کرنے کی ضرورت ہے۔
آپریٹر پر مبنی اپروچ اور دوسرے سسٹمز میں کیا فرق ہے؟ حلم بھی ہے۔ یہ کلک ہاؤس کو انسٹال کرنے میں بھی مدد کرتا ہے، آپ ہیلم چارٹ بنا سکتے ہیں، جو کہ کلک ہاؤس کا پورا کلسٹر بھی انسٹال کر دے گا۔ پھر آپریٹر اور اسی میں کیا فرق ہے، مثال کے طور پر، ہیلم؟
بنیادی بنیادی فرق یہ ہے کہ ہیلم پیکیج مینجمنٹ کے بارے میں ہے، اور آپریٹر ایک قدم آگے بڑھتا ہے۔ یہ پوری زندگی کے چکر کا سہارا ہے۔ یہ صرف تنصیب ہی نہیں ہے، یہ روزمرہ کے کام ہیں جن میں اسکیلنگ، شارڈنگ، یعنی ہر وہ کام جو لائف سائیکل کے دوران کرنے کی ضرورت ہے (اگر ضروری ہو تو ہٹانا بھی) - یہ سب آپریٹر کے ذریعے طے ہوتا ہے۔ یہ پورے سافٹ ویئر لائف سائیکل کو خودکار اور پیش کرنے کی کوشش کرتا ہے۔ یہ پیش کردہ دیگر حلوں سے اس کا بنیادی فرق ہے۔
یہ تھا تعارفی حصہ، چلتے ہیں۔
ہم اپنا آپریٹر کیسے بناتے ہیں؟ ہم کلک ہاؤس کلسٹر کو ایک وسیلہ کے طور پر منظم کرنے کے لیے اس مسئلے سے رجوع کرنے کی کوشش کر رہے ہیں۔
یہاں ہمارے پاس تصویر کے بائیں جانب ان پٹ ڈیٹا ہے۔ یہ ایک کلسٹر تصریح کے ساتھ YAML ہے، جو کلاسیکی طور پر kubectl سے Kubernetes تک جاتا ہے۔ وہاں، ہمارا آپریٹر اسے اٹھاتا ہے، اپنا جادو کرتا ہے۔ اور نتیجے کے طور پر، ہم ایسی سکیم حاصل کرتے ہیں. یہ Kubernetes میں ClickHouse کا نفاذ ہے۔
اور پھر ہم آہستہ آہستہ دیکھیں گے کہ آپریٹر کیسے کام کرتا ہے، کون سے عام کاموں کو حل کیا جا سکتا ہے۔ ہم صرف عام کاموں پر غور کریں گے، کیونکہ ہمارے پاس وقت محدود ہے۔ اور یہ ہر چیز کے بارے میں نہیں بتایا جائے گا جس کا آپریٹر فیصلہ کرسکتا ہے۔
آئیے پریکٹس سے شروع کرتے ہیں۔ ہمارا پروجیکٹ مکمل طور پر اوپن سورس ہے، لہذا آپ دیکھ سکتے ہیں کہ یہ GitHub پر کیسے کام کرتا ہے۔ اور آپ غور سے آگے بڑھ سکتے ہیں، اگر آپ صرف شروع کرنا چاہتے ہیں، تو آپ کوئیک اسٹارٹ گائیڈ کے ساتھ شروع کر سکتے ہیں۔
اگر آپ تفصیل سے سمجھنا چاہتے ہیں، تو ہم دستاویزات کو کم و بیش مہذب شکل میں برقرار رکھنے کی کوشش کرتے ہیں۔
آئیے ایک عملی مسئلہ سے شروع کرتے ہیں۔ پہلا کام جس کے ساتھ ہم سب شروع کرنا چاہتے ہیں وہ ہے پہلی مثال کو کسی نہ کسی طرح چلانا۔ آپریٹر کی مدد سے ClickHouse کو کیسے لانچ کیا جائے، یہ جانے بغیر کہ یہ کیسے کام کرتا ہے؟ ہم ایک منشور لکھ رہے ہیں، کیونکہ k8s کے ساتھ تمام مواصلات مینی فیسٹ کے ذریعے مواصلات ہیں۔
یہاں ایک ایسا پیچیدہ منشور ہے۔ ہم نے سرخ رنگ میں جس چیز پر روشنی ڈالی ہے وہ ہے جس پر ہمیں توجہ مرکوز کرنے کی ضرورت ہے۔ ہم آپریٹر سے ڈیمو کے نام سے ایک کلسٹر بنانے کو کہتے ہیں۔
ابھی کے لیے، یہ بنیادی مثالیں ہیں۔ اسٹوریج کو ابھی تک بیان نہیں کیا گیا ہے، لیکن ہم تھوڑی دیر بعد اسٹوریج پر واپس جائیں گے۔ ابھی کے لیے، ہم حرکیات میں کلسٹر کی ترقی کا مشاہدہ کریں گے۔
ہم نے یہ منشور بنایا ہے۔ ہم اسے اپنے آپریٹر کو کھلاتے ہیں۔ اس نے کام کیا، اس نے جادو کیا۔
ہم کنسول کو دیکھتے ہیں۔ تین اجزاء دلچسپی کے ہیں - یہ Pod، دو سروس-a، StatefulSet ہیں۔
آپریٹر نے کام کیا ہے، اور ہم دیکھ سکتے ہیں کہ اس نے بالکل کیا بنایا ہے۔
وہ کچھ اس طرح تخلیق کرتا ہے۔ ہمارے پاس ہر ایک نقل کے لیے ایک StatefulSet، Pod، ConfigMap، پورے کلسٹر کے لیے ConfigMap ہے۔ لازمی طور پر کلسٹر میں داخلے کے پوائنٹس کے طور پر خدمات۔
سروسز مرکزی لوڈ بیلنسر سروس ہیں اور یہ ہر نقل کے لیے، ہر شارڈ کے لیے ممکن ہے۔
یہاں ہمارا بیس کلسٹر کچھ اس طرح نظر آتا ہے۔ وہ ایک ہی نوڈ سے ہے۔
آئیے مزید آگے بڑھیں، ہم پیچیدہ کریں گے۔ آپ کو کلسٹر کو شارڈ کرنے کی ضرورت ہے۔
ہمارے کام بڑھ رہے ہیں، حرکیات شروع ہو رہی ہیں۔ ہم ایک شارڈ شامل کرنا چاہتے ہیں۔ ہم ترقی کی پیروی کرتے ہیں۔ ہم اپنی تفصیلات کو تبدیل کرتے ہیں۔ ہم اشارہ کرتے ہیں کہ ہم دو ٹکڑے چاہتے ہیں۔
یہ وہی فائل ہے جسے ہم نظام کی ترقی کے ساتھ متحرک طور پر تیار کرتے ہیں۔ کوئی سٹوریج نہیں ہے، سٹوریج پر مزید بات ہوگی، یہ الگ مسئلہ ہے۔
ہم YAML آپریٹر کو کھانا کھلاتے ہیں اور دیکھتے ہیں کہ کیا ہوتا ہے۔
آپریٹر نے سوچا اور درج ذیل ادارے بنائے۔ ہمارے پاس پہلے سے ہی دو پوڈز، تین سروسز اور، اچانک، 2 اسٹیٹفول سیٹس ہیں۔ 2 اسٹیٹفول سیٹ کیوں؟
یہ خاکہ پر اس طرح تھا - یہ ہماری ابتدائی حالت ہے، جب ہمارے پاس ایک پھلی تھی۔
یہ اس طرح بن گیا۔ اب تک، سب کچھ آسان ہے، اسے نقل کیا گیا ہے.
اور سٹیٹ فل سیٹ دو کیوں ہو گئے؟ یہاں ہمیں اس سوال پر بحث کرنے کی ضرورت ہے کہ کبرنیٹس میں پھلیوں کا انتظام کیسے کیا جاتا ہے۔
ایک ایسی چیز ہے جسے StatefulSet کہتے ہیں، جو آپ کو ٹیمپلیٹ سے Pods کا سیٹ بنانے کی اجازت دیتا ہے۔ یہاں کلیدی عنصر Template ہے۔ اور آپ ایک ٹیمپلیٹ کے مطابق ایک StatefulSet میں کئی Pods چلا سکتے ہیں۔ اور یہاں کلیدی جملہ ہے "ایک ٹیمپلیٹ کئی پوڈز"۔
اور پورے کلسٹر کو ایک اسٹیٹفل سیٹ میں پیک کرنے کا ایک بہت بڑا لالچ تھا۔ چلے گا، اس میں کوئی حرج نہیں۔ لیکن ایک انتباہ ہے۔ اگر ہم ایک متضاد کلسٹر کو جمع کرنا چاہتے ہیں، یعنی ClickHouse کے کئی ورژن سے، تو ہمارے سوالات شروع ہوتے ہیں۔ ہاں، StatefulSet ایک رولنگ اپ ڈیٹ کر سکتا ہے، لیکن وہاں آپ ایک نیا ورژن رول آؤٹ کر سکتے ہیں، وضاحت کریں کہ آپ کو ایک ہی وقت میں اتنے زیادہ نوڈس سے زیادہ کوشش کرنے کی ضرورت نہیں ہے۔
لیکن اگر ہم اس کام کو بڑھاتے ہوئے کہتے ہیں کہ ہم مکمل طور پر متضاد کلسٹر بنانا چاہتے ہیں اور رولنگ اپ ڈیٹ کا استعمال کرتے ہوئے پرانے ورژن سے نئے ورژن میں تبدیل نہیں ہونا چاہتے ہیں، بلکہ مختلف ورژن کے لحاظ سے صرف ایک متفاوت کلسٹر بنانا چاہتے ہیں۔ کلک ہاؤس اور مختلف اسٹوریج کے لحاظ سے۔ ہم چاہتے ہیں، مثال کے طور پر، الگ الگ ڈسکوں پر کچھ نقلیں بنانا، سست پر، عام طور پر، مکمل طور پر ایک متضاد کلسٹر بنانا۔ اور اس حقیقت کی وجہ سے کہ StatefulSet ایک ٹیمپلیٹ سے معیاری حل کرتا ہے، لہذا ایسا کرنے کا کوئی طریقہ نہیں ہے۔
کچھ سوچ بچار کے بعد فیصلہ ہوا کہ ہم ایسا ہی کرتے ہیں۔ ہمارے پاس ہر ایک کی نقل اس کے اپنے اسٹیٹفل سیٹ میں ہے۔ اس حل میں کچھ خرابیاں ہیں، لیکن عملی طور پر یہ سب آپریٹر کو مکمل طور پر سمیٹتا ہے۔ اور بہت سے فائدے ہیں۔ ہم مکمل طور پر ایسا کلسٹر بنا سکتے ہیں جیسا کہ ہم چاہتے ہیں، مثال کے طور پر، بالکل متضاد۔ لہذا، ایک کلسٹر میں جس میں ہمارے پاس ایک نقل کے ساتھ دو شارڈز ہوں گے، ہمارے پاس 2 اسٹیٹفول سیٹس اور 2 پوڈز ہوں گے کیونکہ ہم نے متضاد کلسٹر بنانے کی صلاحیت کی مندرجہ بالا وجوہات کی وجہ سے اس نقطہ نظر کا انتخاب کیا ہے۔
آئیے عملی کاموں کی طرف لوٹتے ہیں۔ ہمارے کلسٹر میں، ہمیں صارفین کو ترتیب دینے کی ضرورت ہے، یعنی آپ کو Kubernetes میں ClickHouse کی کچھ کنفیگریشن کرنے کی ضرورت ہے۔ آپریٹر اس کے لیے تمام امکانات فراہم کرتا ہے۔
ہم جو چاہتے ہیں وہ براہ راست YAML میں لکھ سکتے ہیں۔ تمام کنفیگریشن آپشنز کو اس YAML سے براہ راست کلک ہاؤس کنفیگرز میں میپ کیا جاتا ہے، جو پھر پورے کلسٹر میں تعینات ہوتے ہیں۔
آپ اس طرح بھی لکھ سکتے ہیں۔ یہ ایک مثال کے لیے ہے۔ پاس ورڈ کو انکرپٹ کیا جا سکتا ہے۔ بالکل کلک ہاؤس کنفیگریشن کے تمام آپشنز تعاون یافتہ ہیں۔ یہاں صرف ایک مثال ہے۔
کلسٹر کنفیگریشن کو ConfigMap کے بطور تقسیم کیا جاتا ہے۔ عملی طور پر، ConfigMap اپ ڈیٹ فوری طور پر نہیں ہوتا ہے، لہذا اگر ایک بڑا کلسٹر ہے، تو ترتیب کو آگے بڑھانے کے عمل میں کچھ وقت لگتا ہے۔ لیکن یہ سب استعمال کرنے میں بہت آسان ہے۔
ہم کام کو پیچیدہ بناتے ہیں۔ کلسٹر ترقی کر رہا ہے۔ ہم ڈیٹا کو نقل کرنا چاہتے ہیں۔ یعنی، ہمارے پاس پہلے سے ہی دو شارڈز ہیں، ہر ایک کی ایک نقل، صارفین کو ترتیب دیا گیا ہے۔ ہم بڑھ رہے ہیں اور نقل کرنا چاہتے ہیں۔
ہمیں نقل کی کیا ضرورت ہے؟
ہمیں زو کیپر کی ضرورت ہے۔ کلک ہاؤس میں، زو کیپر کا استعمال کرتے ہوئے نقل تیار کی جاتی ہے۔ زو کیپر کی ضرورت ہے تاکہ کلک ہاؤس کی مختلف نقلیں اس بات پر متفق ہوں کہ کون سے ڈیٹا بلاکس کلک ہاؤس پر ہیں۔
زو کیپر کوئی بھی استعمال کر سکتا ہے۔ اگر کسی انٹرپرائز کے پاس بیرونی زو کیپر ہے، تو اسے استعمال کیا جا سکتا ہے۔ اگر نہیں، تو آپ ہمارے ذخیرے سے انسٹال کر سکتے ہیں۔ ایک انسٹالر ہے جو اس ساری چیز کو آسان بنا دیتا ہے۔
اور پورے نظام کے تعامل کی اسکیم اس طرح نکلتی ہے۔ ہمارے پاس ایک پلیٹ فارم کے طور پر Kubernetes ہے۔ یہ کلک ہاؤس کے بیان کو انجام دیتا ہے۔ ZooKeeper میں نے یہاں تصویر بنائی۔ اور آپریٹر ClickHouse اور ZooKeeper دونوں کے ساتھ بات چیت کرتا ہے۔ یعنی ایک تعامل حاصل ہوتا ہے۔
اور یہ سب کلک ہاؤس کے لیے ڈیٹا کو کامیابی کے ساتھ k8s میں نقل کرنے کے لیے ضروری ہے۔
آئیے اب خود کام کو دیکھتے ہیں، نقل کے لیے مینی فیسٹ کیسا نظر آئے گا۔
ہم اپنے مینی فیسٹ میں دو حصے شامل کرتے ہیں۔ پہلا یہ ہے کہ ZooKeeper کہاں سے حاصل کیا جائے، جو یا تو Kubernetes کے اندر ہو سکتا ہے یا بیرونی۔ یہ صرف ایک تفصیل ہے۔ اور ہم نقلیں آرڈر کرتے ہیں۔ وہ. ہم دو نقلیں چاہتے ہیں۔ مجموعی طور پر، ہمارے پاس آؤٹ پٹ پر 4 پوڈ ہونے چاہئیں۔ ہمیں اسٹوریج کے بارے میں یاد ہے، یہ تھوڑا آگے واپس آ جائے گا. ذخیرہ ایک الگ گانا ہے۔
یہ اس طرح تھا۔
یہ اس طرح بن جاتا ہے۔ نقلیں شامل کی جاتی ہیں۔ 4 فٹ نہیں ہوا، ہمیں یقین ہے کہ ان میں سے بہت سے ہو سکتے ہیں۔ اور ZooKeeper کو سائیڈ پر شامل کیا گیا ہے۔ پیٹرن زیادہ پیچیدہ ہو رہے ہیں.
اور اگلا کام شامل کرنے کا وقت آگیا ہے۔ ہم مستقل ذخیرہ شامل کریں گے۔
مستقل اسٹوریج کے لیے، ہمارے پاس مختلف قسم کے اختیارات ہیں۔
اگر ہم کلاؤڈ فراہم کرنے والے میں چل رہے ہیں، مثال کے طور پر، ایمیزون، گوگل کا استعمال کرتے ہوئے، تو کلاؤڈ اسٹوریج استعمال کرنے کا ایک بہت بڑا فتنہ ہے۔ یہ بہت آسان ہے، یہ اچھا ہے۔
اور دوسرا آپشن ہے۔ یہ مقامی اسٹوریج کے لیے ہے، جب ہمارے پاس ہر نوڈ پر مقامی ڈسکیں ہوتی ہیں۔ اس اختیار کو لاگو کرنا بہت مشکل ہے، لیکن ایک ہی وقت میں یہ زیادہ نتیجہ خیز ہے۔
آئیے دیکھتے ہیں کہ کلاؤڈ اسٹوریج کے حوالے سے ہمارے پاس کیا ہے۔
خوبیاں ہیں۔ اسے ترتیب دینا بہت آسان ہے۔ ہم صرف کلاؤڈ فراہم کرنے والے سے حکم دیتے ہیں کہ براہ کرم ہمیں فلاں فلاں صلاحیت، فلاں فلاں کلاس کا ذخیرہ فراہم کریں۔ کلاسز کو فراہم کنندگان کے ذریعہ آزادانہ طور پر پینٹ کیا جاتا ہے۔
اور ایک نقص ہے۔ کچھ لوگوں کے لیے، یہ ایک غیر اہم کمی ہے۔ بلاشبہ، کارکردگی کے کچھ اوورلیز ہوں گے۔ یہ استعمال کرنے میں بہت آسان، قابل اعتماد ہے، لیکن کارکردگی میں کچھ ممکنہ کمی ہے۔
اور تب سے کلک ہاؤس کارکردگی پر توجہ مرکوز کرتا ہے، آپ یہاں تک کہہ سکتے ہیں کہ یہ ہر ممکن چیز کو نچوڑ دیتا ہے، اس لیے بہت سے کلائنٹس زیادہ سے زیادہ کارکردگی کو نچوڑنے کی کوشش کرتے ہیں۔
اور اس سے زیادہ سے زیادہ فائدہ اٹھانے کے لیے، ہمیں مقامی اسٹوریج کی ضرورت ہے۔
Kubernetes Kubernetes میں مقامی اسٹوریج کو استعمال کرنے کے لیے تین تجرید فراہم کرتا ہے۔ یہ:
- خالی ڈائر
- ہوسٹ پاتھ۔
- مقامی
غور کریں کہ وہ کس طرح مختلف ہیں، وہ کیسے ایک جیسے ہیں۔
سب سے پہلے، تینوں طریقوں میں، ہمارے پاس اسٹوریج ہے - یہ مقامی ڈسکیں ہیں جو ایک ہی فزیکل k8s نوڈ پر واقع ہیں۔ لیکن ان میں کچھ اختلافات ہیں۔
آئیے سب سے آسان سے شروع کرتے ہیں، یعنی emptyDir۔ عملی طور پر یہ کیا ہے؟ یہ ہم ہی ہیں جو ہماری تفصیلات سے کنٹینرائزیشن سسٹم (اکثر ڈوکر) سے کہتے ہیں کہ وہ ہمیں مقامی ڈسک کے فولڈر تک رسائی فراہم کرے۔
عملی طور پر، ڈاکر اپنے راستوں میں کہیں ایک عارضی فولڈر بناتا ہے، اسے لمبی ہیش کہتے ہیں۔ اور اس تک رسائی کے لیے ایک انٹرفیس فراہم کرتا ہے۔
کارکردگی کے لحاظ سے یہ کیسا رہے گا؟ یہ لوکل ڈسک کی رفتار سے چلے گا، یعنی یہ آپ کے پیچ تک مکمل رسائی ہے۔
لیکن اس معاملے میں اس کی کمی ہے۔ اس معاملے میں مستقل رہنا کافی مشکوک ہے۔ کنٹینرز کے ساتھ ڈوکر کی پہلی حرکت پر، پرسسٹنٹ کھو جاتا ہے۔ اگر Kubernetes کسی وجہ سے اس Pod کو دوسری ڈسک میں منتقل کرنا چاہتا ہے، تو ڈیٹا ضائع ہو جائے گا۔
یہ طریقہ ٹیسٹوں کے لیے اچھا ہے، کیونکہ یہ پہلے سے ہی نارمل رفتار دکھاتا ہے، لیکن یہ آپشن کسی سنجیدہ چیز کے لیے موزوں نہیں ہے۔
لہذا، دوسرا نقطہ نظر ہے. یہ ہوسٹ پاتھ ہے۔ اگر آپ پچھلی سلائیڈ اور اس سلائیڈ کو دیکھیں تو آپ کو صرف ایک فرق نظر آئے گا۔ ہمارے فولڈر نے ڈوکر کو براہ راست Kubernetes نوڈ پر چھوڑ دیا۔ یہ یہاں تھوڑا تیز ہے۔ ہم براہ راست مقامی فائل سسٹم پر راستہ لکھتے ہیں جہاں ہم اپنا ڈیٹا محفوظ کرنا چاہتے ہیں۔
اس طریقہ کے فوائد ہیں۔ یہ پہلے سے ہی ایک حقیقی مستقل، اور ایک کلاسک ہے۔ ہماری ڈسک پر، ڈیٹا کسی پتے پر لکھا جائے گا۔
اس کے نقصانات بھی ہیں۔ یہ انتظامیہ کی پیچیدگی ہے۔ ہمارے کبرنیٹس پوڈ کو کسی اور فزیکل نوڈ میں منتقل کرنا چاہتے ہیں۔ یہ وہ جگہ ہے جہاں DevOps کھیل میں آتا ہے۔ اسے پورے سسٹم کو صحیح طور پر سمجھانا چاہیے کہ آپ ان پوڈز کو صرف ایسے نوڈس میں منتقل کر سکتے ہیں جن پر آپ نے ان راستوں پر کوئی چیز نصب کی ہوئی ہے، اور ایک وقت میں ایک سے زیادہ نوڈ نہیں ہیں۔ یہ کافی مشکل ہے۔
خاص طور پر ان مقاصد کے لیے، ہم نے اس تمام پیچیدگی کو چھپانے کے لیے اپنے آپریٹر میں ٹیمپلیٹس بنائے ہیں۔ اور آپ صرف یہ کہہ سکتے ہیں: "میں کلک ہاؤس فی فزیکل نوڈ کی ایک مثال اور فلاں اور فلاں راستے پر رکھنا چاہتا ہوں۔"
لیکن یہ ضرورت صرف ہمارے لیے نہیں ہے، اس لیے خود کوبرنیٹس کے حضرات بھی سمجھتے ہیں کہ لوگ فزیکل ڈسک تک رسائی حاصل کرنا چاہتے ہیں، اس لیے وہ تیسرے درجے کی سہولت فراہم کرتے ہیں۔
اسے مقامی کہتے ہیں۔ پچھلی سلائیڈ سے عملی طور پر کوئی فرق نہیں ہے۔ صرف اس سے پہلے یہ ہاتھ سے کرنا ضروری تھا کہ ہم ان پوڈز کو نوڈ سے نوڈ میں منتقل نہیں کر سکتے، کیونکہ انہیں مقامی فزیکل ڈسک کے ساتھ فلاں فلاں راستے کے ساتھ منسلک ہونا ضروری ہے، اور اب یہ سارا علم خود کوبرنیٹس میں سمیٹ دیا گیا ہے۔ اور کنفیگر کرنا بہت آسان ہے۔
آئیے اپنے عملی کام کی طرف لوٹتے ہیں۔ آئیے YAML ٹیمپلیٹ پر واپس آتے ہیں۔ یہاں ہمارے پاس ایک حقیقی ذخیرہ ہے۔ ہم اس پر واپس آ گئے ہیں۔ ہم نے کلاسک VolumeClaim ٹیمپلیٹ کو k8s کی طرح سیٹ کیا ہے۔ اور ہم بیان کرتے ہیں کہ ہم کس قسم کا ذخیرہ چاہتے ہیں۔
اس کے بعد، k8s اسٹوریج کی درخواست کرے گا۔ اسے اسٹیٹفول سیٹ میں ہمارے لیے مختص کریں۔ اور آخر میں، یہ ClickHouse کے اختیار میں نکلے گا۔
ہمارے پاس ایسی سکیم تھی۔ ہمارا پرسسٹنٹ سٹوریج سرخ تھا، جو ایسا لگتا تھا کہ اسے کیا جانا چاہیے۔
اور یہ سبز ہو جاتا ہے۔ اب کلک ہاؤس آن k8s کلسٹر اسکیم کو مکمل طور پر حتمی شکل دی گئی ہے۔ ہمارے پاس شارڈز، replicas، ZooKeeper ہیں، ہمارے پاس حقیقی Persistent ہے، جو کسی نہ کسی طریقے سے لاگو ہوتا ہے۔ اسکیم پہلے ہی مکمل طور پر کام کر چکی ہے۔
ہم زندہ رہتے ہیں۔ ہمارا کلسٹر بڑھ رہا ہے۔ اور الیکسی کلک ہاؤس کے ایک نئے ورژن کو جاری کرنے کی کوشش کر رہی ہے۔
ایک عملی کام پیدا ہوتا ہے - ہمارے کلسٹر پر ClickHouse کے نئے ورژن کی جانچ کرنا۔ اور، یقیناً، میں یہ سب رول آؤٹ نہیں کرنا چاہتا، میں دور کونے میں کہیں ایک نقل میں ایک نیا ورژن رکھنا چاہتا ہوں، یا شاید ایک نیا ورژن نہیں، بلکہ ایک ساتھ دو، کیونکہ وہ اکثر سامنے آتے ہیں۔
ہم اس بارے میں کیا کہہ سکتے ہیں؟
یہاں ہمارے پاس ایسا ہی ایک موقع ہے۔ یہ پوڈ ٹیمپلیٹس ہیں۔ آپ پینٹ کر سکتے ہیں، ہمارا آپریٹر مکمل طور پر آپ کو ایک متضاد کلسٹر بنانے کی اجازت دیتا ہے۔ وہ. ترتیب دیں، ایک گروپ میں تمام نقلوں سے شروع ہو کر، ہر ذاتی نقل کے ساتھ ختم ہو، ہمیں کون سا ورژن کلک ہاؤس چاہیے، کون سا ورژن ہمیں اسٹوریج چاہیے۔ ہم کلسٹر کو مکمل طور پر اس طرح کی ترتیب میں ترتیب دے سکتے ہیں جیسا کہ ہمیں ضرورت ہے۔
آئیے تھوڑا اندر گہرائی میں جائیں۔ اس سے پہلے، ہم نے اس بارے میں بات کی تھی کہ ClickHouse-آپریٹر ClickHouse کی تفصیلات کے سلسلے میں کیسے کام کرتا ہے۔
اب میں اس بارے میں کچھ الفاظ کہنا چاہوں گا کہ کوئی بھی آپریٹر عام طور پر کیسے کام کرتا ہے، اور ساتھ ہی یہ K8s کے ساتھ کیسے تعامل کرتا ہے۔
شروع کرنے کے لیے K8s کے ساتھ تعامل پر غور کریں۔ جب ہم kubectl اپلائی کرتے ہیں تو کیا ہوتا ہے؟ API کے ذریعے، ہماری اشیاء etcd میں ظاہر ہوتی ہیں۔
مثال کے طور پر، بنیادی Kubernetes اشیاء: pod، StatefulSet، سروس، اور اسی طرح فہرست کے ذریعے۔
تاہم، ابھی تک جسمانی طور پر کچھ نہیں ہو رہا ہے۔ ان اشیاء کو کلسٹر میں مادّی بنایا جانا چاہیے۔
یہ وہ جگہ ہے جہاں کنٹرولر آتا ہے۔ کنٹرولر ایک خاص k8s جزو ہے جو ان وضاحتوں کو عملی شکل دے سکتا ہے۔ وہ جانتا ہے کہ جسمانی طور پر کیسے اور کیا کرنا ہے۔ وہ جانتا ہے کہ کنٹینرز کو کیسے چلانا ہے، سرور کے کام کرنے کے لیے وہاں کن کنفیگر ہونے کی ضرورت ہے۔
اور یہ K8s میں ہماری اشیاء کو عملی شکل دیتا ہے۔
لیکن ہم نہ صرف پوڈز، اسٹیٹفول سیٹس کے ساتھ کام کرنا چاہتے ہیں، ہم کلک ہاؤس انسٹالیشن بنانا چاہتے ہیں، یعنی کلک ہاؤس کی قسم کی ایک چیز، تاکہ اس کے ساتھ مجموعی طور پر کام کیا جا سکے۔ ابھی تک ایسا کوئی امکان نہیں ہے۔
لیکن K8s کی ایک اور اچھی چیز ہے۔ ہم چاہتے ہیں کہ ہمارے پاس کہیں ایسی پیچیدہ ہستی ہو، جس میں ہمارے کلسٹر کو پوڈز اور سٹیٹ فل سیٹ سے اسمبل کیا جائے۔
اور اس کے لیے کیا کرنا چاہیے؟ سب سے پہلے، حسب ضرورت وسائل کی تعریف منظر میں داخل ہوتی ہے۔ یہ کیا ہے؟ یہ K8s کے لیے ایک تفصیل ہے کہ آپ کے پاس ایک اور ڈیٹا کی قسم ہوگی جسے ہم پوڈ میں شامل کرنا چاہتے ہیں، StatefulSet، ایک حسب ضرورت وسیلہ جو اندر سے پیچیدہ ہوگا۔ یہ ڈیٹا سٹرکچر کی تفصیل ہے۔
ہم اسے وہاں kubectl apply کے ذریعے بھی بھیجتے ہیں۔ کوبرنیٹس نے خوشی سے اسے لے لیا۔
اور اب ہمارے سٹوریج میں، etcd میں آبجیکٹ کو ClickHouseInstallation نامی ایک حسب ضرورت وسیلہ لکھنے کا موقع ملتا ہے۔
لیکن فی الحال، اور کچھ نہیں ہوگا۔ یعنی، اگر اب ہم ایک YAML فائل بناتے ہیں جس پر ہم نے شارڈ، نقل کی تفصیل کے ساتھ غور کیا ہے اور کہا ہے کہ "kubectl apply"، تو Kubernetes اسے قبول کرے گا، اسے etcd میں ڈالے گا اور کہے گا: "بہت اچھا، لیکن مجھے نہیں معلوم۔ اس کے ساتھ کیا کرنا ہے. میں نہیں جانتا کہ ClickHouseInstallation کو کیسے برقرار رکھنا ہے۔"
اس کے مطابق، ہمیں کسی ایسے شخص کی ضرورت ہے جو Kubernetes کو ڈیٹا کی نئی قسم فراہم کرنے میں مدد کرے۔ بائیں طرف، ہمارے پاس اسٹاک Kubernetes کنٹرولر ہے جو اسٹاک ڈیٹا کی اقسام کے ساتھ کام کرتا ہے۔ اور دائیں طرف، ہمارے پاس ایک حسب ضرورت کنٹرولر ہونا چاہیے جو حسب ضرورت ڈیٹا کی اقسام کے ساتھ کام کر سکے۔
اور دوسرے طریقے سے اسے آپریٹر کہا جاتا ہے۔ میں نے اسے خاص طور پر یہاں کبرنیٹس کے لیے نکالا ہے، کیونکہ اسے K8s کے باہر بھی عمل میں لایا جا سکتا ہے۔ اکثر، بلاشبہ، تمام بیانات کوبرنیٹس میں پھانسی دی جاتی ہیں، لیکن اسے باہر کھڑے ہونے سے کوئی چیز نہیں روکتی، اس لیے یہاں اسے خاص طور پر لایا جاتا ہے۔
اور پہلے سے ہی، بدلے میں، کسٹم کنٹرولر، جسے آپریٹر بھی کہا جاتا ہے، API کے ذریعے Kubernetes کے ساتھ بات چیت کرتا ہے۔ وہ پہلے ہی جانتا ہے کہ API کے ساتھ کیسے تعامل کرنا ہے۔ اور وہ پہلے ہی جانتا ہے کہ ایک پیچیدہ اسکیم کو کیسے عملی جامہ پہنایا جائے جسے ہم اپنی مرضی کے وسائل سے بنانا چاہتے ہیں۔ یہ بالکل وہی ہے جو آپریٹر کرتا ہے۔
آپریٹر کیسے کام کرتا ہے؟ آئیے دائیں طرف پر ایک نظر ڈالیں کہ وہ یہ کیسے کرتا ہے۔ ہم یہ معلوم کریں گے کہ آپریٹر اس سب کو کیسے عملی شکل دیتا ہے اور K8s کے ساتھ مزید تعامل کیسے ہوتا ہے۔
آپریٹر پروگرام ہے۔ وہ واقعہ پر مبنی ہے۔ آپریٹر Kubernetes API کا استعمال کرتے ہوئے ایونٹس کو سبسکرائب کرتا ہے۔ Kubernetes API میں انٹری پوائنٹس ہیں جہاں آپ ایونٹس کو سبسکرائب کر سکتے ہیں۔ اور اگر K8s میں کچھ بدل جاتا ہے، تو Kubernetes ہر ایک کو واقعات بھیجتا ہے، یعنی جنہوں نے اس API پوائنٹ کو سبسکرائب کیا ہے انہیں اطلاعات موصول ہوں گی۔
آپریٹر واقعات کو سبسکرائب کرتا ہے، اور اسے کسی قسم کا رد عمل کرنا چاہیے۔ اس کا کام ابھرتے ہوئے واقعات کا جواب دینا ہے۔
واقعات کچھ اپ ڈیٹس کے ذریعہ تیار ہوتے ہیں۔ ہماری YAML فائل ClickHouseInstallation کی تفصیل کے ساتھ آتی ہے۔ وہ kubectl apply کے ذریعے etcd پر گیا۔ ایک تقریب نے وہاں کام کیا، نتیجے کے طور پر، یہ واقعہ ClickHouse-operator کے پاس آیا۔ آپریٹر کو یہ تفصیل موصول ہوئی۔ اور اسے کچھ کرنا ہے۔ اگر ClickHouseInstallation آبجیکٹ میں کوئی اپ ڈیٹ آیا ہے، تو آپ کو کلسٹر کو اپ ڈیٹ کرنے کی ضرورت ہے۔ اور آپریٹر کا کام کلسٹر کو اپ ڈیٹ کرنا ہے۔
وہ کیا کر رہا ہے؟ سب سے پہلے، ہمیں ایک ایکشن پلان بنانے کی ضرورت ہے کہ ہم اس اپ ڈیٹ کے ساتھ کیا کریں گے۔ اپ ڈیٹس بہت چھوٹے ہو سکتے ہیں، یعنی۔ YAML عملدرآمد میں چھوٹا ہے، لیکن کلسٹر میں بہت بڑی تبدیلیوں کا باعث بن سکتا ہے۔ لہذا، آپریٹر ایک منصوبہ بناتا ہے، اور پھر وہ اس پر عمل کرتا ہے۔
وہ اس منصوبے کے مطابق اس ڈھانچے کو اندر سے ابالنا شروع کرتا ہے تاکہ پھلی، خدمات، یعنی اس کا بنیادی کام کیا کرنا ہے۔ یہ Kubernetes میں ClickHouse کلسٹر بنانے جیسا ہے۔
اب آئیے ایسی ہی ایک دلچسپ چیز پر ہاتھ ڈالتے ہیں۔ یہ Kubernetes اور آپریٹر کے درمیان ذمہ داری کی تقسیم ہے، یعنی Kubernetes کیا کرتا ہے، آپریٹر کیا کرتا ہے، اور وہ ایک دوسرے کے ساتھ کیسے تعامل کرتے ہیں۔
Kubernetes نظام کی چیزوں کے لیے ذمہ دار ہے، یعنی اشیاء کے ایک بنیادی سیٹ کے لیے جس کی تشریح نظام کے دائرہ کار سے کی جا سکتی ہے۔ Kubernetes جانتا ہے کہ پوڈز کو کیسے شروع کرنا ہے، کنٹینرز کو دوبارہ کیسے شروع کرنا ہے، ماؤنٹ والیوم کیسے کرنا ہے، ConfigMap کے ساتھ کیسے کام کرنا ہے، یعنی کوئی بھی چیز جسے نظام کہا جا سکتا ہے۔
آپریٹرز موضوعی علاقوں میں کام کرتے ہیں۔ ہر آپریٹر کو اس کے موضوع کے لیے بنایا گیا ہے۔ ہم نے کلک ہاؤس کے لیے بنایا ہے۔
اور آپریٹر موضوع کے علاقے کے لحاظ سے قطعی طور پر بات چیت کرتا ہے، جیسے کہ ایک نقل شامل کرنا، اسکیم بنانا، نگرانی قائم کرنا۔ ایسی تقسیم ہے۔
آئیے ایک عملی مثال دیکھتے ہیں کہ جب ہم ایک ایڈ ریپلیکا ایکشن کرتے ہیں تو خدشات کی یہ علیحدگی کیسے ہوتی ہے۔
کام آپریٹر کے پاس آتا ہے - ایک نقل شامل کرنا۔ آپریٹر کیا کر رہا ہے؟ آپریٹر حساب لگائے گا کہ نیا اسٹیٹفول سیٹ بنانا ضروری ہے، جس میں فلاں فلاں ٹیمپلیٹس، والیوم کلیم کو بیان کرنا ضروری ہے۔
اس نے یہ سب تیار کیا اور اسے K8s پر منتقل کردیا۔ وہ کہتا ہے کہ اسے ConfigMap، StatefulSet، والیوم کی ضرورت ہے۔ Kubernetes کام کر رہا ہے. وہ بنیادی اکائیوں کو عملی شکل دیتا ہے جن کے ساتھ وہ کام کرتا ہے۔
اور پھر کلک ہاؤس آپریٹر دوبارہ کھیل میں آتا ہے۔ اس کے پاس پہلے سے ہی ایک جسمانی پوڈ ہے جس پر آپ پہلے ہی کچھ کر سکتے ہیں۔ اور ClickHouse-operator پھر موضوع کے لحاظ سے کام کرتا ہے۔ وہ. خاص طور پر، ClickHouse، ایک کلسٹر میں نقل شامل کرنے کے لیے، آپ کو، سب سے پہلے، اس کلسٹر میں موجود ڈیٹا اسکیم کو ترتیب دینا ہوگا۔ اور، دوسری بات، اس ریمارکس کو مانیٹرنگ میں شامل کیا جانا چاہیے تاکہ اس کا واضح طور پر پتہ لگایا جا سکے۔ آپریٹر پہلے سے ہی اسے ترتیب دیتا ہے۔
اور اس کے بعد ہی کلک ہاؤس خود کام میں آتا ہے، یعنی ایک اور اعلی سطحی ادارہ۔ یہ پہلے سے ہی ایک ڈیٹا بیس ہے۔ اس کی اپنی مثال ہے، اگلی ترتیب شدہ نقل، جو کلسٹر میں شامل ہونے کے لیے تیار ہے۔
اس سے پتہ چلتا ہے کہ عمل درآمد اور ذمہ داری کی علیحدگی کا سلسلہ جب ایک نقل شامل کرنا کافی طویل ہے۔
ہم اپنے عملی کاموں کو جاری رکھیں گے۔ اگر کلسٹر پہلے سے موجود ہے، تو آپ کنفیگریشن کو منتقل کر سکتے ہیں۔
ہم نے اسے اس لیے بنایا ہے کہ موجودہ ایکس ایم ایل میں گزرنا ممکن ہو، جسے کلک ہاؤس سمجھتا ہے۔
آپ کلک ہاؤس کو ٹھیک کر سکتے ہیں۔ صرف زونڈ تعیناتی وہی ہے جس کے بارے میں میں نے میزبان پاتھ، مقامی اسٹوریج کی وضاحت کرتے وقت بات کی۔ زونڈ تعیناتی کو صحیح طریقے سے کرنے کا طریقہ یہ ہے۔
اگلا عملی کام نگرانی کرنا ہے۔
اگر ہمارا کلسٹر تبدیل ہوتا ہے، تو ہمیں وقتاً فوقتاً نگرانی کو ترتیب دینے کی ضرورت ہوتی ہے۔
آئیے خاکہ پر ایک نظر ڈالتے ہیں۔ ہم یہاں پہلے ہی سبز تیروں پر غور کر چکے ہیں۔ اب آئیے سرخ تیروں کو دیکھتے ہیں۔ اس طرح ہم اپنے کلسٹر کی نگرانی کرنا چاہتے ہیں۔ کس طرح کلک ہاؤس کلسٹر سے میٹرکس پرومیتھیس میں اور پھر گرافانا میں داخل ہوتے ہیں۔
نگرانی میں کیا مسئلہ ہے؟ اسے کسی قسم کی کامیابی کے طور پر کیوں پیش کیا جاتا ہے؟ مشکل حرکیات میں ہے۔ جب ہمارے پاس ایک کلسٹر ہے اور یہ جامد ہے، تو آپ ایک بار مانیٹرنگ سیٹ کر سکتے ہیں اور مزید پریشان نہیں ہوں گے۔
لیکن اگر ہمارے پاس بہت سارے کلسٹر ہیں، یا کوئی چیز مسلسل بدل رہی ہے، تو یہ عمل متحرک ہے۔ اور مسلسل نگرانی کو دوبارہ ترتیب دینا وسائل اور وقت کا ضیاع ہے۔ یہاں تک کہ صرف سست. یہ خودکار ہونے کی ضرورت ہے۔ مشکل عمل کی حرکیات میں ہے۔ اور آپریٹر اسے بہت اچھی طرح سے خودکار کرتا ہے۔
ہمارا کلسٹر کیسے تیار ہوا؟ شروع شروع میں وہ ایسا تھا۔
پھر وہ اس طرح تھا۔
آخر میں وہ ایسا ہی ہو گیا۔
اور نگرانی خود کار طریقے سے آپریٹر کی طرف سے کیا جاتا ہے. داخلے کا واحد نقطہ۔
اور ہم صرف گرافانا ڈیش بورڈ میں باہر نکلنے کو دیکھتے ہیں کہ ہمارے کلسٹر کی زندگی کس طرح اندر ابلتی ہے۔
ویسے، گرافانا ڈیش بورڈ بھی ہمارے آپریٹر کے ساتھ سورس کوڈ میں ہی تقسیم کیا جاتا ہے۔ آپ جڑ سکتے ہیں اور استعمال کر سکتے ہیں۔ یہ اسکرین شاٹ مجھے ہمارے DevOps نے دیا تھا۔
ہم آگے کہاں جانا چاہیں گے؟ یہ:
- ٹیسٹ آٹومیشن تیار کریں۔ اہم کام نئے ورژن کی خودکار جانچ ہے۔
- ہم واقعی ZooKeeper کے ساتھ انضمام کو خودکار کرنا چاہتے ہیں۔ اور ZooKeeper-operator کے ساتھ ضم کرنے کا ارادہ رکھتا ہے۔ وہ. ZooKeeper کے لیے ایک آپریٹر لکھا گیا ہے، اور یہ منطقی ہے کہ دونوں آپریٹرز ایک زیادہ آسان حل بنانے کے لیے ضم ہونا شروع کر دیں۔
- ہم زندگی کی مزید پیچیدہ جانچیں کرنا چاہتے ہیں۔
- میں نے سبز رنگ میں روشنی ڈالی کہ ہمارے پاس راستے میں ٹیمپلیٹس کی وراثت ہے - DONE، یعنی آپریٹر کی اگلی ریلیز کے ساتھ، ہمارے پاس پہلے سے ہی ٹیمپلیٹ کی وراثت ہوگی۔ یہ ایک طاقتور ٹول ہے جو آپ کو ٹکڑوں سے پیچیدہ کنفیگریشنز بنانے کی اجازت دیتا ہے۔
- اور ہم پیچیدہ کاموں کو خودکار کرنا چاہتے ہیں۔ سب سے اہم ری-شارڈنگ ہے۔
آئیے کچھ انٹرمیڈیٹ نتائج کرتے ہیں۔
اس کے نتیجے میں ہمیں کیا ملتا ہے؟ اور کیا یہ اس کے قابل ہے یا نہیں؟ کیا مجھے ڈیٹا بیس کو Kubernetes میں گھسیٹنے کی کوشش کرنے کی بھی ضرورت ہے اور عام طور پر آپریٹر اور خاص طور پر Alitnity آپریٹر کو لاگو کرنے کی ضرورت ہے۔
آؤٹ پٹ پر ہمیں ملتا ہے:
- ڈرامائی طور پر ترتیب، تعیناتی، اور دیکھ بھال کو آسان اور خودکار بنائیں۔
- فوری طور پر بلٹ ان مانیٹرنگ۔
- اور پیچیدہ حالات کے لیے استعمال کے لیے تیار کوڈیفائیڈ ٹیمپلیٹس۔ پہلے سے ہی ایک نقل شامل کرنے کے لیے قسم کی کارروائی ہاتھ سے کرنے کی ضرورت نہیں ہے۔ یہ آپریٹر کی طرف سے کیا جاتا ہے.
صرف آخری سوال باقی ہے۔ ہمارے پاس پہلے سے ہی Kubernetes میں ایک ڈیٹا بیس ہے، ورچوئلائزیشن۔ اس طرح کے حل کی کارکردگی کے بارے میں کیا خیال ہے، خاص طور پر چونکہ کلک ہاؤس کارکردگی کے لیے موزوں ہے؟
جواب یہ ہے کہ سب کچھ ٹھیک ہے! میں تفصیل سے بیان نہیں کروں گا، یہ ایک الگ رپورٹ کا موضوع ہے۔
لیکن TSBS جیسا ایک پروجیکٹ ہے۔ اس کا بنیادی کام کیا ہے؟ یہ ڈیٹا بیس کی کارکردگی کا ٹیسٹ ہے۔ یہ گرم کا گرم سے، نرم کا نرم سے موازنہ کرنے کی کوشش ہے۔
وہ کیسے کام کرتا ہے؟ ڈیٹا کا ایک سیٹ تیار ہوتا ہے۔ پھر ایک ہی ٹیسٹ سیٹ پر یہ ڈیٹا سیٹ مختلف ڈیٹا بیس پر چلایا جاتا ہے۔ اور ہر ڈیٹا بیس ایک مسئلہ کو جس طرح حل کر سکتا ہے۔ اور پھر آپ نتائج کا موازنہ کر سکتے ہیں۔
یہ پہلے سے ہی ڈیٹا بیس کے ایک بڑے گروپ کی حمایت کرتا ہے۔ میں نے تین اہم کی نشاندہی کی ہے۔ یہ:
- timescaledb.
- انفلوکس ڈی بی۔
- کلک ہاؤس
ایک اور اسی طرح کے حل کے ساتھ موازنہ بھی کیا گیا تھا۔ RedShift کے ساتھ موازنہ۔ موازنہ ایمیزون پر کیا گیا تھا۔ کلک ہاؤس بھی اس معاملے میں سب سے آگے ہے۔
میں نے جو کہا ہے اس سے کیا نتیجہ اخذ کیا جا سکتا ہے؟
- Kubernetes میں DB ممکن ہے۔ شاید، آپ کچھ بھی کر سکتے ہیں، لیکن عام طور پر ایسا لگتا ہے کہ آپ کر سکتے ہیں۔ Kubernetes میں ClickHouse یقینی طور پر ہمارے آپریٹر کی مدد سے ممکن ہے۔
- آپریٹر عمل کو خودکار کرنے میں مدد کرتا ہے اور واقعی زندگی کو آسان بناتا ہے۔
- کارکردگی عام ہے۔
- اور، ہمیں ایسا لگتا ہے کہ اسے استعمال کیا جا سکتا ہے اور ہونا چاہیے۔
اوپن سورس - ہمارے ساتھ شامل ہوں!
جیسا کہ میں نے کہا، آپریٹر ایک مکمل طور پر اوپن سورس پروڈکٹ ہے، لہذا یہ بہت اچھا ہوگا اگر زیادہ سے زیادہ لوگ اسے استعمال کریں۔ ابھی شامل ہوں! ہم آپ سب کا انتظار کر رہے ہیں!
سب کا شکریہ!
آپ کے سوالات
رپورٹ کے لیے شکریہ! میرا نام انتون ہے۔ میں SEMrush سے ہوں۔ میں حیران ہوں کہ لاگنگ کا کیا حال ہے۔ ہم نگرانی کے بارے میں سنتے ہیں، لیکن لاگنگ کے بارے میں کچھ نہیں، اگر ہم پورے کلسٹر کے بارے میں بات کرتے ہیں۔ مثال کے طور پر، ہمارے پاس ہارڈ ویئر پر ایک کلسٹر ہے۔ اور ہم مرکزی لاگنگ کا استعمال کرتے ہیں، ہم اسے معیاری ذرائع سے ایک عام ہیپ میں جمع کرتے ہیں۔ اور پھر وہاں سے ہمیں ڈیٹا ملتا ہے جو ہمارے لیے دلچسپ ہوتا ہے۔
اچھا سوال، یعنی ٹوڈو لسٹ میں لاگ ان کرنا۔ ہمارا آپریٹر ابھی تک اسے خودکار نہیں کرتا ہے۔ یہ اب بھی ترقی کر رہا ہے، منصوبہ ابھی بھی کافی جوان ہے۔ ہم لاگنگ کی ضرورت کو سمجھتے ہیں۔ یہ بھی بہت اہم موضوع ہے۔ اور یہ شاید نگرانی سے کم اہم نہیں ہے۔ لیکن نفاذ کے لیے فہرست میں سب سے پہلے نگرانی تھی۔ لاگنگ ہوگی۔ قدرتی طور پر، ہم کلسٹر کی زندگی کے تمام پہلوؤں کو خودکار کرنے کی کوشش کر رہے ہیں۔ لہذا، جواب یہ ہے کہ اس وقت آپریٹر، بدقسمتی سے، یہ نہیں جانتا کہ یہ کیسے کرنا ہے، لیکن یہ منصوبوں میں ہے، ہم یہ کریں گے. اگر آپ شامل ہونا چاہتے ہیں، تو پلیز ریکوسٹ، پلیز۔
ہیلو! رپورٹ کے لیے شکریہ! میرے پاس مستقل حجم سے متعلق ایک معیاری سوال ہے۔ جب ہم اس آپریٹر کے ساتھ ایک کنفیگریشن بناتے ہیں تو آپریٹر یہ کیسے طے کرتا ہے کہ ہمارے پاس کچھ ڈسک یا فولڈر کس نوڈ پر ہے؟ ہمیں پہلے اسے سمجھانا چاہیے کہ، براہ کرم، ہمارے کلک ہاؤس کو بالکل ان نوڈس پر رکھیں جن میں ڈسک ہے؟
جہاں تک میں سمجھتا ہوں، یہ سوال مقامی اسٹوریج کا تسلسل ہے، خاص طور پر اس کا ہوسٹ پاتھ حصہ۔ یہ پورے سسٹم کو سمجھانے کے مترادف ہے کہ پوڈ کے لیے فلاں فلاں نوڈ پر بالکل لانچ ہونا ضروری ہے، جس پر ہمارے پاس فزیکل کنیکٹڈ ڈسک ہے، جو فلاں فلاں راستے پر لگی ہوئی ہے۔ یہ ایک پورا حصہ ہے جسے میں نے بہت سطحی طور پر چھوا ہے، کیونکہ وہاں کا جواب کافی بڑا ہے۔
مختصراً، ایسا لگتا ہے۔ یقینا، ہمیں ان جلدوں کی فراہمی کی ضرورت ہے۔ اس وقت، مقامی اسٹوریج میں کوئی متحرک پروویژن نہیں ہے، لہذا DevOps کو خود ہی ڈسک کاٹنا چاہیے، یہ والیوم یہ ہیں۔ اور انہیں Kubernetes پروویژننگ کی وضاحت کرنی چاہیے، کہ آپ کے پاس فلاں اور فلاں کلاس کی مستقل جلدیں ہوں گی، جو فلاں اور فلاں نوڈس پر واقع ہے۔ پھر یہ Kubernetes کو سمجھانا ضروری ہو گا کہ ایسے پوڈز جن کے لیے فلاں اور فلاں مقامی سٹوریج کلاس کی ضرورت ہوتی ہے انہیں صرف فلاں اور فلاں نوڈس کے لیبل کے مطابق شیڈول کرنے کی ضرورت ہے۔ ان مقاصد کے لیے، آپریٹر کے پاس کسی قسم کا لیبل تفویض کرنے کی صلاحیت ہے اور ہر میزبان مثال کے لیے ایک۔ اور یہ پتہ چلتا ہے کہ کوبرنیٹس کے ذریعہ پوڈز کو صرف نوڈس پر چلانے کے لئے روٹ کیا جائے گا جو آسان الفاظ میں ضروریات، لیبلز کو پورا کرتے ہیں۔ منتظمین لیبل تفویض کرتے ہیں، ہاتھ سے ڈسکوں کی فراہمی کرتے ہیں۔ اور پھر ترازو۔
اور صرف تیسرا آپشن مقامی اسے تھوڑا آسان بنانے میں مدد کرتا ہے۔ جیسا کہ میں نے پہلے ہی زور دیا ہے، یہ ٹیوننگ کا ایک محنتی کام ہے، جو بالآخر زیادہ سے زیادہ کارکردگی حاصل کرنے میں مدد کرتا ہے۔
میرا اس سے متعلق دوسرا سوال ہے۔ Kubernetes کا تصور اس طرح سے کیا گیا تھا کہ اس سے ہمیں کوئی فرق نہیں پڑتا کہ آیا ہم نوڈ کھو دیتے ہیں یا نہیں۔ اس صورت میں ہمیں کیا کرنا چاہیے اگر ہم نے نوڈ کھو دیا ہے جہاں ہمارے پاس شارڈ ہے؟
جی ہاں، Kubernetes اصل میں پوزیشن میں تھا کہ ہماری پھلیوں کے ساتھ ہمارا تعلق مویشیوں کی طرح ہے، لیکن یہاں ہر ڈسک پالتو جانور کی طرح کچھ بن جاتا ہے. ایک ایسا مسئلہ ہے کہ ہم انہیں صرف دور نہیں کر سکتے۔ اور Kubernetes کی ترقی اس سمت میں جا رہی ہے کہ فلسفیانہ طور پر اسے مکمل طور پر ضائع شدہ وسائل کے طور پر پیش کرنا ناممکن ہے۔
اب ایک عملی سوال۔ اگر آپ اس نوڈ کو کھو دیں جس پر ڈسک تھی تو کیا کریں؟ یہاں مسئلہ اعلیٰ سطح پر حل ہوتا ہے۔ ClickHouse کے معاملے میں، ہمارے پاس ایسی نقلیں ہیں جو اعلیٰ سطح پر کام کرتی ہیں، یعنی کلک ہاؤس کی سطح پر۔
مزاج کیا ہے؟ DevOps اس بات کو یقینی بنانے کے لیے ذمہ دار ہے کہ ڈیٹا ضائع نہ ہو۔ اسے نقل کو صحیح طریقے سے ترتیب دینا چاہیے اور اس بات کو یقینی بنانا چاہیے کہ نقل چل رہی ہے۔ ClickHouse کی سطح پر نقل میں، ڈیٹا کو ڈپلیکیٹ کیا جانا چاہیے۔ یہ وہ کام نہیں ہے جسے آپریٹر حل کرتا ہے۔ اور وہ کام نہیں جسے Kubernetes خود حل کرتا ہے۔ یہ کلک ہاؤس کی سطح پر ہے۔
اگر آپ کا لوہے کا نوڈ گر گیا ہے تو کیا کریں؟ اور یہ پتہ چلتا ہے کہ دوسرا ڈالنا ضروری ہوگا، اس پر ڈسک کو صحیح طریقے سے منتقل کریں، لیبل لگائیں. اور اس کے بعد، یہ ان ضروریات کو پورا کرے گا جو اس پر موجود Kubernetes ایک پوڈ مثال چلا سکتا ہے۔ Kubernetes اسے شروع کرے گا. آپ کی پھلیوں کی تعداد متعین کردہ کے لیے کافی نہیں ہے۔ یہ اس چکر سے گزرے گا جو میں نے دکھایا تھا۔ اور اعلیٰ ترین سطح پر، ClickHouse سمجھے گا کہ ہمارے پاس ایک نقل داخل کی گئی ہے، یہ اب بھی خالی ہے اور ہمیں اس میں ڈیٹا کی منتقلی شروع کرنے کی ضرورت ہے۔ وہ. یہ عمل اب بھی غیر تسلی بخش خودکار ہے۔
رپورٹ کے لیے شکریہ! جب تمام قسم کی گندی چیزیں ہوتی ہیں، آپریٹر کریش ہو جاتا ہے اور دوبارہ شروع ہوتا ہے، اور اس وقت واقعات آتے ہیں، کیا آپ کسی طرح اس پر کارروائی کرتے ہیں؟
کیا ہوتا ہے اگر آپریٹر کریش ہو جائے اور دوبارہ شروع ہو جائے، ہاں؟
جی ہاں. اور اسی لمحے واقعات سامنے آئے۔
اس معاملے میں کیا کرنا ہے اس کا کام جزوی طور پر آپریٹر اور Kubernetes کے درمیان تقسیم ہے۔ Kubernetes میں واقع ہونے والے واقعے کو دوبارہ چلانے کی صلاحیت ہے۔ وہ ری پلے کرتا ہے۔ اور آپریٹر کا کام اس بات کو یقینی بنانا ہے کہ جب ایونٹ لاگ کو اس پر دوبارہ چلایا گیا تھا، تو یہ واقعات غیرمعمولی ہیں۔ اور تاکہ ایک ہی واقعہ کا دوبارہ وقوع پذیر ہونا ہمارے لیے ہمارے نظام کو توڑ نہ دے۔ اور ہمارا آپریٹر اس کام کا مقابلہ کرتا ہے۔
ہیلو! رپورٹ کے لیے شکریہ! دمتری زاویلوف، کمپنی سمیدوف۔ کیا آپریٹر میں ہاپروکسی کے ساتھ حسب ضرورت کے اختیارات شامل کرنے کا منصوبہ ہے؟ معیاری کے علاوہ کچھ اور بیلنس دلچسپ ہے، تاکہ یہ ہوشیار ہو اور سمجھے کہ ClickHouse وہاں حقیقی ہے۔
کیا آپ Ingress کے بارے میں بات کر رہے ہیں؟
ہاں، Ingress کو haproxy سے تبدیل کریں۔ ہاپروکسی میں، آپ کلسٹر ٹوپولوجی کی وضاحت کر سکتے ہیں جہاں اس کی نقلیں ہیں۔
ابھی تک، ہم نے اس کے بارے میں نہیں سوچا ہے۔ اگر آپ کو اس کی ضرورت ہے اور یہ بتا سکتے ہیں کہ اس کی ضرورت کیوں ہے، تو اس پر عمل درآمد ممکن ہوگا، خاص طور پر اگر آپ حصہ لینا چاہتے ہیں۔ ہمیں آپشن پر غور کرنے میں خوشی ہوگی۔ مختصر جواب نہیں ہے، فی الحال ہمارے پاس ایسی فعالیت نہیں ہے۔ ٹپ کے لیے شکریہ، ہم اس پر ایک نظر ڈالیں گے۔ اور اگر آپ استعمال کے معاملے کی بھی وضاحت کریں اور عملی طور پر یہ کیوں ضروری ہے، مثال کے طور پر، GitHub پر ایشوز بنائیں، تو یہ بہت اچھا ہوگا۔
پہلے ہی.
ٹھیک. ہم کسی بھی تجاویز کے لیے کھلے ہیں۔ اور ہاپروکسی کو ٹوڈو لسٹ میں ڈال دیا گیا ہے۔ ٹوڈو لسٹ بڑھ رہی ہے، ابھی سکڑ نہیں رہی ہے۔ لیکن یہ اچھا ہے، اس کا مطلب ہے کہ مصنوعات کی مانگ ہے۔
ماخذ: www.habr.com