کیا کبرنیٹس پر کافکا اچھا ہے؟

سلام، حبر!

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

تعارف

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

دوسری طرف، کافکا بنیادی طور پر تقسیم شدہ ڈیٹا بیس کے طور پر کام کرتا ہے۔ اس طرح، کام کرتے وقت، آپ کو ریاست سے نمٹنا پڑتا ہے، اور یہ مائیکرو سروس سے کہیں زیادہ بھاری ہوتا ہے۔ Kubernetes ریاستی بوجھ کی حمایت کرتا ہے، لیکن جیسا کہ Kelsey Hightower نے دو ٹویٹس میں اشارہ کیا ہے، انہیں احتیاط کے ساتھ سنبھالنا چاہیے:

کچھ لوگ محسوس کرتے ہیں کہ اگر آپ Kubernetes کو ایک ریاستی کام کے بوجھ میں ڈالتے ہیں، تو یہ ایک مکمل طور پر منظم ڈیٹا بیس بن جاتا ہے جو RDS کا مقابلہ کرتا ہے۔ یہ غلط ہے. ہو سکتا ہے، اگر آپ کافی محنت کرتے ہیں، اضافی اجزاء شامل کرتے ہیں اور SRE انجینئرز کی ٹیم کو راغب کرتے ہیں، تو آپ Kubernetes کے اوپر RDS بنانے کے قابل ہو جائیں گے۔

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

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

تکمیل کا وقت

آئیے بنیادی چیز کے بارے میں بات کرتے ہیں - خود رن ٹائم ماحول

عمل

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

یاد رکھیں

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

ڈیٹا اسٹور

کنٹینرز میں ڈیٹا کا ذخیرہ عارضی ہے - دوبارہ شروع ہونے پر ڈیٹا ضائع ہو جاتا ہے۔ کافکا ڈیٹا کے لیے آپ حجم استعمال کر سکتے ہیں۔ emptyDir، اور اثر ایک جیسا ہو گا: آپ کا بروکر ڈیٹا مکمل ہونے کے بعد ضائع ہو جائے گا۔ آپ کے پیغامات اب بھی دوسرے بروکرز پر نقل کے طور پر محفوظ کیے جا سکتے ہیں۔ لہذا، دوبارہ شروع کرنے کے بعد، ناکام بروکر کو پہلے تمام ڈیٹا کو نقل کرنا ہوگا، اور اس عمل میں کافی وقت لگ سکتا ہے۔

اس لیے آپ کو طویل مدتی ڈیٹا اسٹوریج کا استعمال کرنا چاہیے۔ اسے XFS فائل سسٹم کے ساتھ غیر مقامی طویل مدتی اسٹوریج ہونے دیں یا، زیادہ واضح طور پر، ext4۔ NFS استعمال نہ کریں۔ میں نے آپ کو خبردار کیا۔ NFS ورژن v3 یا v4 کام نہیں کریں گے۔ مختصراً، کافکا بروکر کریش ہو جائے گا اگر وہ NFS میں "بیوقوف نام بدلنے" کے مسئلے کی وجہ سے ڈیٹا ڈائرکٹری کو حذف نہیں کر سکتا۔ اگر میں نے آپ کو ابھی تک قائل نہیں کیا تو بہت احتیاط سے اس مضمون کو پڑھیں. ڈیٹا اسٹور غیر مقامی ہونا چاہیے تاکہ کوبرنیٹس دوبارہ شروع کرنے یا جگہ بدلنے کے بعد زیادہ لچکدار طریقے سے ایک نیا نوڈ منتخب کر سکے۔

Сеть

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

تشکیل

باقاعدہ منشور

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

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

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

ہیلم چارٹس

Helm ایک Kubernetes کے لیے ایک پیکیج مینیجر ہے جس کا موازنہ OS پیکیج مینیجرز جیسے yum، apt، Homebrew یا Chocolatey سے کیا جا سکتا ہے۔ یہ ہیلم چارٹس میں بیان کردہ پہلے سے طے شدہ سافٹ ویئر پیکجوں کو انسٹال کرنا آسان بناتا ہے۔ ایک اچھی طرح سے منتخب کردہ ہیلم چارٹ اس مشکل کام کو آسان بناتا ہے کہ کبرنیٹس پر کافکا کو استعمال کرنے کے لیے تمام پیرامیٹرز کو درست طریقے سے ترتیب دینے کا طریقہ آسان ہے۔ کافکا کے کئی خاکے ہیں: سرکاری ایک واقع ہے۔ انکیوبیٹر کی حالت میں، وہاں سے ایک ہے۔ میں confluent, ایک اور - سے بٹنی.

آپریٹرز

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

فہرست میں حیرت انگیز آپریٹرز کافکا کے لیے دو آپریٹرز کا ذکر کیا گیا ہے۔ ان میں سے ایک - سٹرمزی. Strimzi کے ساتھ، اپنے کافکا کلسٹر کو منٹوں میں تیار کرنا اور چلانا آسان ہے۔ عملی طور پر کسی ترتیب کی ضرورت نہیں ہے، اس کے علاوہ، آپریٹر خود کچھ اچھی خصوصیات فراہم کرتا ہے، مثال کے طور پر، کلسٹر کے اندر پوائنٹ ٹو پوائنٹ TLS انکرپشن۔ سنگم بھی فراہم کرتا ہے۔ اپنا آپریٹر.

