ڪبرنيٽس ٽوٽڪا ۽ ترڪيبون: NGINX ۽ PHP-FPM ۾ شاندار بند جون خاصيتون

ڪبرنيٽس ۾ CI/CD لاڳو ڪرڻ وقت هڪ عام حالت: ايپليڪيشن کي لازمي طور تي مڪمل طور تي بند ٿيڻ کان اڳ نون ڪلائنٽ جي درخواستن کي قبول نه ڪرڻ جي قابل هجڻ گهرجي، ۽ سڀ کان اهم، ڪاميابيءَ سان موجوده درخواستن کي مڪمل ڪري.

هن شرط جي تعميل توهان کي اجازت ڏئي ٿي ته توهان مقرري دوران صفر ختم وقت حاصل ڪري سگهو ٿا. جڏهن ته، جيتوڻيڪ جڏهن تمام مشهور بنڊل استعمال ڪري رهيا آهن (جهڙوڪ NGINX ۽ PHP-FPM)، توهان مشڪلاتن کي منهن ڏئي سگهو ٿا جيڪي هر مقرري سان غلطين جو اضافو ٿيندو ...

نظريو. پوڊ ڪيئن زندگي گذاريندو آهي

اسان اڳ ۾ ئي پوڊ جي زندگي جي چڪر بابت تفصيل سان شايع ڪيو آهي اهو مضمون. هيٺ ڏنل موضوع جي حوالي سان، اسان کي هيٺين ۾ دلچسپي آهي: هن وقت جڏهن پوڊ رياست ۾ داخل ٿئي ٿو ختم ڪندي، نيون درخواستون ان ڏانهن موڪلڻ بند ٿيون (pod ختم ٿيل سروس جي آخري پوائنٽن جي فهرست مان). اهڙيء طرح، مقرري دوران بند ٿيڻ کان بچڻ لاء، اهو اسان لاء ڪافي آهي ته ايپليڪيشن کي صحيح طريقي سان روڪڻ جي مسئلي کي حل ڪرڻ لاء.

توهان کي اهو پڻ ياد رکڻ گهرجي ته ڊفالٽ فضل وارو دور آهي 30 سيڪنڊ: هن کان پوء، پوڊ کي ختم ڪيو ويندو ۽ ايپليڪيشن کي هن عرصي کان اڳ سڀني درخواستن تي عمل ڪرڻ جو وقت هجڻ گهرجي. ويچاري: جيتوڻيڪ ڪا به درخواست جيڪا 5-10 سيڪنڊن کان وڌيڪ وٺندي آهي اڳ ۾ ئي مسئلو آهي، ۽ شاندار بند هاڻي ان جي مدد نه ڪندو ...

بهتر سمجهڻ لاءِ ته ڇا ٿئي ٿو جڏهن هڪ پوڊ ختم ٿئي ٿو، صرف هيٺ ڏنل شڪل ڏسو:

A1، B1 - دل جي حالت بابت تبديليون حاصل ڪرڻ
A2 - روانگي SIGTERM
B2 - آخري پوائنٽن مان پوڊ کي هٽائڻ
B3 - تبديليون وصول ڪرڻ (آخري پوائنٽن جي فهرست تبديل ٿي وئي آهي)
B4 - iptables ضابطن کي اپڊيٽ ڪريو

مهرباني ڪري نوٽ ڪريو: آخري پوائنٽ پوڊ کي حذف ڪرڻ ۽ SIGTERM موڪلڻ تسلسل سان نه، پر متوازي طور تي. ۽ ان حقيقت جي ڪري ته Ingress فوري طور تي آخري پوائنٽن جي تازه ڪاري لسٽ حاصل نه ڪري، گراهڪن کان نئين درخواستون پوڊ ڏانهن موڪليا ويندا، جيڪا پوڊ ختم ٿيڻ دوران 500 غلطي جو سبب بڻجندي. (هن مسئلي تي وڌيڪ تفصيلي مواد لاء، اسان ترجمو). هن مسئلي کي هيٺين طريقن سان حل ڪرڻ جي ضرورت آهي:

• ڪنيڪشن موڪليو: جواب جي هيڊرن ۾ بند ڪريو (جيڪڏهن اهو هڪ HTTP ايپليڪيشن جو خدشو آهي).
• جيڪڏهن اهو ممڪن ناهي ته ڪوڊ ۾ تبديليون ڪرڻ، پوء هيٺ ڏنل آرٽيڪل هڪ حل بيان ڪري ٿو جيڪو توهان کي اجازت ڏيندو درخواستن تي عمل ڪرڻ جي آخري وقت تائين.

