رپورٽ Kubernetes ۾ هڪ آپريٽر کي ترقي ڪرڻ، ان جي فن تعمير ۽ آپريشن جي بنيادي اصولن کي ڊزائين ڪرڻ جي عملي مسئلن ڏانهن وقف ڪئي وئي آهي.
رپورٽ جي پهرين حصي ۾، اسان غور ڪنداسين:
- Kubernetes ۾ هڪ آپريٽر ڇا آهي ۽ ان جي ضرورت ڇو آهي؛
- بلڪل ڪيئن آپريٽر پيچيده سسٽم جي انتظام کي آسان بڻائي ٿو؛
- ڇا آپريٽر ڪري سگهي ٿو ۽ ڇا آپريٽر نٿو ڪري سگهي.
اڳيون، اسان آپريٽر جي اندروني ڍانچي جي بحث ڏانهن رخ ڪندا آهيون. قدم ذريعي آپريٽر جي فن تعمير ۽ آپريشن تي غور ڪريو. اچو ته تفصيل سان تجزيو ڪريون:
- آپريٽر ۽ Kubernetes جي وچ ۾ رابطي؛
- آپريٽر ڪھڙا ڪم ڪندو آھي ۽ ڪھڙا نمائندا ڪبرنيٽس ڏانھن.
ڪبرنيٽس ۾ شارڊز ۽ ڊيٽابيس جي نقلن کي منظم ڪرڻ تي غور ڪريو.
اڳيون، اسان ڊيٽا اسٽوريج مسئلن تي بحث ڪنداسين:
- هڪ آپريٽر جي نقطي نظر کان مسلسل اسٽوريج سان ڪيئن ڪم ڪرڻ؛
- مقامي اسٽوريج استعمال ڪرڻ جا نقصان.
رپورٽ جي آخري حصي ۾، اسان اپليڪيشن جي عملي مثالن تي غور ڪنداسين Amazon يا گوگل ڪلائوڊ سروس سان. رپورٽ ڪلڪ هاؤس لاءِ آپريٽر جي ترقي ۽ آپريٽنگ تجربو جي مثال تي ٻڌل آهي.
وڊيو:
منهنجو نالو Vladislav Klimenko آهي. اڄ مان هڪ آپريٽر کي ترقي ۽ هلائڻ ۾ اسان جي تجربي جي باري ۾ ڳالهائڻ چاهيان ٿو، ۽ هي ڊيٽابيس ڪلسٽرز کي منظم ڪرڻ لاءِ هڪ خاص آپريٽر آهي. مثال طور ڪلڪ هائوس ڪلستر کي منظم ڪرڻ لاء.
ڇو اسان کي آپريٽر ۽ ClickHouse جي باري ۾ ڳالهائڻ جو موقعو آهي؟
- اسان ڪلڪ هاؤس جي حمايت ۽ ترقي ڪريون ٿا.
- هن وقت، اسان ڪوشش ڪري رهيا آهيون ته سست رفتاري سان ڪلڪ هاؤس جي ترقي ۾ پنهنجو حصو ڏيو. ۽ ڪلڪ هاؤس ۾ ڪيل تبديلين جي مقدار جي لحاظ کان اسان Yandex کان پوءِ ٻئي نمبر تي آهيون.
- اسان ڪوشش ڪري رهيا آهيون اضافي منصوبا ClickHouse ecosystem لاءِ.
مان انهن منصوبن مان هڪ بابت ڳالهائڻ چاهيندس. هي ڪبرنيٽس لاءِ ClickHouse-operator بابت آهي.
منهنجي رپورٽ ۾، مان ٻن عنوانن تي رابطو ڪرڻ چاهيان ٿو:
- پهريون موضوع اهو آهي ته اسان جو ClickHouse ڊيٽابيس آپريٽر ڪبرنيٽس ۾ ڪيئن ڪم ڪري ٿو.
- ٻيو موضوع اهو آهي ته ڪو به آپريٽر ڪيئن ڪم ڪندو آهي، يعني اهو ڪبرنيٽس سان ڪيئن لهي ٿو.
بهرحال، اهي ٻه سوال منهنجي سڄي رپورٽ ۾ چون ٿا.
ڪير ٻڌڻ ۾ دلچسپي وٺندو جيڪو مان چوڻ جي ڪوشش ڪري رهيو آهيان؟
- سڀ کان وڌيڪ دلچسپ اهي هوندا جيڪي آپريٽرز جو استحصال ڪندا آهن.
- يا انهن لاءِ جيڪي پنهنجو پاڻ ٺاهڻ چاهين ٿا اهو سمجهڻ لاءِ ته اهو اندر ڪيئن ڪم ڪري ٿو، آپريٽر ڪبرنيٽس سان ڪيئن لهي ٿو، ۽ ڪهڙا نقصان ظاهر ٿي سگهن ٿا.
چڱيءَ طرح سمجھڻ لاءِ جيڪو اسان اڄ بحث ڪرڻ وارا آھيون، اھو ڄاڻڻ سٺو ٿيندو ته ڪبرنيٽس ڪھڙي طرح ڪم ڪري ٿو ۽ ڪلائوڊ ڪمپيوٽنگ ۾ بنيادي پس منظر آھي.
ClickHouse ڇا آهي؟ هي هڪ ڪالمن ڊيٽابيس آهي جنهن ۾ تفصيل سان تجزياتي سوالن جي آن لائن پروسيسنگ. ۽ اهو مڪمل طور تي کليل ذريعو آهي.
۽ اسان کي صرف ٻه شيون ڄاڻڻ جي ضرورت آهي. توهان کي ڄاڻڻ جي ضرورت آهي ته هي هڪ ڊيٽابيس آهي، تنهنڪري مان توهان کي ٻڌايان ٿو ته تقريبا ڪنهن به ڊيٽابيس تي لاڳو ٿيندو. ۽ حقيقت اها آهي ته ڪلڪ هاؤس ڊي بي ايم ايس اسڪيل تمام چڱي طرح اسڪيلبلٽي کي تقريبا لڪير ڏئي ٿو. ۽ تنهن ڪري، ڪلستر جي حالت ClickHouse لاء هڪ قدرتي رياست آهي. ۽ اسان بحث ڪرڻ ۾ تمام گهڻي دلچسپي رکون ٿا ته ڪبرنيٽس ۾ ڪلڪ هاؤس ڪلستر جي خدمت ڪيئن ڪجي.
هن کي اتي ڇو ضرورت آهي؟ اسان ان کي پاڻ هلائڻ جاري ڇو نٿا رکي سگهون؟ ۽ جواب جزوي طور تي ٽيڪنالاجي ۽ جزوي طور تي تنظيمي آهن.
- عملي طور تي، گهڻو ڪري اسان کي اهڙي صورتحال سان منهن ڏيڻو پوي ٿو جڏهن وڏي ڪمپنين ۾ تقريبن سڀئي اجزاء اڳ ۾ ئي Kubernetes ۾ آهن. ڊيٽابيس کان ٻاهر رکو.
- ۽ وڌيڪ ۽ وڌيڪ اڪثر سوال پڇيو ويندو آهي: "ڇا اهو اندر رکي سگهجي ٿو؟". تنهن ڪري، وڏيون ڪمپنيون ڪوشش ڪري رهيا آهن ته انتظام جي وڌ ۾ وڌ اتحاد پيدا ڪرڻ لاء جلدي انهن جي ڊيٽا گودام کي منظم ڪرڻ جي قابل ٿي.
- ۽ اهو خاص طور تي مدد ڪري ٿو جيڪڏهن توهان کي هڪ نئين جڳهه تي ساڳئي شيء کي ورجائڻ لاء وڌ ۾ وڌ موقعو جي ضرورت آهي، اهو آهي، وڌ ۾ وڌ پورٽبلٽي.
اهو ڪيترو آسان يا ڏکيو آهي؟ اهو، يقينا، هٿ سان ڪري سگهجي ٿو. پر اهو ايترو آسان ناهي، ڇاڪاڻ ته اسان پاڻ کي ڪبرنيٽس کي منظم ڪرڻ جي پيچيدگي کي وڌايو، پر ساڳئي وقت ڪلڪ هائوس جون خاصيتون لاڳو ڪيون ويون آهن. ۽ اهو ظاهر ٿئي ٿو ته هڪ اهڙي مجموعي.
۽ سڀ گڏجي، هي ٽيڪنالاجي جو هڪ تمام وڏو سيٽ ڏئي ٿو، جنهن کي منظم ڪرڻ اڳ ۾ ئي ڪافي ڏکيو ٿي رهيو آهي، ڇاڪاڻ ته ڪبرنيٽس پنهنجي روزمره جي مسئلن کي آپريشن ۾ آڻيندو آهي، ۽ ڪلڪ هائوس پنهنجي مسئلن کي روزمره جي آپريشن ۾ آڻيندو آهي. خاص طور تي جيڪڏهن اسان وٽ ڪيترائي ڪلڪ هائوس آهن، ۽ اسان کي انهن سان مسلسل ڪجهه ڪرڻ جي ضرورت آهي.
ڪلڪ هائوس هڪ متحرڪ ترتيب سان ڪافي وڏي تعداد ۾ مسئلا آهن جيڪي DevOps تي مسلسل لوڊ ٺاهي رهيا آهن:
- جڏهن اسان ڪلڪ هائوس ۾ ڪجهه تبديل ڪرڻ چاهيون ٿا، مثال طور، هڪ نقل شامل ڪريو، هڪ شارڊ، پوء اسان کي ترتيب ڏيڻ جي ضرورت آهي.
- پوء ڊيٽا اسڪيم کي تبديل ڪريو، ڇاڪاڻ ته ClickHouse وٽ ھڪڙو مخصوص شارڊنگ طريقو آھي. اتي اهو ضروري آهي ته ڊيٽا اسڪيم کي ترتيب ڏيو، ترتيبن کي ترتيب ڏيو.
- توهان کي نگراني قائم ڪرڻ جي ضرورت آهي.
- نون شارڊز لاءِ لاگن جو مجموعو، نئين نقل لاءِ.
- بحالي جو خيال رکجو.
- ۽ ٻيهر شروع ڪريو.
اهي اهڙا معمول جا ڪم آهن جن کي مان آپريشن ۾ تمام گهڻو آسان ڪرڻ چاهيان ٿو.
Kubernetes پاڻ کي آپريشن ۾ تمام گهڻو مدد ڪري ٿو، پر بنيادي سسٽم شين تي.
ڪبرنيٽس شين کي سهولت ڏيڻ ۽ خودڪار ڪرڻ ۾ وڏو آهي جهڙوڪ:
- بحالي.
- ٻيهر شروع ڪريو.
- اسٽوريج جو انتظام.
اھو سٺو آھي، اھو صحيح رستو آھي، پر اھو مڪمل طور تي رابطي کان ٻاھر آھي ته ڊيٽابيس ڪلستر کي ڪيئن هلائڻ لاء.
مان وڌيڪ چاهيان ٿو، مان چاهيان ٿو ته سڄو ڊيٽابيس اسان لاءِ ڪبرنيٽس ۾ ڪم ڪري.
مان ڪجهه حاصل ڪرڻ چاهيان ٿو هڪ وڏي هڪ جادوئي ڳاڙهي بٽڻ وانگر جنهن کي توهان دٻايو ۽ توهان وٽ هڪ ڪلسٽر مقرر ۽ برقرار آهي سڄي زندگي جي چڪر ۾ روزمره جي ڪمن سان گڏ جنهن کي حل ڪرڻ جي ضرورت آهي. ڪبرنيٽس ۾ ڪلڪ هائوس ڪلستر.
۽ اسان هڪ حل ڪرڻ جي ڪوشش ڪئي جيڪا ڪم کي آسان بڻائي سگهندي. ھي آھي ڪلڪ ھائوس-آپريٽر لاءِ Kubernetes کان Altinity.
هڪ آپريٽر هڪ پروگرام آهي جنهن جو بنيادي ڪم ٻين پروگرامن کي منظم ڪرڻ آهي، اهو آهي، اهو هڪ مينيجر آهي.
۽ ان ۾ رويي جي نمونن تي مشتمل آهي. توھان ان کي سڏي سگھو ٿا ڪوڊ ٿيل ڄاڻ بابت موضوع جي علائقي بابت.
۽ هن جو بنيادي ڪم DevOps لاءِ زندگي کي آسان بڻائڻ ۽ مائڪرو مئنيجمينٽ کي گهٽائڻ آهي ته جيئن هو (DevOps) اڳ ۾ ئي اعليٰ سطحي اصطلاحن ۾ سوچيندو هجي، يعني ته هو (DevOps) مائڪرو مئنيج نٿو ڪري، ته جيئن هو دستي طور تي ترتيب نه ڏئي. تفصيل.
۽ صرف آپريٽر هڪ روبوٽ اسسٽنٽ آهي جيڪو مائڪرو ٽاسڪس سان جدوجهد ڪري ٿو ۽ DevOps جي مدد ڪري ٿو.
ڇو هڪ آپريٽر جي ضرورت آهي؟ هن کي ٻن علائقن ۾ شاندار آهي:
- جڏهن هڪ ClickHouse ماهر وٽ ڪافي تجربو نه هوندو آهي، پر ClickHouse کي هلائڻ لاءِ پهريان کان ئي ضروري هوندو آهي، آپريٽر آپريشن کي آسان بڻائي ٿو ۽ توهان کي اجازت ڏئي ٿو ته ڪلڪ هاؤس ڪلسٽر کي هڪ بلڪه پيچيده ترتيب سان هلائڻ جي، جڏهن ته ان بابت تمام گهڻي تفصيل ۾ نه وڃي ته اهو سڀ ڪجهه اندر ڪيئن ڪم ڪري ٿو. . توهان صرف هن کي اعلي سطحي ڪم ڏيو، ۽ اهو ڪم ڪري ٿو.
- ۽ ٻيو ڪم جنهن ۾ اهو پاڻ کي تمام سٺو ڏيکاري ٿو جڏهن اهو ضروري آهي ته وڏي تعداد ۾ عام ڪمن کي خودڪار ڪرڻ. sysadmins مان microtasks هٽائي ٿو.
اهو سڀ کان وڌيڪ گهربل آهي انهن جي طرفان جيڪي صرف پنهنجو سفر شروع ڪري رهيا آهن، يا انهن جي طرفان جن کي تمام گهڻو خودڪار ڪرڻ جي ضرورت آهي.
آپريٽر تي ٻڌل طريقي ۽ ٻين سسٽم جي وچ ۾ ڇا فرق آهي؟ هيلم پڻ آهي. اهو پڻ ڪلڪ هاؤس کي انسٽال ڪرڻ ۾ مدد ڪري ٿو، توهان هيلم چارٽ ٺاهي سگهو ٿا، جيڪو پڻ مڪمل ڪلڪ هاؤس ڪلستر کي نصب ڪندو. پوء ڇا فرق آهي آپريٽر جي وچ ۾ ۽ ساڳئي کان، مثال طور، هيلم؟
بنيادي بنيادي فرق اهو آهي ته هيلم پيڪيج جي انتظام بابت آهي، ۽ آپريٽر هڪ قدم اڳتي وڌندو آهي. هي سڄي زندگي چڪر جو سهارو آهي. اهو صرف تنصيب نه آهي، اهي روزمره جا ڪم آهن جن ۾ شامل آهن اسڪيلنگ، شارڊنگ، يعني هر شيء جيڪا زندگي جي چڪر دوران ڪرڻ جي ضرورت آهي (جيڪڏهن ضروري هجي، هٽائڻ به) - اهو سڀ آپريٽر طرفان فيصلو ڪيو ويندو آهي. اهو خودڪار ڪرڻ جي ڪوشش ڪري ٿو ۽ پوري سافٽ ويئر جي زندگي جي چڪر کي خدمت ڪري ٿو. اهو ان جو بنيادي فرق آهي ٻين حلن کان جيڪي پيش ڪيا ويا آهن.
اهو تعارفي حصو هو، اچو ته اڳتي وڌون.
اسان پنهنجي آپريٽر کي ڪيئن ٺاهيندا آهيون؟ اسان هڪ واحد وسيلن جي طور تي ClickHouse ڪلستر کي منظم ڪرڻ لاء مسئلي کي حل ڪرڻ جي ڪوشش ڪري رهيا آهيون.
هتي اسان وٽ ان پٽ ڊيٽا آهي تصوير جي کاٻي پاسي. هي YAML هڪ ڪلستر جي وضاحت سان آهي، جيڪو ڪلاسيڪل طور تي ڪبيڪٽل ذريعي ڪبرنيٽس تائين پهچايو ويندو آهي. اتي، اسان جو آپريٽر ان کي کڻندو آھي، سندس جادو ڪندو آھي. ۽ نتيجي طور، اسان کي اهڙي اسڪيم حاصل ڪري. هي ڪبرنيٽس ۾ ClickHouse جو نفاذ آهي.
۽ پوءِ اسان آهستي آهستي ڏسنداسين ته آپريٽر ڪيئن ڪم ڪري ٿو، ڪهڙا عام ڪم حل ٿي سگهن ٿا. اسان صرف عام ڪمن تي غور ڪنداسين، ڇاڪاڻ ته اسان وٽ محدود وقت آهي. ۽ اهو هر شي بابت نه ٻڌايو ويندو ته آپريٽر فيصلو ڪري سگهي ٿو.
اچو ته مشق کان شروع ڪريون. اسان جو منصوبو مڪمل طور تي کليل ذريعو آهي، تنهنڪري توهان ڏسي سگهو ٿا ته اهو ڪيئن ڪم ڪري ٿو GitHub تي. ۽ توهان غور سان اڳتي وڌائي سگهو ٿا، جيڪڏهن توهان صرف شروع ڪرڻ چاهيو ٿا، ته پوء توهان شروع ڪري سگهو ٿا تڪڙو شروع گائيڊ سان.
جيڪڏھن توھان تفصيل سان سمجھڻ چاھيو ٿا، ته پوءِ اسان ڪوشش ڪريون ٿا دستاويز کي وڌيڪ يا گھٽ مهذب شڪل ۾ برقرار رکون.
اچو ته هڪ عملي مسئلي سان شروع ڪريون. پهريون ڪم جيڪو اسان سڀني سان شروع ڪرڻ چاهيون ٿا اهو پهريون مثال هلائڻ آهي ڪنهن به طرح. هڪ آپريٽر جي مدد سان ڪلڪ هاؤس کي ڪيئن لانچ ڪيو، اهو ڄاڻڻ کان سواءِ ته اهو ڪيئن ڪم ڪري ٿو؟ اسان هڪ منشور لکي رهيا آهيون، ڇاڪاڻ ته k8s سان سڀ ڪميونيڪيشن منشور ذريعي ڪميونيڪيشن آهي.
هتي اهڙي پيچيده منشور آهي. جيڪو اسان ڳاڙهي ۾ نمايان ڪيو آهي اهو آهي جيڪو اسان کي ڌيان ڏيڻ جي ضرورت آهي. اسان آپريٽر کان پڇون ٿا ته ڊيمو نالي هڪ ڪلستر ٺاهي.
في الحال، اهي بنيادي مثال آهن. اسٽوريج اڃا تائين بيان نه ڪيو ويو آهي، پر اسان ٿوري دير بعد اسٽوريج ڏانهن واپس ڪنداسين. في الحال، اسان ڪلستر جي ترقي کي متحرڪ ۾ ڏسندا سين.
اسان هي منشور ٺاهيو آهي. اسان ان کي اسان جي آپريٽر کي کارايو. هن ڪم ڪيو، هن جادو ڪيو.
اسان ڪنسول کي ڏسو. ٽي حصا دلچسپي جا آهن - اهي آهن پوڊ، ٻه سروس-ا، اسٽيٽفول سيٽ.
آپريٽر ڪم ڪيو آھي، ۽ اسان ڏسي سگھون ٿا ته اھو ڇا ٺاھيو.
هو اهڙي شيءِ ٺاهي ٿو. اسان وٽ آھي StatefulSet، Pod، ConfigMap ھر ھڪ نقل لاءِ، ConfigMap پوري ڪلستر لاءِ. لازمي طور تي ڪلستر ۾ داخلا پوائنٽ جي طور تي خدمتون.
خدمتون مرڪزي لوڊ بيلنس سروس آهن ۽ اهو ممڪن آهي هر نقل لاءِ، هر شارڊ لاءِ.
هتي اسان جو بنيادي ڪلستر ڪجهه هن طرح نظر اچي ٿو. هو هڪ واحد نوڊ مان آهي.
اچو ته اڳتي وڌو، اسان پيچيده ڪنداسين. توهان کي ڪلستر کي ڇڪڻ جي ضرورت آهي.
اسان جا ڪم وڌي رهيا آهن، متحرڪ شروع ٿي رهيا آهن. اسان هڪ شارٽ شامل ڪرڻ چاهيون ٿا. اسان ترقي جي پيروي ڪندا آهيون. اسان اسان جي وضاحت کي تبديل ڪريون ٿا. اسان اشارو ڪريون ٿا ته اسان ٻه حصا چاهيون ٿا.
اهو ساڳيو فائل آهي جيڪو اسان متحرڪ طور تي سسٽم جي ترقي سان ترقي ڪري ٿو. ذخيرا ناهي، ذخيري تي اڳتي بحث ڪيو ويندو، اهو هڪ الڳ مسئلو آهي.
اسان YAML آپريٽر کي کارايو ۽ ڏسو ته ڇا ٿئي.
آپريٽر سوچيو ۽ ھيٺيون ادارا ٺاھيو. اسان وٽ اڳ ۾ ئي ٻه پوڊ، ٽي خدمتون ۽، اوچتو، 2 StatefulSets. ڇو 2 StatefulSets؟
اهو ڊاگرام تي هن طرح هو - هي اسان جي شروعاتي حالت آهي، جڏهن اسان وٽ هڪ پوڊ هو.
ائين ٿي ويو. ايترو پري، هر شيء سادو آهي، اهو نقل ڪيو ويو آهي.
۽ رياستي سيٽ ٻه ڇو ٿي ويا؟ هتي اسان کي ان سوال تي بحث ڪرڻ گهرجي ته ڪبرنيٽس ۾ پوڊ ڪيئن منظم ڪيا ويندا آهن.
هتي هڪ اهڙي شئي آهي جنهن کي StatefulSet سڏيو ويندو آهي، جيڪو توهان کي ٽيمپليٽ مان پوڊ جو هڪ سيٽ ٺاهڻ جي اجازت ڏئي ٿو. هتي اهم عنصر آهي Template. ۽ توھان ھڪڙي ٽيمپليٽ جي مطابق ھڪڙي StatefulSet ۾ ڪيترائي پوڊ هلائي سگھو ٿا. ۽ هتي جو اهم جملو آهي ”هڪ ٽيمپليٽ ڪيترائي پوڊ“.
۽ سڄي ڪلستر کي ٺاهڻ لاءِ هڪ وڏو لالچ هو، ان کي هڪ StatefulSet ۾ پيڪ ڪرڻ. اهو ڪم ڪندو، ان ۾ ڪو مسئلو ناهي. پر اتي هڪ caveat آهي. جيڪڏهن اسان هڪ هيٽروجنيئس ڪلسٽر گڏ ڪرڻ چاهيون ٿا، يعني ڪلڪ هائوس جي ڪيترن ئي ورزن مان، پوءِ اسان جا سوال شروع ٿين ٿا. ها، StatefulSet هڪ رولنگ اپڊيٽ ڪري سگهي ٿو، پر اتي توهان هڪ نئون ورزن رول آئوٽ ڪري سگهو ٿا، وضاحت ڪريو ته توهان کي هڪ ئي وقت ڪيترن ئي نوڊس کان وڌيڪ ڪوشش ڪرڻ جي ضرورت ناهي.
پر جيڪڏهن اسان ڪم کي وڌايو ۽ چئون ته اسان هڪ مڪمل طور تي هيٽروجنيئس ڪلسٽر ٺاهڻ چاهيون ٿا ۽ هڪ رولنگ اپڊيٽ استعمال ڪندي پراڻي ورزن کان نئين نسخي ۾ تبديل ڪرڻ نٿا چاهيون، پر صرف مختلف ورزن جي لحاظ کان هيٽروجنيئس ڪلسٽر ٺاهڻ چاهيون ٿا. ClickHouse جو ۽ مختلف اسٽوريج جي لحاظ کان. اسان چاهيون ٿا، مثال طور، الڳ ڊسڪ تي ڪجهه نقل ٺاهڻ، سست تي، عام طور تي، مڪمل طور تي هيٽروجنيئس ڪلسٽر ٺاهڻ لاءِ. ۽ حقيقت اها آهي ته StatefulSet هڪ ٽيمپليٽ مان هڪ معياري حل ٺاهي ٿو، تنهنڪري اهو ڪرڻ جو ڪو طريقو ناهي.
ڪجهه سوچ ويچار کان پوءِ اهو فيصلو ڪيو ويو ته اسان ائين ڪندا آهيون. اسان وٽ هر هڪ نقل آهي ان جي پنهنجي StatefulSet ۾. هن حل ۾ ڪجهه خرابيون آهن، پر عملي طور تي اهو سڀ ڪجهه مڪمل طور تي آپريٽر کي شامل ڪري ٿو. ۽ ڪيترائي فائدا آھن. اسان هڪ مڪمل طور تي اهڙي ڪلستر ٺاهي سگهون ٿا جيئن اسان چاهيون ٿا، مثال طور، هڪ بلڪل متضاد. تنهن ڪري، هڪ ڪلستر ۾ جنهن ۾ اسان وٽ ٻه شارڊ آهن هڪ ريپليڪا سان، اسان وٽ 2 StatefulSets ۽ 2 پوڊز صحيح طور تي هوندا ڇو ته اسان هي طريقو چونڊيو مٿين سببن جي ڪري هيٽروجنيئس ڪلسٽر ٺاهڻ جي صلاحيت جي ڪري.
اچو ته عملي ڪمن ڏانهن موٽون. اسان جي ڪلستر ۾، اسان کي صارفين کي ترتيب ڏيڻ جي ضرورت آهي، يعني. توهان کي ڪبرنيٽس ۾ ڪلڪ هائوس جي ڪجهه ترتيب ڏيڻ جي ضرورت آهي. آپريٽر هن لاء سڀ امڪان مهيا ڪري ٿو.
اسان لکي سگھون ٿا جيڪو اسان چاهيون ٿا سڌو سنئون YAML ۾. سڀ ٺاھ جوڙ جا اختيار سڌو ھن YAML کان ڪلڪ ڪيو ھاؤس جي ترتيبن ۾ نقشا ڪيا ويا آھن، جيڪي پوءِ پوري ڪلستر ۾ ٺھيل آھن.
توهان به هن طرح لکي سگهو ٿا. هي هڪ مثال لاء آهي. پاسورڊ انڪريپٽ ٿي سگھي ٿو. بلڪل سڀ ڪلڪ هاؤس جي ٺاھ جوڙ جا اختيار سپورٽ آھن. هتي صرف هڪ مثال آهي.
ڪلستر جي ٺاھ جوڙ کي ConfigMap طور ورهايو ويو آھي. عملي طور تي، ConfigMap تازه ڪاري فوري طور تي نه ٿيندي آهي، تنهنڪري جيڪڏهن ڪو وڏو ڪلستر آهي، ته پوء ترتيب ڏيڻ جي عمل کي ڪجهه وقت وٺندو آهي. پر هي سڀ استعمال ڪرڻ بلڪل آسان آهي.
اسان ڪم کي پيچيده ڪريون ٿا. ڪلستر ترقي ڪري رهيو آهي. اسان ڊيٽا کي نقل ڪرڻ چاهيون ٿا. اهو آهي، اسان وٽ اڳ ۾ ئي ٻه شارڊ آهن، هڪ نقل هر هڪ، صارفين کي ترتيب ڏنل آهن. اسان وڌي رهيا آهيون ۽ نقل ڪرڻ چاهيون ٿا.
اسان کي نقل ڪرڻ جي ڪهڙي ضرورت آهي؟
اسان کي ZooKeeper جي ضرورت آهي. ClickHouse ۾، نقل ZooKeeper استعمال ڪندي ٺهيل آهي. ZooKeeper جي ضرورت آهي ته جيئن مختلف ClickHouse replicas تي اتفاق هجي ته ڪهڙن ڊيٽا بلاڪن تي ڪلڪ ڪيو هائوس.
ZooKeeper هر ڪنهن کي استعمال ڪري سگهجي ٿو. جيڪڏهن هڪ ادارتي هڪ ٻاهرين ZooKeeper آهي، پوء ان کي استعمال ڪري سگهجي ٿو. جيڪڏهن نه، ته پوء توهان اسان جي مخزن مان انسٽال ڪري سگهو ٿا. اتي ھڪڙو انسٽالر آھي جيڪو ھن سڄي شيء کي آسان بڻائي ٿو.
۽ سڄي نظام جي رابطي جو منصوبو هن طرح نڪرندو آهي. اسان وٽ ڪبرنيٽس هڪ پليٽ فارم آهي. اهو ڪلڪ هائوس بيان تي عمل ڪري ٿو. ZooKeeper مون هتي تصوير ڪئي. ۽ آپريٽر ٻنهي ClickHouse ۽ ZooKeeper سان رابطو ڪري ٿو. اهو آهي، هڪ رابطي حاصل ڪئي وئي آهي.
۽ اهو سڀ ضروري آهي ClickHouse لاءِ ڊيٽا کي ڪاميابيءَ سان نقل ڪرڻ لاءِ k8s.
اچو ته ھاڻي ٽاسڪ پاڻ ڏسون، نقل لاءِ منشور ڪيئن نظر ايندو.
اسان پنهنجي منشور ۾ ٻه حصا شامل ڪندا آهيون. پهريون اهو آهي جتي حاصل ڪجي ZooKeeper، جيڪو يا ته ڪبرنيٽس جي اندر يا ٻاهران ٿي سگهي ٿو. هي صرف هڪ وضاحت آهي. ۽ اسان replicas حڪم. اهي. اسان ٻه نقل چاهيون ٿا. مجموعي طور تي، اسان وٽ 4 پوڊ هجڻ گهرجن. اسان کي اسٽوريج جي باري ۾ ياد رکون ٿا، اهو ٿورو اڳتي موٽندو. ذخيرو هڪ الڳ گيت آهي.
اهو هن طرح هو.
ائين ٿئي ٿو. نقل شامل ڪيا ويا آهن. چوٿون نه هو، اسان سمجهون ٿا ته انهن مان گهڻا هوندا. ۽ ZooKeeper پاسي تي شامل ڪيو ويو آھي. نمونا وڌيڪ پيچيده ٿي رهيا آهن.
۽ اهو ايندڙ ڪم شامل ڪرڻ جو وقت آهي. اسان مستقل اسٽوريج شامل ڪنداسين.
مسلسل اسٽوريج لاء، اسان وٽ مختلف قسم جا اختيار آهن.
جيڪڏهن اسان ڪلائوڊ فراهم ڪندڙ ۾ هلائي رهيا آهيون، مثال طور، Amazon، گوگل استعمال ڪندي، پوءِ ڪلائوڊ اسٽوريج استعمال ڪرڻ لاءِ هڪ وڏو لالچ آهي. اهو تمام آسان آهي، اهو سٺو آهي.
۽ ٻيو اختيار آهي. هي مقامي اسٽوريج لاء آهي، جڏهن اسان وٽ هر نوڊ تي مقامي ڊسڪ آهي. هي اختيار لاڳو ڪرڻ تمام گهڻو ڏکيو آهي، پر ساڳئي وقت اهو وڌيڪ پيداوار آهي.
اچو ته ڏسون ته اسان وٽ ڪلائوڊ اسٽوريج بابت ڇا آهي.
خوبيون آهن. اهو ترتيب ڏيڻ بلڪل آسان آهي. اسان صرف بادل فراهم ڪندڙ کان حڪم ڪريون ٿا ته مهرباني ڪري اسان کي اهڙي ۽ اهڙي گنجائش، اهڙي ۽ اهڙي طبقي جو ذخيرو ڏيو. ڪلاس فراهم ڪندڙ طرفان آزاد طور تي رنگا ويا آهن.
۽ اتي هڪ drawback آهي. ڪجهه لاء، هي هڪ غير معمولي گهٽتائي آهي. يقينا، اتي ڪجهه ڪارڪردگي اوورليز هوندي. اهو استعمال ڪرڻ تمام آسان آهي، قابل اعتماد، پر ڪارڪردگي ۾ ڪجهه امڪاني خرابيون آهن.
۽ کان وٺي ڪلڪ هائوس ڪارڪردگي تي ڌيان ڏئي ٿو، توهان اهو به چئي سگهو ٿا ته اهو هر شيء کي نچوض ڪري ٿو جيڪو ممڪن آهي، تنهنڪري ڪيترائي گراهڪ وڌ کان وڌ ڪارڪردگي کي نچوض ڪرڻ جي ڪوشش ڪندا آهن.
۽ ان مان تمام گهڻو فائدو حاصل ڪرڻ لاءِ، اسان کي مقامي اسٽوريج جي ضرورت آهي.
ڪبرنيٽس ڪبرنيٽس ۾ مقامي اسٽوريج استعمال ڪرڻ لاءِ ٽي خلاصيون مهيا ڪري ٿي. هي:
- خالي ڊائر
- HostPath.
- مقامي
غور ڪريو ته اهي ڪيئن مختلف آهن، اهي ڪيئن هڪجهڙا آهن.
پهرين، سڀني ٽن طريقن ۾، اسان وٽ اسٽوريج آهي - اهي مقامي ڊسڪ آهن جيڪي ساڳئي جسماني k8s نوڊ تي واقع آهن. پر انهن ۾ ڪجهه اختلاف آهن.
اچو ته سڀ کان آسان سان شروع ڪريون، يعني emptyDir. عملي طور تي ڇا آهي؟ اهو اسان آهيون جيڪو اسان جي وضاحتن کان ڪنٽينرائيزيشن سسٽم (اڪثر ڪري ڊاڪر) کان پڇو ته اسان کي مقامي ڊسڪ تي فولڊر تائين رسائي فراهم ڪري.
عملي طور تي، ڊاکر پنهنجي رستن ۾ هڪ عارضي فولڊر ٺاهي ٿو، ان کي هڪ ڊگهو هيش سڏيندو آهي. ۽ ان کي رسائي حاصل ڪرڻ لاء هڪ انٽرفيس مهيا ڪري.
ڪارڪردگي جي لحاظ کان اهو ڪيئن ٿيندو؟ اهو مقامي ڊسڪ جي رفتار تي هلندو، يعني. هي توهان جي اسڪرو تائين مڪمل رسائي آهي.
پر هن معاملي ۾ ان جي نقصان آهي. هن معاملي ۾ مستقل مزاجي آهي. ڪنٽينرز سان ڊاکر جي پهرين حرڪت تي، مسلسل گم ٿي ويو آهي. جيڪڏهن ڪبرنيٽس ڪنهن سبب لاءِ هن پوڊ کي ٻي ڊسڪ ۾ منتقل ڪرڻ چاهي ته پوءِ ڊيٽا گم ٿي ويندي.
اهو طريقو ٽيسٽ لاء سٺو آهي، ڇاڪاڻ ته اهو اڳ ۾ ئي عام رفتار ڏيکاري ٿو، پر هي اختيار ڪجهه سنجيده لاء مناسب ناهي.
تنهن ڪري، اتي هڪ ٻيو طريقو آهي. هي آهي hostPath. جيڪڏھن توھان ڏسو پوئين سلائڊ ۽ ھي ھڪڙو، توھان ڏسي سگھوٿا صرف ھڪڙو فرق. اسان جو فولڊر ڊڪر کي ڇڏي سڌو ڪبرنيٽس نوڊ ڏانھن. هتي ٿورو تيز آهي. اسان سڌو سنئون مقامي فائل سسٽم تي رستو لکون ٿا جتي اسان اسان جي ڊيٽا کي ذخيرو ڪرڻ چاهيندا آهيون.
هي طريقو فائدا آهن. اهو اڳ ۾ ئي هڪ حقيقي مسلسل، ۽ هڪ کلاسک آهي. اسان جي ڊسڪ تي، ڊيٽا کي ڪجهه پتي تي لکيو ويندو.
اتي به نقصان آهن. هي انتظام جي پيچيدگي آهي. اسان جا ڪبرنيٽس شايد پوڊ کي ٻئي جسماني نوڊ ڏانهن منتقل ڪرڻ چاهيندا. اهو آهي جتي DevOps راند ۾ اچي ٿو. اهو صحيح طور تي سڄي سسٽم کي وضاحت ڪرڻ گهرجي ته توهان صرف انهن پوڊس کي اهڙن نوڊس ڏانهن منتقل ڪري سگهو ٿا جن تي توهان انهن رستن تي ڪجهه نصب ڪيو آهي، ۽ هڪ وقت ۾ هڪ کان وڌيڪ نوڊ نه. اهو ڪافي ڏکيو آهي.
خاص ڪري انهن مقصدن لاءِ، اسان پنهنجي آپريٽر ۾ ٽيمپليٽس ٺاهيا آهن ته جيئن هن سموري پيچيدگي کي لڪايو وڃي. ۽ توهان صرف اهو چئي سگهو ٿا: "مان چاهيان ٿو ڪلڪ هاؤس جو هڪ مثال في فزيڪل نوڊ ۽ اهڙي ۽ اهڙي رستي سان."
پر اها ضرورت صرف اسان جي لاءِ نه آهي، تنهنڪري خود ڪبرنيٽس جا حضرات به سمجهن ٿا ته ماڻهو چاهين ٿا ته فزيڪل ڊسڪ تائين پهچ هجي، ان ڪري اهي ٽيون سطح فراهم ڪن ٿا.
اهو مقامي سڏيو ويندو آهي. پوئين سلائڊ کان عملي طور تي ڪوبه فرق ناهي. صرف اڳ ۾ هٿ سان کڻڻ ضروري هو ته اسان انهن پوڊس کي نوڊ کان نوڊ ڏانهن منتقل نه ڪري سگهون ٿا، ڇاڪاڻ ته اهي لازمي طور تي مقامي فزيڪل ڊسڪ سان ڳنڍيل هوندا، ۽ هاڻي اهو سمورو علم خود ڪبرنيٽس ۾ سمايل آهي. ۽ ان کي ترتيب ڏيڻ لاء تمام آسان ٻاهر ڦرندو.
اچو ته اسان جي عملي ڪم ڏانهن موٽون. اچو ته واپس وڃون YAML ٽيمپليٽ. هتي اسان وٽ هڪ حقيقي اسٽوريج آهي. اسان هن ڏانهن واپس آهيون. اسان k8s وانگر کلاسک VolumeClaim ٽيمپليٽ سيٽ ڪيو. ۽ اسان بيان ڪريون ٿا ته ڪهڙي قسم جي اسٽوريج اسان چاهيون ٿا.
ان کان پوء، k8s اسٽوريج جي درخواست ڪندو. ان کي اسان کي StatefulSet ۾ مختص ڪريو. ۽ آخر ۾، ان کي ٻاهر ڦرندو ClickHouse جي اختياري تي.
اسان وٽ هڪ اهڙي اسڪيم هئي. اسان جي پرسسٽنٽ اسٽوريج ڳاڙهي هئي، جنهن مان لڳي رهيو هو ته اهو ٿيڻ گهرجي.
۽ سائو ٿي ويندو آهي. ھاڻي ڪلڪ ھاؤس تي k8s ڪلستر اسڪيم مڪمل طور تي حتمي آھي. اسان وٽ شارڊز، ريپليڪس، زو ڪيپر، اسان وٽ حقيقي مستقل آهي، جيڪو هڪ طريقي سان لاڳو ٿئي ٿو. اسڪيم اڳ ۾ ئي مڪمل طور تي آپريشنل آهي.
اسان جاري رهنداسين. اسان جو ڪلستر وڌي رهيو آهي. ۽ اليڪسي ڪوشش ڪري رهيو آهي ۽ ڪلڪ هاؤس جو نئون ورزن جاري ڪري رهيو آهي.
ھڪڙو عملي ڪم پيدا ٿئي ٿو - اسان جي ڪلستر تي ClickHouse جي نئين نسخي کي جانچڻ لاء. ۽، يقيناً، مان اهو سڀ ڪجهه ٻاهر ڪڍڻ نه ٿو چاهيان، مان چاهيان ٿو ته هڪ نئون نسخو ڪنهن دور جي ڪنڊ ۾ هڪ نقل ۾، يا شايد هڪ نئون نسخو نه، پر هڪ ڀيرو ٻه، ڇاڪاڻ ته اهي اڪثر نڪرندا آهن.
اسان ان بابت ڇا چئي سگهون ٿا؟
هتي اسان وٽ صرف هڪ موقعو آهي. اهي پوڊ ٽيمپليٽ آهن. توهان رنگ ڪري سگهو ٿا، اسان جو آپريٽر مڪمل طور تي توهان کي اجازت ڏئي ٿو ته هيٽروجنيئس ڪلستر ٺاهي. اهي. ترتيب ڏيو، ھڪڙي گروپ ۾ سڀني نقلن کان شروع ٿي، ھر ھڪڙي ذاتي نقل سان ختم ٿي، اسان کي ڪھڙو ورزن گھرجي ClickHouse، جنھن جو ورجن اسان کي اسٽوريج گھرجي. اسان ڪلستر کي مڪمل طور تي ترتيب ڏئي سگھون ٿا اھڙي ترتيب ۾ جيئن اسان کي ضرورت آھي.
اچو ته ٿورو اندر وڃون. ان کان اڳ، اسان ڳالهايو ته ڪيئن ClickHouse-آپريٽر ClickHouse جي خاصيتن جي سلسلي ۾ ڪم ڪندو آهي.
ھاڻي مان ڪجھ لفظ چوڻ چاھيندس ته ڪھڙي طرح ڪو آپريٽر عام طور ڪم ڪري ٿو، ۽ اھو ڪھڙي ريت K8s سان لاڳاپو رکي ٿو.
شروع ڪرڻ لاءِ K8s سان رابطي تي غور ڪريو. ڇا ٿيندو جڏهن اسان ڪبيڪٽل لاڳو ڪندا آهيون؟ API ذريعي، اسان جون شيون وغيره ۾ ظاهر ٿيندا آهن.
مثال طور، بنيادي Kubernetes شيون: pod، StatefulSet، service، ۽ پوءِ لسٽ ذريعي.
بهرحال، ڪجھ به جسماني اڃا تائين نه ٿي رهيو آهي. اهي شيون هڪ ڪلستر ۾ مادي هجڻ گهرجن.
هي آهي جتي ڪنٽرولر اندر اچي ٿو. ڪنٽرولر هڪ خاص k8s جزو آهي جيڪو انهن وضاحتن کي مادي ڪري سگهي ٿو. هو ڄاڻي ٿو ته جسماني طور ڪيئن ۽ ڇا ڪجي. هو ڄاڻي ٿو ته ڪنٽينرز کي ڪيئن هلائڻو آهي، سرور کي ڪم ڪرڻ لاءِ اتي ڪهڙي ترتيب جي ضرورت آهي.
۽ اهو K8s ۾ اسان جي شين کي مادي ڪري ٿو.
پر اسان نه صرف پوڊس، اسٽيٽفول سيٽن سان هلائڻ چاهيون ٿا، اسان چاهيون ٿا هڪ ڪلڪ هاؤس انسٽالشن، يعني ڪلڪ هاؤس قسم جو هڪ اعتراض، انهي سان مڪمل طور تي هلائڻ لاءِ. هينئر تائين، اهڙو ڪو به امڪان ناهي.
پر K8s وٽ هڪ ٻي سٺي شيءِ آهي. اسان چاهيون ٿا ته اسان کي ڪنهن جاءِ تي اهڙو پيچيده ادارو هجي، جنهن ۾ اسان جو ڪلستر پوڊس ۽ اسٽيٽفول سيٽ مان گڏ ڪيو وڃي.
۽ ان لاءِ ڇا ڪرڻ گهرجي؟ پهريون، ڪسٽم وسيلن جي تعريف منظر ۾ داخل ٿئي ٿي. هي ڇا آهي؟ هي K8s لاءِ هڪ وضاحت آهي ته توهان وٽ هڪ ٻيو ڊيٽا جو قسم هوندو جنهن کي اسان پوڊ ۾ شامل ڪرڻ چاهيون ٿا، StatefulSet، هڪ ڪسٽم وسيلو جيڪو اندر پيچيده هوندو. هي ڊيٽا جي جوڙجڪ جي وضاحت آهي.
اسان ان کي اتي پڻ موڪليندا آهيون kubectl apply. ڪبرنيٽس خوشيءَ سان اهو ورتو.
۽ ھاڻي اسان جي ذخيري ۾، اي سي ڊي ۾ اعتراض کي ڪلڪ ھاؤس انسٽالشن نالي ھڪڙي ڪسٽم ريسورس لکڻ جو موقعو آھي.
پر في الحال، ٻيو ڪجهه به نه ٿيندو. اھو آھي، جيڪڏھن ھاڻي اسان ھڪڙو YAML فائل ٺاھيو آھي جنھن کي اسان شارڊ جي وضاحت سان سمجھيو آھي، replicas ۽ چوندا آھن ”kubectl apply“، پوءِ ڪبرنيٽس ان کي قبول ڪندا، ان کي etcd ۾ وجھو ۽ چوندا: ”ڏاڍو، پر مون کي خبر ناهي. ان سان ڇا ڪجي. مون کي خبر ناهي ته ClickHouseInstallation ڪيئن برقرار رکجي.
انهي جي مطابق، اسان کي ڪنهن جي مدد ڪرڻ جي ضرورت آهي Kubernetes نئين ڊيٽا جي قسم جي خدمت ڪرڻ ۾. کاٻي پاسي، اسان وٽ ھڪڙو اسٽاڪ ڪبرنيٽس ڪنٽرولر آھي جيڪو ڪم ڪري ٿو اسٽاڪ ڊيٽا جي قسمن سان. ۽ ساڄي پاسي، اسان وٽ ھڪڙو ڪسٽم ڪنٽرولر ھئڻ گھرجي جيڪو ڪم ڪري سگھي ٿو ڪسٽم ڊيٽا جي قسمن سان.
۽ ٻئي طريقي سان ان کي آپريٽر سڏيو ويندو آهي. مون خاص طور تي ڪبرنيٽس لاءِ هتي ڪڍيو آهي، ڇاڪاڻ ته اهو پڻ K8s کان ٻاهر ٿي سگهي ٿو. گهڻو ڪري، يقينا، سڀني بيانن تي عمل ڪيو ويو آهي Kubernetes، پر ڪجھ به ان کي ٻاهر نڪرڻ کان روڪي نٿو سگهي، تنهنڪري هتي خاص طور تي ڪڍيو ويو آهي.
۽ اڳ ۾ ئي، موڙ ۾، ڪسٽم ڪنٽرولر، پڻ آپريٽر جي نالي سان سڃاتو وڃي ٿو، API ذريعي ڪبرنيٽس سان رابطو ڪري ٿو. هو اڳ ۾ ئي ڄاڻي ٿو ته API سان ڪيئن لهه وچڙ ۾. ۽ هو اڳ ۾ ئي ڄاڻي ٿو ته هڪ پيچيده اسڪيم کي ڪيئن ٺاهيو جيڪو اسان هڪ ڪسٽم وسيلن مان ٺاهڻ چاهيون ٿا. اهو ئي آهي جيڪو آپريٽر ڪندو آهي.
آپريٽر ڪيئن ڪم ڪندو آهي؟ اچو ته ساڄي پاسي تي هڪ نظر رکون ته ڏسو ته هو اهو ڪيئن ڪندو آهي. اسان اهو معلوم ڪنداسين ته آپريٽر اهو سڀ ڪجهه ڪيئن ڪري ٿو ۽ K8s سان وڌيڪ رابطو ڪيئن ٿئي ٿو.
آپريٽر پروگرام آهي. هوء واقعي تي مبني آهي. آپريٽر Kubernetes API استعمال ڪندي واقعن جي رڪنيت حاصل ڪري ٿو. Kubernetes API وٽ داخلا پوائنٽون آھن جتي توھان رڪنيت حاصل ڪري سگھو ٿا واقعن جي. ۽ جيڪڏهن K8s ۾ ڪا شيء تبديل ٿئي ٿي، پوء ڪبرنيٽس هر ڪنهن کي واقعا موڪلي ٿو، يعني. جيڪو هن API پوائنٽ تي سبسڪرائب ڪيو اهي نوٽيفڪيشن وصول ڪندا.
آپريٽر واقعن جي رڪنيت حاصل ڪري ٿو، ۽ ڪجهه قسم جي رد عمل کي ضرور ڪرڻ گهرجي. ان جو ڪم اڀرندڙ واقعن جو جواب ڏيڻ آهي.
واقعا ڪجهه تازه ڪارين ذريعي ٺاهيا ويا آهن. اسان جي YAML فائل اچي ٿي ClickHouseInstallation جي وضاحت سان. هو kubectl apply ذريعي etcd ڏانهن ويو. اتي هڪ واقعو ڪم ڪيو، جنهن جي نتيجي ۾، هي واقعو ClickHouse-آپريٽر وٽ آيو. آپريٽر هن وضاحت حاصل ڪئي. ۽ هن کي ڪجهه ڪرڻو آهي. جيڪڏهن هڪ تازه ڪاري آئي ClickHouseInstallation اعتراض تي، پوء توهان کي ڪلستر کي اپڊيٽ ڪرڻ جي ضرورت آهي. ۽ آپريٽر جو ڪم ڪلستر کي اپڊيٽ ڪرڻ آهي.
هي ڇا ڪري رهيو آهي؟ پهرين، اسان کي هڪ ايڪشن پلان ٺاهڻ جي ضرورت آهي ته اسان هن تازه ڪاري سان ڇا ڪنداسين. تازه ڪاريون تمام ننڍيون ٿي سگهن ٿيون، يعني. YAML عمل ۾ ننڍو، پر ڪلستر تي تمام وڏي تبديلين جي ڪري سگھي ٿو. تنهن ڪري، آپريٽر هڪ منصوبو ٺاهي ٿو، ۽ پوء هو ان تي عمل ڪري ٿو.
هو شروع ڪري ٿو، هن منصوبي جي مطابق، هن ڍانچي کي اندر جوڙڻ لاءِ ته جيئن پوڊ، خدمتون، يعني. ان جو بنيادي ڪم ڇا ڪرڻ لاء. اهو ڪبرنيٽس ۾ ڪلڪ هاؤس ڪلستر جي تعمير وانگر آهي.
هاڻي اچو ته اهڙي دلچسپ شيء تي رابطو ڪريو. هي Kubernetes ۽ آپريٽر جي وچ ۾ ذميواري جو هڪ ڀاڱو آهي، يعني. ڪبرنيٽس ڇا ڪندو آهي، آپريٽر ڇا ڪندو آهي، ۽ اهي هڪ ٻئي سان ڪيئن لهه وچڙ ۾ ايندا آهن.
Kubernetes سسٽم شين لاء ذميوار آهي، يعني. شين جي هڪ بنيادي سيٽ لاءِ جنهن کي نظام جي دائري جي طور تي تشريح ڪري سگهجي ٿو. ڪبرنيٽس ڄاڻي ٿو ته پوڊس کي ڪيئن شروع ڪجي، ڪنٽينرز کي ڪيئن ٻيهر شروع ڪجي، مائونٽ حجم ڪيئن ڪجي، ConfigMap سان ڪيئن ڪم ڪجي، يعني. هر شيءِ جنهن کي سسٽم چئي سگهجي ٿو.
آپريٽرز موضوع جي علائقن ۾ ڪم ڪن ٿا. هر آپريٽر پنهنجي موضوع واري علائقي لاءِ ٺاهيو ويو آهي. اسان ڪلڪ ڪيو هائوس لاءِ ٺاهيو.
۽ آپريٽر موضوع واري علائقي جي لحاظ کان خاص طور تي رابطو ڪري ٿو، جهڙوڪ هڪ نقل شامل ڪرڻ، هڪ اسڪيم ٺاهڻ، مانيٽرنگ قائم ڪرڻ. اهڙي جدائي آهي.
اچو ته هڪ عملي مثال تي نظر رکون ته ڪيئن خدشات جي هي علحدگي ٿيندي آهي جڏهن اسان هڪ اضافو ريپليڪا عمل ڪندا آهيون.
ڪم آپريٽر ڏانهن اچي ٿو - هڪ نقل شامل ڪرڻ لاء. آپريٽر ڇا ڪري رهيو آهي؟ آپريٽر حساب ڪندو ته اهو ضروري آهي ته هڪ نئون StatefulSet ٺاهيو وڃي، جنهن ۾ اهڙيون ۽ اهڙيون ٽيمپليٽس، حجم جي دعويٰ بيان ڪرڻ ضروري آهي.
هن اهو سڀ تيار ڪيو ۽ ان کي K8s ڏانهن منتقل ڪيو. هو چوي ٿو ته هن کي ضرورت آهي ConfigMap، StatefulSet، Volume. Kubernetes ڪم ڪري رهيو آهي. هو بنيادي يونٽن کي مادي بڻائي ٿو جنهن سان هو هلائي ٿو.
۽ پوءِ ڪلڪ هائوس آپريٽر وري راند ۾ اچي ٿو. هن وٽ اڳ ۾ ئي هڪ جسماني پوڊ آهي جنهن تي توهان اڳ ۾ ئي ڪجهه ڪري سگهو ٿا. ۽ ClickHouse-operator وري ڪم ڪري ٿو موضوع جي لحاظ کان. اهي. خاص طور تي، ڪلڪ هاؤس، ڪلستر ۾ نقل شامل ڪرڻ لاءِ، توھان کي، پھريائين، ھن ڪلستر ۾ موجود ڊيٽا اسڪيم کي ترتيب ڏيڻ گھرجي. ۽، ٻيو، هي تبصرو مانيٽرنگ ۾ شامل ڪيو وڃي ته جيئن اهو واضح طور تي ڳولي سگهجي. آپريٽر اڳ ۾ ئي ان کي ترتيب ڏئي ٿو.
۽ صرف ان کان پوءِ ڪلڪ هائوس پاڻ راند ۾ اچي ٿو، يعني. ٻيو اعلي سطحي ادارو. اهو اڳ ۾ ئي هڪ ڊيٽابيس آهي. ان جو پنهنجو مثال آهي، ايندڙ ترتيب ڏنل نقل، جيڪو ڪلستر ۾ شامل ٿيڻ لاءِ تيار آهي.
اهو ظاهر ٿئي ٿو ته عمل جي زنجير ۽ ذميواري جي الڳ ٿيڻ جڏهن هڪ نقل شامل ڪرڻ ڪافي ڊگهو آهي.
اسان پنهنجي عملي ڪم کي جاري رکون ٿا. جيڪڏهن ڪلستر اڳ ۾ ئي موجود آهي، ته پوء توهان ترتيب کي لڏپلاڻ ڪري سگهو ٿا.
اسان ان کي ٺاهيو ته جيئن موجوده xml ذريعي منتقل ٿيڻ ممڪن آهي، جنهن کي ClickHouse سمجهي ٿو.
توھان ڪلڪ ڪري سگھوٿا ڪلڪ هائوس. صرف زون ٿيل تعیناتي اها آهي جنهن بابت مون ڳالهايو هوسٽ پاٿ، مقامي اسٽوريج جي وضاحت ڪرڻ وقت. اهو آهي ته ڪيئن صحيح طور تي زون جي ترتيب ڏيڻ.
ايندڙ عملي ڪم مانيٽرنگ آهي.
جيڪڏهن اسان جو ڪلستر تبديل ٿئي ٿو، پوء اسان کي وقتي طور تي نگراني کي ترتيب ڏيڻ جي ضرورت آهي.
اچو ته ڊائريگرام تي هڪ نظر وجهون. اسان هتي اڳ ۾ ئي سائي تير تي غور ڪيو آهي. هاڻي اچو ته ڳاڙهي تيرن کي ڏسو. هي آهي اسان پنهنجي ڪلستر جي نگراني ڪرڻ چاهيون ٿا. ڪلڪ هاؤس ڪلستر مان ميٽرڪ ڪيئن حاصل ٿئي ٿو پروميٿيس ۾، ۽ پوءِ گرافانا ۾.
مانيٽرنگ ۾ ڪهڙو مسئلو آهي؟ ان کي ڪنهن قسم جي حاصلات جي طور تي ڇو پيش ڪيو وڃي ٿو؟ ڏکيائي متحرڪ ۾ آهي. جڏهن اسان وٽ هڪ ڪلستر آهي ۽ اهو جامد آهي، ته پوء توهان هڪ ڀيرو مانيٽرنگ قائم ڪري سگهو ٿا ۽ وڌيڪ پريشان نه ڪريو.
پر جيڪڏهن اسان وٽ ڪيترائي ڪلستر آهن، يا ڪا شيء مسلسل تبديل ٿي رهي آهي، پوء اهو عمل متحرڪ آهي. ۽ مسلسل نگراني کي ٻيهر ترتيب ڏيڻ وسيلن ۽ وقت جو ضايع آهي. جيتوڻيڪ صرف سست. اهو خودڪار ٿيڻ جي ضرورت آهي. مشڪل عمل جي متحرڪ ۾ آهي. ۽ آپريٽر اهو تمام سٺو خودڪار ڪري ٿو.
اسان جي ڪلستر ڪيئن ترقي ڪئي؟ شروع شروع ۾ هو اهڙو هو.
پوءِ هو اهڙو هو.
آخر ۾، هو هن جهڙو ٿي ويو.
۽ نگراني خود بخود آپريٽر طرفان ڪيو ويندو آهي. داخلا جو واحد نقطو.
۽ اسان صرف گرافانا ڊيش بورڊ ۾ نڪرڻ تي ڏسون ٿا، ڪيئن اسان جي ڪلستر جي زندگي اندر جوش آهي.
رستي جي ذريعي، گرافانا ڊيش بورڊ پڻ ورهايو ويو آهي اسان جي آپريٽر سان صحيح سورس ڪوڊ ۾. توهان ڳنڍي سگهو ٿا ۽ استعمال ڪري سگهو ٿا. هي اسڪرين شاٽ مون کي ڏنو ويو هو اسان جي DevOps پاران.
اسان اڳتي ڪٿي وڃڻ چاهيون ٿا؟ هي:
- ٽيسٽ آٽوميشن کي ترقي ڪريو. مکيه ڪم نئين نسخن جي خودڪار جاچ آهي.
- اسان پڻ واقعي چاهيون ٿا ZooKeeper سان انضمام کي خودڪار ڪرڻ. ۽ ZooKeeper-آپريٽر سان ضم ڪرڻ جو منصوبو. اهي. ZooKeeper لاءِ هڪ آپريٽر لکيو ويو آهي، ۽ اهو منطقي آهي ته ٻه آپريٽر هڪ وڌيڪ آسان حل ٺاهڻ لاءِ ضم ٿيڻ شروع ڪن.
- اسان وڌيڪ پيچيده زندگي جي چڪاس ڪرڻ چاهيون ٿا.
- مون سائي رنگ ۾ نمايان ڪئي ته اسان وٽ رستي ۾ ٽيمپليٽ وراثت آهي - ٿي چڪو آهي، يعني آپريٽر جي ايندڙ رليز سان، اسان وٽ اڳ ۾ ئي ٽيمپليٽ جي ورثي هوندي. هي هڪ طاقتور اوزار آهي جيڪو توهان کي ٽڪرن مان پيچيده ترتيب ٺاهڻ جي اجازت ڏئي ٿو.
- ۽ اسان پيچيده ڪمن کي خودڪار ڪرڻ چاهيون ٿا. مکيه هڪ آهي Re-shading.
اچو ته ڪجهه وچڙندڙ نتيجا ڏيو.
ان جي نتيجي ۾ اسان کي ڇا حاصل آهي؟ ۽ اهو ان جي لائق آهي يا نه؟ ڇا مون کي به ڪوشش ڪرڻ جي ضرورت آهي ڊيٽابيس کي ڪبرنيٽس ۾ ڇڪڻ ۽ لاڳو ڪرڻ لاءِ عام طور تي آپريٽر ۽ خاص طور تي Alitnity آپريٽر.
پيداوار تي اسان حاصل ڪريون ٿا:
- ڊرامائي طور تي آسان ۽ خودڪار ترتيب ڏيڻ، ترتيب ڏيڻ، ۽ سار سنڀال.
- فوري طور تي تعمير ٿيل نگراني.
- ۽ پيچيده حالتن لاءِ استعمال لاءِ تيار ڪيل ڪوڊ ٿيل ٽيمپليٽس. اڳ ۾ ئي قسم جو عمل هڪ نقل شامل ڪرڻ لاء هٿ سان ڪرڻ جي ضرورت ناهي. اهو آپريٽر طرفان ڪيو ويندو آهي.
صرف آخري سوال رهي ٿو. اسان وٽ اڳ ۾ ئي هڪ ڊيٽابيس آهي Kubernetes، ورچوئلائيزيشن. اهڙي حل جي ڪارڪردگي بابت ڇا، خاص طور تي ڪلڪ هائوس ڪارڪردگي لاء بهتر ڪيو ويو آهي؟
جواب اهو آهي ته سڀ ڪجهه ٺيڪ آهي! مان تفصيل سان بيان نه ڪندس، هي هڪ الڳ رپورٽ جو موضوع آهي.
پر اتي TSBS وانگر هڪ منصوبو آهي. ان جو بنيادي ڪم ڇا آهي؟ هي هڪ ڊيٽابيس ڪارڪردگي ٽيسٽ آهي. هي هڪ ڪوشش آهي ته گرم سان گرم، نرم سان نرم.
هو ڪيئن ڪم ڪندو آهي؟ ڊيٽا جو ھڪڙو سيٽ ٺاھيو ويو آھي. پوءِ هي ڊيٽا سيٽ هڪ ئي ٽيسٽ سيٽ تي مختلف ڊيٽابيس تي هلائي ويندي آهي. ۽ هر ڊيٽابيس هڪ مسئلو حل ڪري ٿو طريقي سان اهو ڪري سگهي ٿو. ۽ پوء توهان نتيجن جي مقابلي ڪري سگهو ٿا.
اهو پهريان ئي ڊيٽابيس جي هڪ وڏي گروپ کي سپورٽ ڪري ٿو. مون ٽن مکيه جي نشاندهي ڪئي آهي. هي:
- وقت جي حساب سان بي.
- InfluxDB.
- ڪلڪ هائوس.
هڪ مقابلو پڻ ڪيو ويو هڪ ٻئي ساڳئي حل سان. RedShift سان مقابلو. مقابلو Amazon تي ڪيو ويو. ڪلڪ هاؤس پڻ هن معاملي ۾ سڀني کان اڳتي آهي.
مون جيڪي چيو ان مان ڪهڙا نتيجا ڪڍي سگهجن ٿا؟
- ڪبرنيٽس ۾ ڊي بي ممڪن آهي. شايد، توهان ڪجھ به ڪري سگهو ٿا، پر عام طور تي اهو لڳي ٿو ته توهان ڪري سگهو ٿا. Kubernetes ۾ ClickHouse ضرور اسان جي آپريٽر جي مدد سان ممڪن آهي.
- آپريٽر عمل کي خودڪار ڪرڻ ۾ مدد ڪري ٿو ۽ حقيقت ۾ زندگي کي آسان بڻائي ٿو.
- ڪارڪردگي عام آهي.
- ۽، اهو اسان کي لڳي ٿو ته اهو ٿي سگهي ٿو ۽ استعمال ٿيڻ گهرجي.
اوپن سورس - اسان سان شامل ٿيو!
جيئن مون چيو، آپريٽر هڪ مڪمل طور تي اوپن سورس پراڊڪٽ آهي، تنهنڪري اهو تمام سٺو ٿيندو جيڪڏهن وڌ کان وڌ ماڻهن ان کي استعمال ڪيو. بلڪل ھاڻي ئي! اسان توهان سڀني لاء انتظار ڪري رهيا آهيون!
سڀني جي مهرباني!
توهان جا سوال
رپورٽ لاءِ مهرباني! منهنجو نالو Anton آهي. مان SEMrush مان آهيان. مان حيران آهيان ته لاگنگ سان ڇا ٿيو. اسان مانيٽرنگ بابت ٻڌون ٿا، پر لاگنگ بابت ڪجھ به نه، جيڪڏهن اسان سڄي ڪلستر بابت ڳالهايو. مثال طور، اسان وٽ هارڊويئر تي ڪلستر آهي. ۽ اسان مرڪزي لاگنگ استعمال ڪندا آهيون، اسان ان کي عام ڍير ۾ معياري طريقن سان گڏ ڪندا آهيون. ۽ پوءِ اتان اسان کي ڊيٽا ملي ٿي جيڪا اسان لاءِ دلچسپ آهي.
سٺو سوال، يعني لاگ ان ٽوڊو لسٽ ۾. اسان جو آپريٽر اڃا تائين خودڪار نٿو ڪري. اهو اڃا ترقي ڪري رهيو آهي، پروجيڪٽ اڃا تائين ڪافي نوجوان آهي. اسان لاگنگ جي ضرورت کي سمجهون ٿا. اهو پڻ هڪ اهم موضوع آهي. ۽ اهو شايد نگراني کان گهٽ اهم ناهي. پر عملدرآمد جي فهرست تي پهرين نگراني هئي. لاگنگ ٿيندي. قدرتي طور تي، اسان ڪلستر جي زندگيء جي سڀني شعبن کي خودڪار ڪرڻ جي ڪوشش ڪري رهيا آهيون. تنهن ڪري، جواب اهو آهي ته هن وقت آپريٽر، بدقسمتي سان، اهو نه ڄاڻيو ته اهو ڪيئن ڪجي، پر اهو منصوبن ۾ آهي، اسان اهو ڪنداسين. جيڪڏھن توھان شامل ٿيڻ چاھيو ٿا، ته درخواست ڪريو، مھرباني ڪري.
سلام! رپورٽ لاءِ مهرباني! مون وٽ هڪ معياري سوال آهي مسلسل حجم سان لاڳاپيل. جڏهن اسان هن آپريٽر سان ڪا ترتيب ٺاهيندا آهيون ته آپريٽر ڪيئن طئي ڪندو ته ڪهڙي نوڊ تي اسان وٽ ڪا ڊسڪ يا فولڊر آهي؟ اسان کي پهريان هن کي وضاحت ڪرڻ گهرجي ته، مهرباني ڪري، اسان جي ڪلڪ هاؤس کي انهن نوڊس تي رکي، جن وٽ ڊسڪ آهي؟
جيتري قدر مان سمجهان ٿو، اهو سوال مقامي اسٽوريج جو تسلسل آهي، خاص طور تي ان جو hostPath حصو. اهو سڄي سسٽم کي بيان ڪرڻ جهڙو آهي ته اهو ضروري آهي ته پوڊ کي بلڪل اهڙي ۽ اهڙي نوڊ تي لانچ ڪيو وڃي، جنهن تي اسان وٽ هڪ فزيڪل ڳنڍيل ڊسڪ آهي، جيڪا اهڙي ۽ اهڙي رستي تي نصب ٿيل آهي. هي هڪ مڪمل حصو آهي جنهن کي مون تمام سطحي طور تي ڇڪيو آهي، ڇاڪاڻ ته جواب ڪافي وڏو آهي.
مختصر ۾، اهو هن وانگر ڏسڻ ۾ اچي ٿو. يقينن، اسان کي انهن جلدن جو بندوبست ڪرڻ جي ضرورت آهي. هن وقت، مقامي اسٽوريج ۾ ڪابه متحرڪ روزي نه آهي، تنهن ڪري DevOps پاڻ کي ڊسڪ کي ڪٽڻ گهرجي، هتي اهي حجم آهن. ۽ انهن کي لازمي طور تي وضاحت ڪرڻ گهرجي Kubernetes provisioning، ته توهان وٽ اهڙي ۽ اهڙي طبقي جا مستقل حجم هوندا، جيڪي اهڙي ۽ اهڙي نوڊس تي واقع آهن. پوءِ اهو ضروري ٿيندو ته ڪبرنيٽس کي وضاحت ڪرڻ گهرجي ته پوڊز جن کي اهڙي ۽ اهڙي مقامي اسٽوريج ڪلاس جي ضرورت هوندي آهي انهن کي ليبل جي مطابق شيڊول ڪرڻ جي ضرورت آهي صرف اهڙن ۽ اهڙن نوڊس کي. انهن مقصدن لاء، آپريٽر کي ڪجهه قسم جي ليبل تفويض ڪرڻ جي صلاحيت آهي ۽ هڪ هر ميزبان مثال طور. ۽ اهو ظاهر ٿئي ٿو ته پوڊز ڪبرنيٽس طرفان روٽ ڪيا ويندا صرف نوڊس تي هلائڻ لاءِ جيڪي ضرورتن کي پورا ڪن ٿا ، ليبل ، سادي اصطلاحن ۾. ايڊمنسٽريٽر ليبل تفويض ڪن ٿا، هٿ سان ڊسڪ جو بندوبست ڪن ٿا. ۽ پوءِ اُها ماپي ٿي.
۽ صرف ٽيون اختيار مقامي ان کي ٿورو آسان ڪرڻ ۾ مدد ڪري ٿي. جيئن ته مون اڳ ۾ ئي زور ڏنو آهي، اهو سرنگ جو هڪ مشڪل ڪم آهي، جيڪو آخرڪار وڌ کان وڌ ڪارڪردگي حاصل ڪرڻ ۾ مدد ڪري ٿو.
ان سلسلي ۾ منهنجو هڪ ٻيو سوال آهي. ڪبرنيٽس کي اهڙيءَ طرح تصور ڪيو ويو هو ته اهو اسان لاءِ ڪو مسئلو ناهي ته اسان هڪ نوڊ وڃايو يا نه. ان صورت ۾ اسان کي ڇا ڪرڻ گهرجي جيڪڏهن اسان اهو نوڊ وڃائي ڇڏيو آهي جتي اسان وٽ شارڊ آهي؟
ها، ڪبرنيٽس اصل ۾ پوزيشن ڪئي وئي هئي ته اسان جي پوڊ سان اسان جو تعلق ڍورن وانگر آهي، پر هتي هر ڊسڪ هڪ پالتو جانور وانگر آهي. اتي هڪ اهڙو مسئلو آهي جنهن کي اسان صرف ان کي اڇلائي نٿا سگهون. ۽ ڪبرنيٽس جي ترقي ان طرف وڃي رهي آهي ته ان کي مڪمل طور تي رد ڪيل وسيلن جي طور تي فلسفيانه طور تي مڪمل طور تي علاج ڪرڻ ناممڪن آهي.
هاڻي هڪ عملي سوال. ڇا ڪجي جيڪڏهن توهان نوڊ وڃائي ڇڏيو جنهن تي ڊسڪ هئي؟ هتي مسئلو هڪ اعلي سطح تي حل ڪيو ويو آهي. ClickHouse جي صورت ۾، اسان وٽ نقل آهن جيڪي اعلي سطح تي ڪم ڪن ٿيون، يعني. ڪلڪ هائوس سطح تي.
طبيعت ڇا آهي؟ DevOps انهي کي يقيني بڻائڻ جو ذميوار آهي ته ڊيٽا گم نه آهي. اهو صحيح طريقي سان ترتيب ڏيڻ گهرجي ۽ انهي کي يقيني بڻائڻ گهرجي ته نقل هلندڙ آهي. ڪلڪ هاؤس جي سطح تي نقل ۾، ڊيٽا کي نقل ڪيو وڃي. هي اهو ڪم ناهي جيڪو آپريٽر حل ڪري ٿو. ۽ اهو ڪم نه آهي جيڪو ڪبرنيٽس پاڻ حل ڪري ٿو. هي ڪلڪ هائوس سطح تي آهي.
ڇا ڪجي جيڪڏهن توهان جي لوهه جي نوڊ بند ٿي وئي آهي؟ ۽ اهو ظاهر ٿئي ٿو ته اهو ضروري آهي ته ٻيو هڪ رکڻو پوندو، صحيح طور تي ڊسڪ کي منتقل ڪريو، ليبل لاڳو ڪريو. ۽ ان کان پوء، اها ضرورتن کي پورو ڪندي ته ان تي ڪبرنيٽس هڪ پوڊ مثال هلائي سگهي ٿو. Kubernetes ان کي لانچ ڪندو. توهان جي پوڊ جو تعداد بيان ڪيل هڪ لاء ڪافي ناهي. اهو چڪر مان گذري ويندو جيڪو مون ڏيکاريو. ۽ بلند ترين سطح تي، ClickHouse سمجھندو ته اسان وٽ ھڪڙو نقل داخل ڪيو ويو آھي، اھو اڃا تائين خالي آھي ۽ اسان کي ان کي ڊيٽا منتقل ڪرڻ شروع ڪرڻ جي ضرورت آھي. اهي. اهو عمل اڃا تائين ناقص خودڪار آهي.
رپورٽ لاءِ مهرباني! جڏهن هر قسم جون خراب شيون ٿين ٿيون، آپريٽر حادثو ۽ ٻيهر شروع ٿئي ٿو، ۽ ان وقت واقعا پهچندا آهن، ڇا توهان ڪنهن طريقي سان عمل ڪندا آهيو؟
ڇا ٿيندو جيڪڏهن آپريٽر حادثو ۽ ٻيهر شروع ٿئي، ها؟
ها. ۽ ان وقت واقعا پيش آيا.
هن معاملي ۾ ڇا ڪرڻ جو ڪم جزوي طور آپريٽر ۽ Kubernetes جي وچ ۾ ورهايل آهي. ڪبرنيٽس وٽ هڪ واقعي کي ٻيهر هلائڻ جي صلاحيت آهي جيڪا واقع ٿي چڪي آهي. هو وري هلايو. ۽ آپريٽر جو ڪم اهو آهي ته انهي ڳالهه کي يقيني بڻائي ته جڏهن واقعي لاگ ان تي ٻيهر هلايو ويو، اهي واقعا ناقابل اعتبار آهن. ۽ انهي ڪري ته ساڳئي واقعي جو ٻيهر وقوع اسان لاءِ اسان جي نظام کي ٽوڙي نه وڃي. ۽ اسان جي آپريٽر هن ڪم سان copes.
سلام! رپورٽ لاءِ مهرباني! دمتري Zavialov، ڪمپني سميدوف. ڇا اهو آپريٽر کي haproxy سان ڪسٽمائيزيشن جا اختيار شامل ڪرڻ جي رٿابندي ڪئي وئي آهي؟ ڪجهه ٻيو بيلنس معياري کان علاوه دلچسپ آهي، انهي ڪري اهو هوشيار آهي ۽ سمجهي ٿو ته ڪلڪ هائوس اتي حقيقي آهي.
ڇا توهان Ingress جي باري ۾ ڳالهائي رهيا آهيو؟
ها، هاپروڪسي سان Ingress کي تبديل ڪريو. haproxy ۾، توھان وضاحت ڪري سگھو ٿا ڪلستر ٽوپولوجي جتي ان ۾ replicas آھن.
هينئر تائين، اسان ان بابت نه سوچيو آهي. جيڪڏھن توھان کي ضرورت آھي ۽ وضاحت ڪري سگھوٿا ته ان جي ضرورت ڇو آھي، پوءِ ان کي لاڳو ڪرڻ ممڪن ٿيندو، خاص ڪري جيڪڏھن توھان حصو وٺڻ چاھيو ٿا. اسان کي اختيار تي غور ڪرڻ لاء خوش ٿي ويندي. مختصر جواب نه آهي، اسان وٽ في الحال اهڙي ڪارڪردگي نه آهي. ٽپ لاءِ مهرباني، اسان هن تي هڪ نظر وجهنداسين. ۽ جيڪڏھن توھان پڻ وضاحت ڪريو استعمال ڪيس ۽ اھو عملي طور تي ڇو ضروري آھي، مثال طور، GitHub تي مسئلا ٺاھيو، پوء اھو وڏو ٿيندو.
اڳ ۾ ئي آهي.
ٺيڪ. اسان ڪنهن به تجويز لاء کليل آهيون. ۽ haproxy todo لسٽ تي رکيل آهي. ٽوڊو لسٽ وڌي رهي آهي، اڃا گهٽجي نه ٿي. پر اهو سٺو آهي، ان جو مطلب آهي ته پيداوار جي طلب ۾ آهي.
جو ذريعو: www.habr.com