Kubernetes ۾ زندگي جي تحقيقات خطرناڪ ٿي سگهي ٿي

نوٽ. ترجمو: Zalando کان ليڊ انجنيئر، Henning Jacobs، بار بار محسوس ڪيو آهي ڪبرنيٽس استعمال ڪندڙن جي وچ ۾ زندگي جي مقصد (۽ تيارگي) جاچ ۽ انهن جي صحيح استعمال کي سمجهڻ ۾. تنهن ڪري، هن پنهنجي خيالن کي گڏ ڪيو هن قابل ذڪر نوٽ ۾، جيڪو آخرڪار K8s دستاويزن جو حصو بڻجي ويندو.

صحت جي چڪاس، ڪبرنيٽس ۾ ڄاڻايل آهي حياتياتي جاچ (يعني، لفظي، "قابل عمل ٽيسٽ" - تقريبن ترجمو.)، ڪافي خطرناڪ ٿي سگهي ٿو. آئون انهن کان بچڻ جي صلاح ڏيان ٿو جيڪڏهن ممڪن هجي: صرف استثنا آهن جڏهن اهي واقعي ضروري آهن ۽ توهان انهن جي استعمال جي خاصيتن ۽ نتيجن کان مڪمل طور تي واقف آهيو. هي اشاعت زندهه ۽ تياري جي چڪاس بابت ڳالهائيندو، ۽ اهو پڻ ٻڌائيندو ته ڪهڙن حالتن ۾ لڳي ٿو ۽ توهان کي انهن کي استعمال نه ڪرڻ گهرجي.

منهنجو ساٿي سينڊر تازو ئي Twitter تي شيئر ڪيو آهي سڀ کان وڌيڪ عام غلطيون جيڪي هن کي سامهون اچي رهيون آهن، جن ۾ اهي شامل آهن جيڪي تياري/زندگي جي جاچ جي استعمال سان لاڳاپيل آهن:

غلط ترتيب ڏنل livenessProbe تيز لوڊ حالتون وڌائي سگھي ٿو (سنو بال شٽ ڊائون + امڪاني طور تي ڊگھو ڪنٽينر/ايپليڪيشن جي شروعات جو وقت) ۽ ٻين ناڪاري نتيجن کي جنم ڏئي سگھي ٿو جهڙوڪ انحصار جي گھٽتائي (پڻ ڏسو منهنجو تازو مضمون K3s + ACME ميلاپ ۾ درخواستن جي تعداد کي محدود ڪرڻ بابت). اهو اڃا به خراب آهي جڏهن زندگي جي جاچ کي صحت جي چڪاس سان گڏ ڪيو ويندو آهي، جيڪو هڪ خارجي ڊيٽابيس آهي: هڪ واحد ڊي بي ناڪامي توهان جي سڀني ڪنٽينرز کي ٻيهر شروع ڪندي!

عام پيغام "زندگي جي تحقيقات استعمال نه ڪريو" انهي صورت ۾ اهو گهڻو مدد نٿو ڪري، تنهنڪري اچو ته ڏسو ته تيارگي ۽ جاندار چيڪن لاء ڇا آهن.

نوٽ: هيٺ ڏنل اڪثر ٽيسٽ اصل ۾ Zalando جي اندروني ڊولپر دستاويزن ۾ شامل ڪئي وئي هئي.

تيارگي ۽ زندگي جي چڪاس

Kubernetes مهيا ڪري ٿو ٻه اهم ميڪانيزم جنهن کي سڏيو ويندو آهي حياتياتي جاچ ۽ تياري جاچ. اهي وقتي طور تي ڪجهه عمل ڪندا آهن- جهڙوڪ هڪ HTTP درخواست موڪلڻ، هڪ TCP ڪنيڪشن کولڻ، يا ڪنٽينر ۾ حڪم جاري ڪرڻ- تصديق ڪرڻ لاءِ ته ايپليڪيشن توقع جي مطابق ڪم ڪري رهي آهي.