نظريو. ڪيئن NGINX ۽ PHP-FPM انهن جي عملن کي ختم ڪري ٿو

اين اين جي آء

اچو ته NGINX سان شروع ڪريون، ڇو ته هر شيء ان سان وڌيڪ يا گهٽ واضح آهي. نظريي ۾ ڊائيونگ ڪندي، اسان کي معلوم ٿئي ٿو ته NGINX وٽ ھڪڙو ماسٽر پروسيس آھي ۽ ڪيترائي "مزدور" - اھي ٻاراڻا عمل آھن جيڪي ڪلائنٽ جي درخواستن تي عمل ڪندا آھن. ھڪڙو آسان اختيار ڏنو ويو آھي: ڪمانڊ استعمال ڪندي nginx -s <SIGNAL> عمل کي ختم ڪريو يا ته فاسٽ شٽ ڊائون يا شاندار شٽ ڊائون موڊ ۾. ظاهر آهي، اهو آخري اختيار آهي جيڪو اسان جي فائدي ۾ آهي.

پوء سڀڪنھن شيء کي سادو آهي: توهان کي شامل ڪرڻ جي ضرورت آهي پري اسٽاپ-هڪ هڪ حڪم جيڪو هڪ شاندار بند سگنل موڪليندو. اهو ڪم ۾ ڪري سگهجي ٿو، ڪنٽينر بلاڪ ۾:

       lifecycle:
          preStop:
            exec:
              command:
              - /usr/sbin/nginx
              - -s
              - quit

هاڻي، جڏهن پوڊ بند ٿي ويندو آهي، اسان هيٺ ڏنل NGINX ڪنٽينر لاگز ۾ ڏسندا.

2018/01/25 13:58:31 [notice] 1#1: signal 3 (SIGQUIT) received, shutting down
2018/01/25 13:58:31 [notice] 11#11: gracefully shutting down

۽ اهو مطلب ٿيندو جيڪو اسان کي گهرجي: NGINX مڪمل ٿيڻ جي درخواستن جو انتظار ڪري ٿو، ۽ پوء عمل کي ماريندو آهي. بهرحال، هيٺ اسين هڪ عام مسئلي تي پڻ غور ڪنداسين، جنهن جي ڪري، حڪم سان پڻ nginx -s quit عمل غلط طور تي ختم ٿي ويندو.

۽ هن اسٽيج تي اسان NGINX سان ڪيو آهي: گهٽ ۾ گهٽ لاگز مان توهان سمجهي سگهو ٿا ته هر شي ڪم ڪري رهي آهي جيئن ان کي گهرجي.

PHP-FPM سان ڪهڙو معاملو آهي؟ اهو ڪيئن خوبصورت بند کي سنڀاليندو آهي؟ اچو ته ان جو اندازو لڳايو.

PHP-FPM

PHP-FPM جي صورت ۾، ٿورڙي ڄاڻ آهي. جيڪڏهن توهان تي ڌيان ڏيو سرڪاري دستور PHP-FPM جي مطابق، اهو چوندو ته هيٺيان POSIX سگنل قبول ڪيا ويا آهن:

1. SIGINT, SIGTERM - تڪڙو بند؛
2. SIGQUIT - شاندار بند (جيڪو اسان کي گهرجي).

باقي سگنل هن ڪم ۾ گهربل نه آهن، تنهنڪري اسان انهن جي تجزيو کي ختم ڪنداسين. صحيح طريقي سان عمل کي ختم ڪرڻ لاءِ، توھان کي ھيٺ ڏنل preStop ٿلهو لکڻ جي ضرورت پوندي.

        lifecycle:
          preStop:
            exec:
              command:
              - /bin/kill
              - -SIGQUIT
              - "1"

پهرين نظر ۾، اهو سڀ ڪجهه آهي جيڪو ٻنهي ڪنٽينرز ۾ شاندار بند ڪرڻ جي ضرورت آهي. بهرحال، ڪم وڌيڪ ڏکيو آهي ان کان وڌيڪ لڳي ٿو. هيٺيان ٻه ڪيس آهن جن ۾ شاندار بندش ڪم نه ڪيو ۽ ڊيپلائيشن دوران پروجيڪٽ جي مختصر مدت جي غير موجودگي سبب.

مشق. شاندار بند سان ممڪن مسئلا

