موڪلون ختم ٿي ويون آهن ۽ اسان واپس آيا آهيون اسان جي ٻئي پوسٽ سان Istio سروس ميش سيريز ۾.
اڄ جو موضوع آهي سرڪٽ بريڪر، جنهن جو روسي اليڪٽريڪل انجنيئرنگ ۾ ترجمو ڪيو ويو آهي ”سرڪٽ بريڪر“، عام اصطلاح ۾ - ”سرڪٽ بريڪر“. صرف Istio ۾ هي مشين هڪ شارٽ يا اوورلوڊ ٿيل سرڪٽ کي ختم نٿو ڪري، پر ناقص ڪنٽينرز.
اهو ڪيئن مثالي طور ڪم ڪرڻ گهرجي
جڏهن مائيڪرو سروسز ڪبرنيٽس پاران منظم ڪيون وينديون آهن، مثال طور OpenShift پليٽ فارم جي اندر، اهي خودڪار طريقي سان ماپ ڪري وڌندا آهن ۽ لوڊ جي لحاظ کان هيٺ. ڇاڪاڻ ته مائڪرو سروسز پوڊز ۾ هلن ٿيون، اتي هڪ ڪنٽينر ٿيل مائڪرو سروسز جا ڪيترائي مثال ٿي سگهن ٿا هڪ آخري پوائنٽ تي، ۽ ڪبرنيٽس انهن جي وچ ۾ درخواستن ۽ لوڊ بيلنس کي روٽ ڪندا. ۽ - مثالي - اهو سڀ ڪجهه مڪمل طور تي ڪم ڪرڻ گهرجي.
اسان کي ياد آهي ته microservices ننڍا ۽ عارضي آهن. Ephemerality، جنهن جو هتي مطلب آهي ظاهر ٿيڻ ۽ غائب ٿيڻ جي آسانيءَ جو، اڪثر ڪري گهٽ اندازو لڳايو ويندو آهي. پوڊ ۾ مائڪرو سروس جي هڪ ٻي مثال جي پيدائش ۽ موت ڪافي متوقع شيون آهن، OpenShift ۽ Kubernetes ان کي چڱي طرح سنڀاليندا آهن، ۽ هر شي تمام سٺو ڪم ڪري ٿو - پر ٻيهر نظريي ۾.
اهو ڪيئن واقعي ڪم ڪري ٿو
ھاڻي تصور ڪريو ته ھڪڙي مائيڪرو سروس جو ھڪڙو خاص مثال، اھو آھي، ھڪڙو ڪنٽينر، ناقابل استعمال ٿي ويو آھي: يا ته اھو جواب نٿو ڏئي (غلطي 503)، يا، جيڪو وڌيڪ ناپسنديده آھي، اھو جواب ڏئي ٿو، پر تمام سست. ٻين لفظن ۾، اهو گليچي ٿئي ٿو يا درخواستن جو جواب نٿو ڏئي، پر اهو خودڪار طور تي تلاء مان نه هٽايو ويو آهي. هن معاملي ۾ ڇا ڪرڻ گهرجي؟ ٻيهر ڪوشش ڪرڻ لاء؟ ڇا مان ان کي روٽنگ اسڪيم مان هٽائي ڇڏيان؟ ۽ ڇا مطلب آهي "تمام سست" جو مطلب آهي - اهو تعداد ۾ ڪيترو آهي، ۽ ڪير انهن کي طئي ڪري ٿو؟ ٿي سگهي ٿو اهو صرف هڪ وقفو ڏيو ۽ بعد ۾ ٻيهر ڪوشش ڪريو؟ جيڪڏهن ائين آهي، ڪيترو دير بعد؟
Istio ۾ پول Ejection ڇا آهي
۽ هتي Istio پنهنجي سرڪٽ برڪر تحفظ واري مشينن سان بچاءُ ۾ اچي ٿو، جيڪي عارضي طور تي ناقص ڪنٽينرز کي روٽنگ ۽ لوڊ بيلنس ريسورس پول مان هٽائي، پول Ejection جي طريقيڪار تي عمل ڪندي.
هڪ ٻاهرئين پتو لڳائڻ واري حڪمت عملي کي استعمال ڪندي، Istio وکر پوڊ کي ڳولي ٿو جيڪي لائن کان ٻاهر آهن ۽ انهن کي وسيلن جي تلاء مان هڪ مخصوص وقت لاء هٽائي ٿو، جنهن کي ننڊ ونڊو سڏيو ويندو آهي.
اهو ڏيکارڻ لاءِ ته اهو ڪيئن ڪم ڪري ٿو Kubernetes ۾ OpenShift پليٽ فارم تي، اچو ته شروع ڪريون هڪ اسڪرين شاٽ سان عام طور تي ڪم ڪندڙ مائڪرو سروسز جي مثال مان مخزن ۾ . هتي اسان وٽ ٻه پوڊ آهن، v1 ۽ v2، هر هڪ هلائيندڙ هڪ ڪنٽينر. جڏهن Istio روٽنگ ضابطا استعمال نه ڪيا ويا آهن، Kubernetes ڊفالٽ برابر متوازن گول رابن روٽنگ ڏانهن:
ناڪامي جي تياري
Pool Ejection ڪرڻ کان پهريان، توهان کي هڪ Istio روٽنگ قاعدو ٺاهڻ جي ضرورت آهي. اچو ته چئو ته اسان پوڊ جي وچ ۾ 50/50 جي تناسب ۾ درخواستون ورهائڻ چاهيون ٿا. اضافي طور تي، اسان v2 ڪنٽينرز جو تعداد وڌائينداسين ھڪڙي کان ٻن تائين، جھڙوڪ:
oc scale deployment recommendation-v2 --replicas=2 -n tutorial
ھاڻي اسان ھڪڙي رستي جو قاعدو مقرر ڪيو آھي ته جيئن ٽرئفڪ کي 50/50 جي تناسب ۾ پوڊ جي وچ ۾ ورهايو وڃي.
ھتي اھو آھي جيڪو ھن قاعدي جو نتيجو ڏسڻ ۾ اچي ٿو:
توهان حقيقت ۾ غلطي ڳولي سگهو ٿا ته هي اسڪرين 50/50 نه، پر 14:9 آهي، پر وقت سان گڏ صورتحال بهتر ٿيندي.
خرابي ڪرڻ
ھاڻي اچو ته ٻن v2 ڪنٽينرن مان ھڪڙي کي غير فعال ڪريون ته جيئن اسان وٽ ھڪڙو صحتمند v1 ڪنٽينر، ھڪڙو صحتمند v2 ڪنٽينر ۽ ھڪڙو ناقص v2 ڪنٽينر آھي.
خرابي کي درست ڪرڻ
تنهن ڪري، اسان وٽ هڪ ناقص ڪنٽينر آهي، ۽ اهو پول ايجڪشن جو وقت آهي. هڪ تمام سادي ترتيب استعمال ڪندي، اسان هن ناڪام ڪنٽينر کي ڪنهن به روٽنگ اسڪيمن مان 15 سيڪنڊن لاءِ خارج ڪري ڇڏينداسين اميد ته اهو هڪ صحتمند حالت ڏانهن موٽندو (يا ته ٻيهر شروع يا ڪارڪردگي بحال). هي اهو آهي جيڪو هن ترتيب وانگر ڏسڻ ۾ اچي ٿو ۽ ان جي ڪم جا نتيجا:
جئين توهان ڏسي سگهو ٿا، ناڪام v2 ڪنٽينر هاڻي روٽنگ جي درخواستن لاءِ استعمال نه ڪيو ويو آهي ڇاڪاڻ ته اهو پول مان هٽايو ويو آهي. پر 15 سيڪنڊن کان پوء، اهو خودڪار طريقي سان تلاء ڏانهن موٽندو. دراصل، اسان صرف ڏيکاريو ته ڪيئن پول Ejection ڪم ڪري ٿو.
اچو ته تعميراتي فن تعمير شروع ڪريون
پول Ejection، Istio جي نگراني جي صلاحيتن سان گڏ، توهان کي خودڪار طور تي ناقص ڪنٽينرز کي تبديل ڪرڻ لاء هڪ فريم ورڪ ٺاهڻ شروع ڪرڻ جي اجازت ڏئي ٿو، جيڪڏهن ختم نه ڪيو وڃي، ختم ٿيڻ ۽ ناڪامي.
ناسا وٽ ھڪڙو بلند آواز آھي - ناڪامي ھڪڙو اختيار نه آھي، جنھن جو مصنف سمجھيو ويندو آھي فلائيٽ ڊائريڪٽر . اهو روسي ۾ ترجمو ڪري سگهجي ٿو "ناڪامي هڪ آپشن ناهي،" ۽ مطلب هتي اهو آهي ته هر شي ڪم ڪري سگهجي ٿي جيڪڏهن توهان وٽ ڪافي خواهش آهي. بهرحال، حقيقي زندگي ۾، ناڪامي صرف نه ٿينديون آهن، اهي ناگزير آهن، هر جڳهه ۽ هر شيء ۾. ۽ ڪيئن microservices جي صورت ۾ انھن سان ڊيل ڪرڻ لاء؟ اسان جي راء ۾، اهو بهتر آهي ته انحصار ڪرڻ جي طاقت تي نه، پر ڪنٽينرز جي صلاحيتن تي، , ۽ .
Istio، جيئن اسان مٿي لکيو آهي، سرڪٽ برڪرز جي تصور کي لاڳو ڪري ٿو، جيڪو پاڻ کي جسماني دنيا ۾ سٺو ثابت ڪيو آهي. ۽ جيئن ته هڪ برقي سرڪٽ بريڪر هڪ سرڪٽ جي هڪ مسئلي واري حصي کي بند ڪري ٿو، Istio جو سافٽ ويئر سرڪٽ بريڪر درخواستن جي هڪ وهڪرو ۽ هڪ مسئلو ڪنٽينر جي وچ ۾ ڪنيڪشن کي کوليندو آهي جڏهن ڪجهه ختم ٿيڻ واري نقطي سان غلط آهي، مثال طور، جڏهن سرور حادثو ٿيو يا شروع ڪيو. آهستي ڪريو.
ان کان علاوه، ٻئي صورت ۾ صرف وڌيڪ مسئلا آهن، ڇاڪاڻ ته هڪ ڪنٽينر جي برڪ نه رڳو ان جي رسائي جي خدمتن ۾ دير جو سبب بڻجن ٿا ۽ نتيجي طور، مجموعي طور تي سسٽم جي ڪارڪردگي کي گھٽائي ٿو، پر بار بار پيدا ڪري ٿو. اڳ ۾ ئي سست هلندڙ سروس جي درخواست، جيڪا صرف صورتحال کي وڌائي ٿي.
نظريي ۾ سرڪٽ برڪر
سرڪٽ برڪر هڪ پراکسي آهي جيڪو آخري پوائنٽ ڏانهن درخواستن جي وهڪري کي سنڀاليندو آهي. جڏهن اهو نقطو ڪم ڪرڻ بند ڪري ٿو يا، مقرر ڪيل سيٽنگن تي منحصر ڪري ٿو، سست ٿيڻ شروع ٿئي ٿو، پراکسي ڪنٽينر سان ڪنيڪشن کي ٽوڙي ٿو. ٽريفڪ وري ٻين ڪنٽينرن ڏانهن منتقل ڪئي وئي آهي، صرف لوڊ بيلنسنگ جي ڪري. ڪنيڪشن هڪ ڏنل ننڊ ونڊو لاءِ کليل رهي ٿو، ٻه منٽ چئو، ۽ پوءِ اڌ کليل سمجهي وڃي ٿو. ايندڙ درخواست موڪلڻ جي ڪوشش ڪنيڪشن جي وڌيڪ حالت کي طئي ڪري ٿي. جيڪڏهن خدمت سان سڀ ڪجهه ٺيڪ آهي، ڪنيڪشن ڪم ڪندڙ حالت ڏانهن موٽندو ۽ ٻيهر بند ٿي ويندو. جيڪڏهن خدمت ۾ اڃا به ڪجهه غلط آهي، ڪنيڪشن ختم ٿي وئي آهي ۽ ننڊ ونڊو ٻيهر چالو ڪيو ويو آهي. هتي اهو آهي ته هڪ آسان سرڪٽ برڪر اسٽيٽ ڊراگرام وانگر نظر اچي ٿو:
هتي اهو نوٽ ڪرڻ ضروري آهي ته اهو سڀ ڪجهه سطح تي ٿئي ٿو، تنهنڪري ڳالهائڻ لاء، سسٽم فن تعمير. تنهن ڪري ڪجهه نقطي تي توهان کي پنهنجي ايپليڪيشنن کي سرڪٽ بريڪر سان ڪم ڪرڻ سيکارڻو پوندو، جيئن جواب ۾ ڊفالٽ قيمت مهيا ڪرڻ يا، جيڪڏهن ممڪن هجي، خدمت جي وجود کي نظر انداز ڪرڻ. هن لاءِ هڪ بلڪ هيڊ جو نمونو استعمال ڪيو ويو آهي، پر اهو هن مضمون جي دائري کان ٻاهر آهي.
عملي طور تي سرڪٽ برڪر
مثال طور، اسان OpenShift تي اسان جي تجويز ڪيل microservice جا ٻه نسخا هلائينداسين. نسخو 1 ٺيڪ ڪم ڪندو، پر v2 ۾ اسان دير سان تعمير ڪنداسين سرور تي سست رفتار کي ترتيب ڏيڻ لاء. نتيجن کي ڏسڻ لاء، اوزار استعمال ڪريو :
siege -r 2 -c 20 -v customer-tutorial.$(minishift ip).nip.io
هر شي ڪم ڪرڻ لڳي، پر ڪهڙي قيمت تي؟ پهرين نظر ۾، اسان وٽ 100٪ دستياب آهي، پر هڪ ويجهي نظر وٺو - وڌ ۾ وڌ ٽرانزيڪشن جي مدت 12 سيڪنڊن جيتري آهي. اهو واضح طور تي هڪ رڪاوٽ آهي ۽ وڌائڻ جي ضرورت آهي.
هن کي ڪرڻ لاء، اسان استعمال ڪنداسين Istio ڪالن کي ختم ڪرڻ لاء سست ڪنٽينرز ڏانهن. هي اهو آهي جيڪو لاڳاپيل ترتيب سرڪٽ برڪر استعمال ڪرڻ وانگر ڏسڻ ۾ اچي ٿو:
httpMaxRequestsPerConnection پيٽرولر سان آخري لڪير اشارو ڏئي ٿي ته ڪنيڪشن ختم ٿيڻ گهرجي جڏهن ٻيو - ٻيو - ڪنيڪشن ٺاهڻ جي ڪوشش ڪئي وڃي موجوده هڪ کان علاوه. جيئن ته اسان جو ڪنٽينر هڪ سست خدمت ٺاهي ٿو، اهڙيون حالتون وقتي طور تي پيدا ٿينديون آهن، ۽ پوء Istio هڪ 503 غلطي واپس آڻيندو، پر اهو آهي جيڪو محاصرو ڏيکاريندو:
ٺيڪ، اسان وٽ سرڪٽ بريڪر آهي، اڳتي ڇا آهي؟
تنهن ڪري، اسان پاڻمرادو بند لاڳو ڪيو بغير ڪنهن به خدمتن جي ماخذ ڪوڊ کي ڇڪڻ کان سواءِ. مٿي بيان ڪيل سرڪٽ بريڪر ۽ پول ايجڪشن جي طريقيڪار کي استعمال ڪندي، اسان وسيلن جي تلاءَ مان بريڪ ڪنٽينرز کي هٽائي سگھون ٿا جيستائين اهي معمول تي نه اچن، ۽ انهن جي حالت کي مخصوص تعدد تي چيڪ ڪريو - اسان جي مثال ۾، هي ٻه منٽ آهي (ننڊ ونڊو پيٽرولر).
نوٽ ڪريو ته 503 غلطي جو جواب ڏيڻ جي ايپليڪيشن جي صلاحيت اڃا تائين ماخذ ڪوڊ جي سطح تي مقرر ڪئي وئي آهي. سرڪٽ برڪر استعمال ڪرڻ لاء ڪيتريون ئي حڪمت عمليون آھن، صورتحال تي منحصر آھي.
ايندڙ پوسٽ ۾: اسان ان ٽريڪنگ ۽ مانيٽرنگ جي باري ۾ ڳالهائينداسين جيڪو اڳ ۾ ئي ٺهيل آهي يا آساني سان Istio ۾ شامل ڪيو ويو آهي، انهي سان گڏ ڪيئن ارادي سان سسٽم ۾ غلطيون متعارف ڪرايون وڃن.
جو ذريعو: www.habr.com