ڪبرنيٽس استعمال ڪري ٿو تياري جاچسمجھڻ لاءِ جڏھن ڪنٽينر ٽريفڪ قبول ڪرڻ لاءِ تيار آھي. هڪ پوڊ استعمال لاء تيار سمجهيو ويندو آهي جيڪڏهن ان جا سڀئي ڪنٽينر تيار آهن. هن ميڪانيزم جو هڪ استعمال اهو آهي ڪنٽرول ڪرڻ لاءِ ڪهڙن پوڊس کي ڪبرنيٽس سروسز (۽ خاص طور تي Ingress) لاءِ پس منظر طور استعمال ڪيو وڃي ٿو.

حياتياتي جاچ ڪبرنيٽس کي سمجھڻ ۾ مدد ڪريو جڏهن ڪنٽينر کي ٻيهر شروع ڪرڻ جو وقت آهي. مثال طور، اهڙي چيڪ توهان کي اجازت ڏئي ٿي ته هڪ بند لاڪ کي روڪيو جڏهن هڪ ايپليڪيشن هڪ جاءِ تي ڦاسي پوي. هن حالت ۾ ڪنٽينر کي ٻيهر شروع ڪرڻ ۾ مدد ڪري ٿي ايپليڪيشن کي حاصل ڪرڻ ۾ غلطين جي باوجود، پر اهو پڻ ٿي سگهي ٿو cascading ناڪامي (هيٺ ڏسو).

جيڪڏهن توهان هڪ ايپليڪيشن اپڊيٽ کي ترتيب ڏيڻ جي ڪوشش ڪندا آهيو جيڪا جاندار/تياريءَ جي چڪاس ۾ ناڪام ٿئي ٿي، ان جو رول آئوٽ روڪيو ويندو جيئن ڪبرنيٽس اسٽيٽس جو انتظار ڪري رهيو آهي Ready سڀني پٽن مان.

مثال طور

ھتي ھڪڙو مثال آھي تياري جي جاچ جو رستو چيڪ ڪرڻ /health HTTP ذريعي ڊفالٽ سيٽنگون (وقار: 10 سيڪنڊ وقت ختم ٿي ويو: 1 سيڪنڊ، ڪاميابي جي حد: 1، ناڪامي جي حد:3):

# часть общего описания deployment'а/стека
podTemplate:
  spec:
    containers:
    - name: my-container
      # ...
      readinessProbe:
        httpGet:
          path: /health
          port: 8080

سفارشون

1. HTTP جي آخر پوائنٽ سان مائڪرو سروسز لاءِ (REST، وغيره) هميشه تياري جي جاچ جي وضاحت ڪريو، جيڪو چيڪ ڪري ٿو ته ڇا ايپليڪيشن (pod) ٽرئفڪ کي قبول ڪرڻ لاءِ تيار آهي.
2. تياري جي جاچ کي پڪ ڪريو اصل ويب سرور پورٽ جي دستيابي کي ڍڪي ٿو:
   • انتظامي مقصدن لاءِ بندرگاهن کي استعمال ڪندي، جنهن کي ”منتظم“ يا ”انتظام“ سڏيو وڃي ٿو (مثال طور، 9090) readinessProbe, پڪ ڪريو ته آخري پوائنٽ صرف ٺيڪ موٽائي ٿو جيڪڏهن پرائمري HTTP بندرگاهه (جهڙوڪ 8080) ٽرئفڪ کي قبول ڪرڻ لاء تيار آهي*؛

     *مان Zalando ۾ گهٽ ۾ گهٽ هڪ ڪيس کان واقف آهيان جتي اهو نه ٿيو هو، يعني. readinessProbe مون ”انتظام“ بندرگاهه کي چيڪ ڪيو، پر ڪيش لوڊ ڪرڻ ۾ مشڪلاتن جي ڪري سرور پاڻ ڪم ڪرڻ شروع نه ڪيو.

   • تياري جي جاچ کي الڳ بندرگاهن سان ڳنڍڻ سان حقيقت اها ٿي سگهي ٿي ته مکيه بندرگاهه تي اوور لوڊ صحت جي چڪاس ۾ ظاهر نه ٿيندو (يعني سرور تي ٿريڊ پول مڪمل آهي، پر صحت جي چڪاس اڃا به ڏيکاري ٿي ته سڀ ڪجهه ٺيڪ آهي. ).