اين اين جي آء

سڀ کان پهريان، اهو ياد رکڻ لاء مفيد آهي: حڪم تي عمل ڪرڻ کان علاوه nginx -s quit اتي ھڪڙو ٻيو مرحلو آھي جنھن تي ڌيان ڏيڻ جي قابل آھي. اسان کي هڪ مسئلو درپيش آهي جتي NGINX اڃا تائين SIGQUIT سگنل جي بدران SIGTERM موڪليندو، درخواستون صحيح طريقي سان مڪمل نه ٿيڻ سبب. اهڙا ڪيس ڳولي سگهجن ٿا، مثال طور، هتي. بدقسمتي سان، اسان هن رويي جي مخصوص سبب کي طئي ڪرڻ کان قاصر هئا: اين اين اينڪس نسخن بابت هڪ شڪ هو، پر ان جي تصديق نه ڪئي وئي هئي. علامه اهو هو ته پيغام NGINX ڪنٽينر لاگز ۾ ڏٺا ويا "اوپن ساکٽ # 10 ڪنيڪشن 5 ۾ ڇڏي ويو"، جنهن کان پوء پوڊ بند ٿي ويو.

اسان اهڙي مسئلي جو مشاهدو ڪري سگهون ٿا، مثال طور، Ingress تي ڏنل جوابن مان اسان کي ضرورت آهي:

مقرري جي وقت اسٽيٽس ڪوڊ جا اشارا

انهي صورت ۾، اسان صرف هڪ 503 غلطي ڪوڊ حاصل ڪريون ٿا Ingress کان: اهو NGINX ڪنٽينر تائين رسائي نٿو ڪري سگهي، ڇاڪاڻ ته اهو هاڻي دستياب ناهي. جيڪڏهن توهان NGINX سان ڪنٽينر لاگز تي نظر اچن ٿا، انهن ۾ هيٺيان شامل آهن:

[alert] 13939#0: *154 open socket #3 left in connection 16
[alert] 13939#0: *168 open socket #6 left in connection 13

اسٽاپ سگنل کي تبديل ڪرڻ کان پوء، ڪنٽينر صحيح طور تي بند ٿيڻ شروع ٿئي ٿو: هن حقيقت جي تصديق ڪئي وئي آهي ته 503 غلطي هاڻي نه ڏٺو ويو آهي.

جيڪڏهن توهان هڪجهڙائي واري مسئلي کي منهن ڏيو ٿا، اهو سمجهڻ جو احساس آهي ته ڪنٽينر ۾ ڪهڙو اسٽاپ سگنل استعمال ڪيو ويو آهي ۽ ڇا واقعي پري اسٽاپ ٿلهو ڏسڻ جهڙو آهي. اهو بلڪل ممڪن آهي ته ان جو سبب ان ۾ ئي آهي.

PHP-FPM... ۽ وڌيڪ

PHP-FPM سان مسئلو هڪ ننڍڙي انداز ۾ بيان ڪيو ويو آهي: اهو ٻار جي عملن جي مڪمل ٿيڻ جو انتظار نٿو ڪري، اهو انهن کي ختم ڪري ٿو، ڇو ته 502 غلطيون ڊيپلائيشن ۽ ٻين عملن دوران ٿينديون آهن. 2005 کان وٺي bugs.php.net تي ڪيتريون ئي بگ رپورٽون آهن (مثال طور هتي и هتي)، جيڪو هن مسئلي کي بيان ڪري ٿو. پر توهان گهڻو ڪري لاگز ۾ ڪجهه به نه ڏسندا: PHP-FPM بغير ڪنهن غلطي يا ٽئين پارٽي جي اطلاعن جي پنهنجي عمل جي مڪمل ٿيڻ جو اعلان ڪندو.

اهو واضح ڪرڻ جي قابل آهي ته مسئلو پاڻ کي ايپليڪيشن تي گهٽ يا وڏي حد تائين منحصر ڪري سگهي ٿو ۽ شايد پاڻ کي ظاهر نه ڪري سگھي، مثال طور، نگراني ۾. جيڪڏهن توهان ان کي منهن ڏيو ٿا، هڪ سادو ڪم ڪار پهريون ڀيرو ذهن ۾ اچي ٿو: شامل ڪريو هڪ پري اسٽاپ ٿلهو سان sleep(30). اهو توهان کي سڀني درخواستن کي مڪمل ڪرڻ جي اجازت ڏيندو جيڪي اڳ ۾ هيون (۽ اسان نئين قبول نه ڪندا آهيون، پوڊ کان وٺي اڳ ۾ ئي ڪرڻ جي لائق ختم ڪندي)، ۽ 30 سيڪنڊن کان پوء پوڊ پاڻ کي سگنل سان ختم ٿي ويندو SIGTERM.