کارکردگی

اپنے کافکا مثال کو بینچ مارک کرکے کارکردگی کو جانچنا ضروری ہے۔ اس طرح کے ٹیسٹ آپ کو مسائل پیدا ہونے سے پہلے ممکنہ رکاوٹوں کو تلاش کرنے میں مدد کریں گے۔ خوش قسمتی سے، کافکا پہلے ہی کارکردگی کی جانچ کے دو ٹولز فراہم کرتا ہے: kafka-producer-perf-test.sh и kafka-consumer-perf-test.sh. ان کا فعال استعمال کریں۔ حوالہ کے لیے، آپ اس میں بیان کردہ نتائج کا حوالہ دے سکتے ہیں۔ یہ پوسٹ جے کریپس، یا توجہ مرکوز کریں یہ جائزہ ایمیزون ایم ایس کے بذریعہ اسٹیفن ماریک۔

آپریشنز

نگرانی

سسٹم میں شفافیت بہت ضروری ہے ورنہ آپ سمجھ نہیں پائیں گے کہ اس میں کیا ہو رہا ہے۔ آج ایک ٹھوس ٹول کٹ ہے جو کلاؤڈ مقامی انداز میں میٹرکس پر مبنی نگرانی فراہم کرتی ہے۔ اس مقصد کے لیے دو مشہور اوزار Prometheus اور Grafana ہیں۔ Prometheus ایک JMX برآمد کنندہ کا استعمال کرتے ہوئے جاوا کے تمام عملوں (کافکا، زوکیپر، کافکا کنیکٹ) سے میٹرکس اکٹھا کر سکتا ہے - آسان ترین طریقے سے۔ اگر آپ cAdvisor میٹرکس کو شامل کرتے ہیں، تو آپ مزید پوری طرح سمجھ سکتے ہیں کہ Kubernetes میں وسائل کیسے استعمال کیے جاتے ہیں۔

Strimzi کے پاس کافکا کے لیے گرافانا ڈیش بورڈ کی بہت آسان مثال ہے۔ یہ کلیدی میٹرکس کا تصور کرتا ہے، مثال کے طور پر، کم نقل شدہ شعبوں کے بارے میں یا جو آف لائن ہیں۔ وہاں سب کچھ بہت واضح ہے۔ یہ میٹرکس وسائل کے استعمال اور کارکردگی کی معلومات کے ساتھ ساتھ استحکام کے اشاریوں سے مکمل ہوتے ہیں۔ لہذا آپ کو بغیر کسی کام کے بنیادی کافکا کلسٹر مانیٹرنگ مل جاتی ہے!

ماخذ: streamzi.io/docs/master/#kafka_dashboard

اس سب کو کلائنٹ مانیٹرنگ (صارفین اور پروڈیوسرز پر میٹرکس) کے ساتھ ساتھ تاخیر کی نگرانی کے ساتھ پورا کرنا اچھا ہو گا (اس کے لیے یہ ہے دفن) اور اینڈ ٹو اینڈ مانیٹرنگ - اس استعمال کے لیے کافکا مانیٹر.

لاگنگ

لاگنگ ایک اور اہم کام ہے۔ یقینی بنائیں کہ آپ کی کافکا کی تنصیب میں تمام کنٹینرز لاگ ان ہیں۔ stdout и stderr، اور یہ بھی یقینی بنائیں کہ آپ کا Kubernetes کلسٹر تمام لاگز کو مرکزی لاگنگ انفراسٹرکچر میں جمع کرتا ہے، جیسے Elasticsearch.

فنکشنل ٹیسٹنگ

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

اپ ڈیٹس کو رول آؤٹ کرنا

StatefulSets خودکار اپ ڈیٹس کو سپورٹ کرتے ہیں: اگر آپ رولنگ اپ ڈیٹ کی حکمت عملی کو منتخب کرتے ہیں، تو کافکا کے تحت ہر ایک کو باری باری اپ ڈیٹ کیا جائے گا۔ اس طرح، ڈاؤن ٹائم کو صفر تک کم کیا جا سکتا ہے۔

اسکیلنگ

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

انتظامیہ

آپ کے کافکا کلسٹر کے نظم و نسق سے متعلق کام، جیسے موضوعات بنانا اور شعبوں کو دوبارہ تفویض کرنا، آپ کے پوڈز میں کمانڈ لائن انٹرفیس کو کھول کر موجودہ شیل اسکرپٹس کا استعمال کرتے ہوئے کیا جا سکتا ہے۔ تاہم، یہ حل بہت خوبصورت نہیں ہے. Strimzi ایک مختلف آپریٹر کا استعمال کرتے ہوئے موضوعات کو منظم کرنے میں معاونت کرتا ہے۔ یہاں بہتری کی کچھ گنجائش ہے۔

بیک اپ اور بحال

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

حاصل يہ ہوا

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

ماخذ: www.habr.com