3. پڪ ڪريو ته تياري جي جاچ کي فعال ڪري ٿو ڊيٽابيس جي شروعات/لڏپلاڻ;
   • هن کي حاصل ڪرڻ جو آسان طريقو اهو آهي ته HTTP سرور سان رابطو ڪيو وڃي صرف شروعات مڪمل ٿيڻ کان پوءِ (مثال طور، هڪ ڊيٽابيس کي منتقل ڪرڻ اڏامندڙ رستو ۽ ايئن.)؛ اهو آهي، صحت جي چڪاس واري صورتحال کي تبديل ڪرڻ جي بدران، صرف ويب سرور شروع نه ڪريو جيستائين ڊيٽابيس لڏپلاڻ مڪمل نه ٿئي*.

     * توهان پوڊ کان ٻاهر init ڪنٽينرز مان ڊيٽابيس لڏپلاڻ پڻ هلائي سگهو ٿا. مان اڃا تائين خود مختيار ايپليڪيشنن جو پرستار آهيان، يعني اهي آهن، جن ۾ ايپليڪيشن ڪنٽينر ڄاڻي ٿو ته ڊيٽابيس کي گهربل حالت ۾ ڪيئن آڻيو ٻاهرين ڪوآرڊينيشن کان سواءِ.

4. استعمال ڪريو httpGet عام صحت جي چڪاس جي آخري پوائنٽن ذريعي تياري جي چڪاس لاءِ (مثال طور، /health).
5. سمجھو ڊفالٽ چيڪ پيٽرولر (interval: 10s, timeout: 1s, successThreshold: 1, failureThreshold: 3):
   • ڊفالٽ اختيارن جو مطلب آھي پوڊ بڻجي ويندو تيار نه اٽڪل 30 سيڪنڊن کان پوءِ (3 ناڪام صفائي جي چڪاس).
6. "منتظم" يا "انتظام" لاءِ الڳ پورٽ استعمال ڪريو جيڪڏھن ٽيڪنالاجي اسٽيڪ (مثال طور جاوا/اسپرنگ) ان کي اجازت ڏئي ٿي، صحت ۽ ميٽرڪ مينيجمينٽ کي باقاعده ٽرئفڪ کان الڳ ڪرڻ لاءِ:
   • پر پوائنٽ 2 جي باري ۾ نه وساريو.
7. جيڪڏهن ضروري هجي ته، تياري جي جاچ کي ڪيش کي گرم ڪرڻ/لوڊ ڪرڻ ۽ 503 اسٽيٽس ڪوڊ واپس ڪرڻ لاءِ استعمال ڪري سگهجي ٿو جيستائين ڪنٽينر گرم نه ٿئي:
   • مان پڻ سفارش ڪريان ٿو ته توهان پڙهو نئين چيڪ startupProbe, نسخو 1.16 ۾ ظاهر ٿيو (اسان ان بابت روسي ۾ لکيو هتي - لڳ ڀڳ ترجمو.).

ڪيٽيون