اهو ظاهر ٿي ويو آهي lifecycle ڪنٽينر لاءِ هن طرح نظر ايندو:

    lifecycle:
      preStop:
        exec:
          command:
          - /bin/sleep
          - "30"

بهرحال، 30 سيڪنڊن جي ڪري sleep اسان آهيون گھڻو اسان مقرري جو وقت وڌائينداسين، ڇو ته هر پوڊ ختم ڪيو ويندو گهٽ ۾ گهٽ 30 سيڪنڊ، جيڪو خراب آهي. ان بابت ڇا ڪري سگهجي ٿو؟

اچو ته پارٽي ڏانهن رخ ڪريون جيڪي درخواست جي سڌي عمل جي ذميوار آهن. اسان جي صورت ۾ اهو آهي PHP-FPMته ڊفالٽ طور تي ان جي ٻار جي عمل جي عمل جي نگراني نٿو ڪري: ماسٽر پروسيس کي فوري طور تي ختم ڪيو ويو آهي. توھان ھدايت استعمال ڪندي ھن رويي کي تبديل ڪري سگھو ٿا process_control_timeout، جيڪو ماسٽر کان سگنلن جي انتظار ۾ ٻارن جي عملن لاءِ وقت جي حدن کي بيان ڪري ٿو. جيڪڏهن توهان قيمت کي 20 سيڪنڊن تي مقرر ڪيو ٿا، اهو ڪنٽينر ۾ هلندڙ اڪثر سوالن کي ڍڪيندو ۽ مڪمل ٿيڻ کان پوء ماسٽر پروسيس کي روڪي ڇڏيندو.

هن علم سان، اچو ته اسان جي آخري مسئلي ڏانهن موٽون. جيئن ذڪر ڪيو ويو آهي، ڪبرنيٽس هڪ واحد پليٽ فارم نه آهي: ان جي مختلف حصن جي وچ ۾ رابطي ۾ ڪجهه وقت وٺندو آهي. اهو خاص طور تي سچ آهي جڏهن اسان Ingresses ۽ ٻين لاڳاپيل حصن جي آپريشن تي غور ڪندا آهيون، ڇاڪاڻ ته تعیناتي جي وقت ۾ اهڙي دير جي ڪري 500 غلطين جو اضافو حاصل ڪرڻ آسان آهي. مثال طور، اپ اسٽريم ڏانهن درخواست موڪلڻ جي مرحلي ۾ هڪ غلطي ٿي سگهي ٿي، پر اجزاء جي وچ ۾ رابطي جو ”وقت جي وقفي“ ڪافي مختصر آهي - هڪ سيڪنڊ کان به گهٽ.

تنهن ڪري ڪل اڳ ۾ ئي ذڪر ڪيل هدايتن سان process_control_timeout توھان ھيٺ ڏنل تعمير استعمال ڪري سگھو ٿا lifecycle:

lifecycle:
  preStop:
    exec:
      command: ["/bin/bash","-c","/bin/sleep 1; kill -QUIT 1"]

انهي صورت ۾، اسان حڪم سان دير جي لاء معاوضي ڪنداسين sleep ۽ مقرري جي وقت کي تمام گهڻو نه وڌايو: ڇا 30 سيڪنڊن ۽ هڪ جي وچ ۾ هڪ قابل ذڪر فرق آهي؟ ... حقيقت ۾، اهو آهي process_control_timeout۽ lifecycle صرف وقف جي صورت ۾ "حفاظت نيٽ" طور استعمال ڪيو ويو.

عام طور تي ڳالهائڻ، بيان ڪيل رويي ۽ لاڳاپيل حل نه رڳو PHP-FPM تي لاڳو ٿين ٿا. ساڳي صورتحال هڪ طريقو يا ٻيو پيدا ٿي سگهي ٿو جڏهن ٻيون ٻوليون / فريم ورڪ استعمال ڪندي. جيڪڏهن توهان ٻين طريقن سان خوبصورت بندش کي درست نٿا ڪري سگهو - مثال طور، ڪوڊ کي ٻيهر لکڻ سان جيئن ته ايپليڪيشن صحيح طريقي سان ختم ٿيڻ جي سگنلن تي عمل ڪري - توهان بيان ڪيل طريقو استعمال ڪري سگهو ٿا. اهو سڀ کان وڌيڪ خوبصورت نه ٿي سگهي، پر اهو ڪم ڪري ٿو.