1. خارجي انحصار تي ڀروسو نه ڪريو (جهڙوڪ ڊيٽا گودام) جڏهن تياري / جاندار ٽيسٽ هلائي رهيا آهن - اهو ٿي سگهي ٿو cascading ناڪامي:
   • مثال طور، اچو ته هڪ پوسٽ گريس ڊيٽابيس جي بنياد تي 10 پوڊس سان گڏ هڪ رياستي REST سروس وٺون: جڏهن چيڪ ڊي بي سان ڪم ڪندڙ ڪنيڪشن تي منحصر هوندو آهي، سڀ 10 پوڊ ناڪام ٿي سگهن ٿا جيڪڏهن نيٽ ورڪ/ڊي بي پاسي تي دير ٿئي ٿي - عام طور تي اهو سڀ ختم ٿي سگهي ٿو ان کان وڌيڪ خراب؛
   • مهرباني ڪري نوٽ ڪريو ته اسپرنگ ڊيٽا ڊيٽابيس ڪنيڪشن کي ڊفالٽ طور چيڪ ڪري ٿو*؛

     * هي اسپرنگ ڊيٽا ريڊس جو ڊفالٽ رويو آهي (گهٽ ۾ گهٽ اهو آخري وقت هو جيڪو مون چيڪ ڪيو هو)، جنهن جي نتيجي ۾ ”تباهي واري“ ناڪامي ٿي: جڏهن ريڊيس ٿوري وقت لاءِ دستياب نه هو، سڀ پوڊس ”تباهه ٿي ويا“.

   • "بيروني" هن معنى ۾ ساڳئي ايپليڪيشن جي ٻين پوڊس جو مطلب پڻ ٿي سگهي ٿو، اهو آهي، مثالي طور تي چيڪ کي ساڳئي ڪلستر جي ٻين پوڊ جي حالت تي منحصر نه هجڻ گهرجي ته جيئن حادثن کي روڪڻ لاء:
     • ورهايل رياست سان ايپليڪيشنن لاءِ نتيجا مختلف ٿي سگهن ٿا (مثال طور، پوڊز ۾ ميموري ڪيشنگ).
2. زندهه جاچ استعمال نه ڪريو پوڊز لاءِ (استثنائي ڪيس آهن جڏهن اهي واقعي ضروري آهن ۽ توهان انهن جي استعمال جي خاصيتن ۽ نتيجن کان مڪمل طور تي واقف آهيو):
   • هڪ جاندار جاچ ٽنگيل ڪنٽينرز کي بحال ڪرڻ ۾ مدد ڪري سگهي ٿي، پر جيئن ته توهان وٽ توهان جي ايپليڪيشن تي مڪمل ڪنٽرول آهي، شيون جهڙوڪ ٽنگيل عمل ۽ تعطل مثالي طور تي نه ٿيڻ گهرجي: بهترين متبادل اهو آهي ته عمدي طور تي ايپليڪيشن کي تباهه ڪرڻ ۽ ان کي پوئين مستحڪم حالت ۾ واپس آڻڻ؛
   • هڪ ناڪام جاندار جاچ ڪنٽينر کي ٻيهر شروع ڪرڻ جو سبب بڻائيندو، ان ڪري ممڪن طور تي بوٽ سان لاڳاپيل غلطين جي اثرات کي وڌائيندو: ڪنٽينر کي ٻيهر شروع ڪرڻ جي نتيجي ۾ دير ٿي ويندي (گهٽ ۾ گهٽ ايپليڪيشن جي شروعات جي مدت لاء، 30+ سيڪنڊن لاء)، نئين غلطي جو سبب بڻجندي، ٻين ڪنٽينرز تي لوڊ وڌائڻ ۽ انهن جي ناڪامي جو امڪان وڌائڻ، وغيره.
   • زندهه چڪاسون گڏيل خارجي انحصار سان گڏ سڀ کان بدترين ممڪن ميلاپ آهن، خطرناڪ ناڪامي جو خطرو: ڊيٽابيس جي پاسي تي ٿوري دير توهان جي سڀني ڪنٽينرز کي ٻيهر شروع ڪرڻ جو سبب بڻجندي!