مشق. پوڊ جي آپريشن کي جانچڻ لاءِ لوڊ ٽيسٽ

لوڊ ٽيسٽنگ طريقن مان هڪ آهي جانچڻ جو ته ڪنٽينر ڪيئن ڪم ڪري ٿو، ڇو ته اهو طريقو ان کي حقيقي جنگي حالتن جي ويجهو آڻي ٿو جڏهن صارف سائيٽ جو دورو ڪن ٿا. مٿين سفارشن کي جانچڻ لاء، توھان استعمال ڪري سگھو ٿا Yandex.Tankom: اهو اسان جي سڀني ضرورتن کي پورو ڪري ٿو. هيٺ ڏنل تجاويز ۽ سفارشون آهن جاچ ڪرڻ لاءِ اسان جي تجربي مان هڪ واضح مثال سان Grafana ۽ Yandex.Tank جي گرافس جي مهرباني.

هتي سڀ کان اهم شيء آهي قدم بہ قدم تبديليون چيڪ ڪريو. نئين اصلاح کي شامل ڪرڻ کان پوء، ٽيسٽ کي هلائڻ ۽ ڏسو ته نتيجا آخري رن جي مقابلي ۾ تبديل ٿي ويا آھن. ٻي صورت ۾، غير موثر حل کي سڃاڻڻ ڏکيو ٿيندو، ۽ ڊگهي عرصي ۾ اهو صرف نقصان ڪري سگهي ٿو (مثال طور، مقرري وقت وڌايو).

ٻيو nuance ان جي ختم ٿيڻ دوران ڪنٽينر لاگز کي ڏسڻ لاءِ آهي. ڇا شاندار بند بابت معلومات اتي رڪارڊ ٿيل آهي؟ ڇا لاگن ۾ ڪي نقص آھن جڏھن ٻين وسيلن تائين پھچڻ وقت (مثال طور، پاڙيسري PHP-FPM ڪنٽينر ڏانھن)؟ ايپليڪيشن ۾ ئي غلطيون (جيئن مٿي بيان ڪيل NGINX جي صورت ۾)؟ مون کي اميد آهي ته هن آرٽيڪل مان تعارفي معلومات توهان کي بهتر سمجهڻ ۾ مدد ڪندي ته ان جي ختم ٿيڻ دوران ڪنٽينر کي ڇا ٿيندو.

تنهن ڪري، پهرين ٽيسٽ رن بغير ٿي وئي lifecycle ۽ بغير اضافي هدايتن جي ايپليڪيشن سرور لاءِ (process_control_timeout PHP-FPM ۾). ھن ٽيسٽ جو مقصد ھي ھو ته نقصن جي لڳ ڀڳ تعداد کي سڃاڻڻ (۽ ڇا ڪي آھن). انهي سان گڏ، اضافي معلومات مان، توهان کي ڄاڻڻ گهرجي ته هر پوڊ لاء اوسط ترتيب ڏيڻ جو وقت اٽڪل 5-10 سيڪنڊ هو جيستائين اهو مڪمل طور تي تيار نه هو. نتيجا هي آهن:

Yandex.Tank انفارميشن پينل 502 غلطين جي اسپائڪ کي ڏيکاري ٿو، جيڪا ڊيپلائيمينٽ جي وقت ٿي ۽ سراسري طور تي 5 سيڪنڊن تائين رهي. ممڪن آهي ته اهو ئي سبب هو ته پراڻي پوڊ جي موجوده درخواستن کي ختم ڪيو پيو وڃي جڏهن ان کي ختم ڪيو پيو وڃي. ان کان پوء، 503 غلطيون ظاهر ٿيون، جيڪو هڪ بند ٿيل NGINX ڪنٽينر جو نتيجو هو، جيڪو پڻ پس منظر جي ڪري ڪنيڪشن ختم ڪري ڇڏيو (جنهن کي ان سان ڳنڍڻ کان روڪيو ويو).

اچو ته ڏسو ڪيئن process_control_timeout PHP-FPM ۾ اسان کي ٻارن جي عملن جي مڪمل ٿيڻ جو انتظار ڪرڻ ۾ مدد ڪندو، يعني. اهڙين غلطين کي درست ڪريو. هن هدايت کي استعمال ڪندي ٻيهر ترتيب ڏيو:

500 هين تعیناتي دوران وڌيڪ غلطيون نه آهن! تعیناتي ڪامياب آهي، شاندار بند ڪم.

بهرحال، اهو ياد رکڻ جي قابل آهي ته مسئلو Ingress ڪنٽينرز سان، غلطين جو هڪ ننڍڙو سيڪڙو جنهن ۾ اسان کي وقت جي دير جي سبب حاصل ڪري سگهون ٿا. انهن کان بچڻ لاء، باقي رهي ٿو هڪ ساخت شامل ڪرڻ سان sleep ۽ ورجائي ورجائي. بهرحال، اسان جي خاص صورت ۾، ڪا به تبديلي نظر نه آئي (ٻيهر، ڪا به غلطي نه).

ٿڪل

عمل کي شاندار طور تي ختم ڪرڻ لاء، اسان کي درخواست کان هيٺين رويي جي توقع آهي:

1. ڪجھ سيڪنڊن جو انتظار ڪريو ۽ پوء نئين ڪنيڪشن کي قبول ڪرڻ بند ڪريو.
2. انتظار ڪريو سڀني درخواستن کي مڪمل ڪرڻ ۽ بند ڪرڻ لاءِ سڀئي محفوظ ڪنيڪشن جيڪي درخواستن تي عمل نه ڪري رهيا آهن.
3. پنهنجو عمل ختم ڪريو.

بهرحال، نه سڀئي ايپليڪيشنون هن طريقي سان ڪم ڪري سگهن ٿيون. Kubernetes حقيقتن ۾ مسئلي جو هڪ حل آهي:

• هڪ پري اسٽاپ ٿلهو شامل ڪرڻ جيڪو ڪجھ سيڪنڊن جو انتظار ڪندو؛
• اسان جي پس منظر جي ٺاھ جوڙ واري فائل جو مطالعو ڪرڻ مناسب پيٽرولن لاء.

NGINX سان مثال اهو واضح ڪري ٿو ته هڪ ايپليڪيشن جيڪا شروعاتي طور تي ختم ٿيڻ جي سگنلن کي صحيح طريقي سان عمل ڪرڻ گهرجي، ائين نه ٿي سگهي، تنهنڪري اهو ضروري آهي ته ايپليڪيشن جي ترتيب جي دوران 500 غلطين جي جانچ ڪرڻ لاء. اهو پڻ توهان کي مسئلي کي وڌيڪ وسيع طور تي ڏسڻ جي اجازت ڏئي ٿو ۽ هڪ واحد پوڊ يا ڪنٽينر تي ڌيان نه ڏيو، پر مجموعي طور تي مڪمل انفراسٽرڪچر کي ڏسو.

هڪ جاچ واري اوزار جي طور تي، توهان استعمال ڪري سگهو ٿا Yandex.Tank ڪنهن به مانيٽرنگ سسٽم سان گڏ (اسان جي صورت ۾، ڊيٽا Grafana کان ورتو ويو هڪ Prometheus backend سان ٽيسٽ لاءِ). خوبصورت بندش سان مسئلا واضح طور تي واضح طور تي نظر اچن ٿا ڳري بار هيٺ جيڪي معيار پيدا ڪري سگھن ٿا، ۽ نگراني ٽيسٽ دوران يا بعد ۾ صورتحال کي وڌيڪ تفصيل سان تجزيو ڪرڻ ۾ مدد ڪري ٿي.

مضمون تي موٽ جي جواب ۾: اهو قابل ذڪر آهي ته مسئلا ۽ حل هتي بيان ڪيا ويا آهن NGINX Ingress جي حوالي سان. ٻين ڪيسن لاء، ٻيا حل آهن، جن کي اسان سيريز جي هيٺين مواد ۾ غور ڪري سگهون ٿا.

پي ايس

ٻيا K8s ٽوٽڪا ۽ چالون سيريز مان:

• «NGINX Ingress ۾ ڪسٽم ايرر صفحا"؛
• «ويب ايپليڪيشن تي نوڊ مختص ڪرڻ ۽ لوڊ ڪرڻ بابت"؛
• «dev سائيٽن تائين رسائي"؛
• «وڏي ڊيٽابيس لاءِ بوٽ اسٽراپ کي تيز ڪرڻ».

جو ذريعو: www.habr.com