3. جاندار ۽ تيارگي جي چڪاس جا پيرا ميٽر مختلف هجڻ گهرجي:
   • توهان ساڳي صحت جي چڪاس سان هڪ زندهه جاچ استعمال ڪري سگهو ٿا، پر هڪ اعلي جوابي حد (failureThreshold)، مثال طور، حيثيت ڏيو تيار نه 3 ڪوششن کان پوء ۽ غور ڪيو ته زندگي جي تحقيق 10 ڪوششن کان پوء ناڪام ٿي وئي آهي؛
4. exec چيڪ استعمال نه ڪريو، ڇاڪاڻ ته اهي سڃاتل مسئلن سان جڙيل آهن جيڪي زومبي عمل جي ظاهر ٿيڻ جي ڪري آهن:
   • تفصيل: ڏسو Datadog ماهرن پاران پيش ڪيل.

خلاصو

• تياري جاچ استعمال ڪريو اهو طئي ڪرڻ لاءِ ته جڏهن پوڊ ٽرئفڪ حاصل ڪرڻ لاءِ تيار آهي.
• زندهه جاچ صرف استعمال ڪريو جڏهن اهي واقعي گهربل آهن.
• تياري/ جاندار جاچ جو غلط استعمال گهٽجڻ جي دستيابي ۽ ڪاسڪيڊنگ ناڪامي جو سبب بڻجي سگھي ٿو.

موضوع تي اضافي مواد

• ڪبرنيٽس دستاويز: ترتيب ڏيو زندگي ۽ تياري جي جاچ;
• ڪبرنيٽس لائيونس ۽ تيارگي جي تحقيقات ٻيهر نظرثاني ڪئي وئي: ڪيئن پاڻ کي ٻين پيرن ۾ گولي هڻڻ کان بچڻ;
• NRE ليب آئوٽيج پوسٽ مارٽم (هو livenessProbe بابت پڻ ڳالهائيندو آهي).

تازه ڪاري نمبر 1 کان 2019-09-29

ڊيٽابيس لڏپلاڻ لاءِ init ڪنٽينرز بابت: فوٽ نوٽ شامل ڪيو ويو.

EJ مون کي ياد ڏياريو PDB بابت: زندگي جي چڪاس جي مسئلن مان هڪ آهي پوڊ جي وچ ۾ هم آهنگي جي کوٽ. ڪبرنيٽس وٽ آهي Pod Disruption Budges (PDB) سمورو ناڪامين جي تعداد کي محدود ڪرڻ لاءِ هڪ ايپليڪيشن تجربو ڪري سگهي ٿي، جڏهن ته چيڪ PDB جي حساب ۾ نه ٿا اچن. مثالي طور، اسان K8s کي چئي سگهون ٿا ته "هڪ پوڊ کي ٻيهر شروع ڪريو جيڪڏهن ان جو امتحان ناڪام ٿئي، پر انهن سڀني کي ٻيهر شروع نه ڪريو شيون خراب ڪرڻ کان بچڻ لاء."

Bryan ان کي مڪمل طور تي رکيو: ”جڏهن توهان ڄاڻو ٿا ته واقعي ڇا آهي زندهه جاچ استعمال ڪريو ڪرڻ جو بهترين ڪم آهي ايپليڪيشن کي مارڻ"(ٻيهر، پري نه وڃو).

تازه ڪاري نمبر 2 کان 2019-09-29

استعمال کان اڳ دستاويز پڙهڻ جي حوالي سان: مون لاڳاپيل درخواست ٺاهي (مضمون جي درخواست) زندهه جاچ بابت دستاويز شامل ڪرڻ لاءِ.

پي ايس مترجم کان

اسان جي بلاگ تي پڻ پڙهو:

• «ڪبرنيٽس: پوڊ لائف"؛
• «گوگل جي مطابق ڪنٽينر استعمال ڪرڻ لاءِ 7 بهترين طريقا"؛
• «ڪنٽينر تي ٻڌل ايپليڪيشنن کي ڊزائين ڪرڻ لاءِ 7 اصول».

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