په Kubernetes کې د ژوندانه تحقیقات خطرناک کیدی شي

نوټ. ژباړه: د Zalando مخکښ انجنیر، Henning Jacobs، په مکرر ډول د Kubernetes کاروونکو ترمنځ د ژوندانه (او چمتووالي) تحقیقاتو او د دوی د سمې کارونې هدف په پوهیدو کې ستونزې لیدلي. له همدې امله، هغه خپل فکرونه په دې وړ یادښت کې راټول کړل، چې په پای کې به د K8s اسنادو برخه شي.

روغتیایی معاینات چې په کوبرنیټس کې پیژندل کیږي ژوندیتوب تحقیقات (د بیلګې په توګه، په لفظي توګه، "د وړتیا ازموینې" - نږدې ژباړه.)، کیدای شي خورا خطرناک وي. زه د امکان په صورت کې د دوی څخه مخنیوی وړاندیز کوم: یوازینۍ استثناوې هغه وخت دي کله چې دوی واقعیا اړین وي او تاسو د دوی کارولو ځانګړتیاو او پایلو څخه په بشپړ ډول خبر یاست. دا خپرونه به د ژوندانه او چمتووالي چک په اړه وغږیږي، او دا به هم تاسو ته ووایي چې په کوم حالت کې ارزښت لري او تاسو باید دوی ونه کاروئ.

زما همکار سنډور پدې وروستیو کې په ټویټر کې خورا عام غلطۍ شریکې کړې چې هغه ورسره مخ کیږي ، پشمول د چمتووالي/ژوندۍ تحقیقاتو کارولو پورې اړوند:

په غلطه توګه ترتیب شوی livenessProbe کولی شي د لوړ بار حالتونه خراب کړي (د سنوبال بندول + احتمالي اوږد کانټینر/د غوښتنلیک پیل وخت) او د نورو منفي پایلو لکه د انحصار کمیدو لامل کیږي (هم وګوره زما وروستۍ مقاله د K3s + ACME ترکیب کې د غوښتنو شمیر محدودولو په اړه). دا لا بدتر دی کله چې د ژوندانه تحقیقات د روغتیا معاینې سره یوځای کیږي، کوم چې یو بهرنی ډیټابیس دی: د DB یو واحد ناکامي به ستاسو ټول کانټینرونه بیا پیل کړي!

عمومي پیغام "د ژوندانه تحقیقات مه کاروئ" پدې حالت کې دا ډیره مرسته نه کوي، نو راځئ چې وګورو چې د چمتووالي او ژوند کولو چکونه د څه لپاره دي.

یادونه: لاندې ډیری ازموینې په اصل کې د زیلانډو داخلي پراختیا کونکي اسنادو کې شاملې وې.

د چمتووالي او ژوندانه چکونه

Kubernetes په نوم دوه مهم میکانیزمونه وړاندې کوي د ژوندانه تحقیقات او د چمتووالي تحقیقات. دوی په دوره توګه ځینې کړنې ترسره کوي - لکه د HTTP غوښتنه لیږل، د TCP پیوستون پرانیستل، یا په کانټینر کې د قوماندې اجرا کول - ترڅو دا تایید کړي چې غوښتنلیک د توقع سره سم کار کوي.

Kubernetes کاروي د چمتووالي تحقیقاتد پوهیدو لپاره کله چې کانټینر د ترافیک منلو ته چمتو وي. یو پوډ د کارونې لپاره چمتو ګڼل کیږي که چیرې ټول کانټینرونه چمتو وي. د دې میکانیزم یوه کارول د دې کنټرول کول دي چې کوم پوډونه د کوبرنیټس خدماتو (او په ځانګړي توګه انګریس) لپاره د بیکینډ په توګه کارول کیږي.

د ژوندانه تحقیقات د کبرنیټس سره مرسته وکړئ چې پوه شي کله چې د کانټینر بیا پیل کولو وخت دی. د مثال په توګه، دا ډول چک تاسو ته اجازه درکوي چې یو خنډ ودروي کله چې یو غوښتنلیک په یو ځای کې ودریږي. په دې حالت کې د کانټینر بیا پیل کول د غلطیو سره سره د غوښتنلیک له ځمکې څخه لرې کولو کې مرسته کوي، مګر دا کولی شي د کاسکیډینګ ناکامۍ لامل شي (لاندې وګورئ).

که تاسو د غوښتنلیک تازه کولو هڅه وکړئ چې د ژوندانه / چمتووالي چکونو کې پاتې راشي، نو د دې رول آوټ به ودرول شي ځکه چې کبرنیټس وضعیت ته انتظار کوي Ready د ټولو پوډرو څخه.

بېلګه:

دلته د چمتووالي تحقیقاتو یوه بیلګه ده چې د لارې معاینه کوي /health د ډیفالټ ترتیباتو سره د HTTP له لارې (منځګړی: 10 ثانیې وخت خلاص شو: 1 ثانیه د بریالیتوب حد: 1، د ناکامۍ حد:۳):

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

سپارښتنې

1. د HTTP پای ټکی سره د مایکرو خدماتو لپاره (REST، او نور) تل د چمتووالي تحقیقات تعریف کړئ، کوم چې ګوري چې ایا غوښتنلیک (پوډ) د ترافیک منلو لپاره چمتو دی.
2. ډاډ ترلاسه کړئ چې د چمتووالي پلټنه وکړئ د ریښتیني ویب سرور بندر شتون پوښي:
   • د اداري موخو لپاره د بندرونو کارول، چې د "اډمین" یا "مدیریت" په نوم یادیږي (د مثال په توګه، 9090)، د دې لپاره readinessProbe، ډاډ ترلاسه کړئ چې پای ټکی یوازې بیرته راستنیږي که چیرې لومړني HTTP پورټ (لکه 8080) د ترافیک منلو ته چمتو وي*؛

     * زه په ځلانډو کې لږترلږه د یوې قضیې څخه خبر یم چیرې چې دا ندي پیښ شوي، د بیلګې په توګه. 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. په بهرنیو انحصارونو تکیه مه کوئ (لکه د معلوماتو ګودامونه) کله چې د چمتووالي/ژوندۍ ازموینې چلول - دا کولی شي د ناکامۍ لامل شي:
   • د مثال په توګه ، راځئ چې د پوسټ ګریس ډیټابیس پورې اړوند د 10 پوډونو سره یو دولتي REST خدمت واخلو: کله چې چک د DB سره په کاري ارتباط پورې اړه لري ، ټول 10 پوډونه ناکام کیدی شي که چیرې د شبکې / DB اړخ کې ځنډ شتون ولري - معمولا دا ټول پای له هغه څخه ډیر خراب دی؛
   • مهرباني وکړئ په یاد ولرئ چې د پسرلي ډاټا د ډیفالټ په واسطه د ډیټابیس اتصال چیک کوي*؛

     * دا د پسرلي ډیټا ریډیس ډیفالټ چلند دی (لږترلږه دا وروستی ځل و چې ما چیک کړی و) ، کوم چې د "ناورین" ناکامۍ لامل شوی: کله چې ریډیس د لنډ وخت لپاره شتون نلري ، ټول پوډونه "کریش شوي".

   • "بهرني" پدې معنی کې د ورته غوښتنلیک نور پوډونه هم معنی کولی شي ، دا دی ، په مثالي ډول چیک باید د ورته کلستر نورو پوډونو حالت پورې اړه ونلري ترڅو د کیسکیډینګ حادثو مخه ونیسي:
     • پایلې ممکن د توزیع شوي حالت سره غوښتنلیکونو لپاره توپیر ولري (د مثال په توګه ، په پوډونو کې د حافظې کې کیشینګ).
2. د ژوندانه تحقیقات مه کاروئ د پوډونو لپاره (استثنا هغه قضیې دي کله چې دوی واقعیا اړین وي او تاسو د دوی د کارولو ځانګړتیاو او پایلو څخه په بشپړ ډول خبر یاست):
   • د ژوندیتوب تحقیقات کولی شي د ځړول شوي کانټینرونو په رغولو کې مرسته وکړي، مګر دا چې تاسو په خپل غوښتنلیک بشپړ کنټرول لرئ، د ځړول شوي پروسې او ځنډونو په څیر شیان باید په نظر کې ونه نیول شي: غوره بدیل دا دی چې په عمدي توګه غوښتنلیک خراب کړي او بیرته پخواني ثابت حالت ته راوړي؛
   • د ژوندی پاتې کیدو یوه ناکامه څیړنه به د کانټینر د بیا پیلیدو لامل شي، په دې توګه به په احتمالي توګه د بارولو پورې اړوند غلطیو پایلې لاپسې زیاتې کړي: د کانټینر بیا پیل کول به د ځنډیدو پایله ولري (لږترلږه د غوښتنلیک پیل کولو مودې لپاره، د 30 ثانیو لپاره ووایه)، د نوي غلطیو لامل کیږي. ، په نورو کانټینرونو کې د بار زیاتوالی او د دوی د ناکامۍ احتمال ډیرول ، او داسې نور؛
   • د بهرني انحصار سره یوځای د ژوند کولو چکونه ترټولو بد ممکنه ترکیب دی، د کاسکیډینګ ناکامۍ ګواښوي: د ډیټابیس اړخ کې یو څه ځنډ به ستاسو د ټولو کانټینرونو بیا پیل کیدو لامل شي!
3. د ژوندانه او چمتووالي معایناتو پیرامیټونه باید توپیر ولري:
   • تاسو کولی شئ د ورته روغتیایی معاینې سره د ژوندانه تحقیقات وکاروئ، مګر د لوړ غبرګون حد (failureThreshold)، د مثال په توګه، د وضعیت ټاکل نه چمتو د 3 هڅو ​​وروسته او په پام کې ونیسئ چې د ژوندانه څیړنه د 10 هڅو وروسته ناکامه شوې ده؛
4. د اجرایی چکونو څخه کار مه اخلئ، ځکه چې دوی د پیژندل شوي ستونزو سره تړاو لري چې د زومبي پروسو څرګندیدو لامل کیږي:
   • تفصيلات: وګورئ د ډیټاګګ متخصصینو لخوا پریزنټشن.

لنډیز

• د چمتووالي تحقیقات وکاروئ ترڅو معلومه کړئ کله چې پوډ د ټرافیک ترلاسه کولو لپاره چمتو وي.
• د ژوندانه تحقیقات یوازې هغه وخت وکاروئ کله چې واقعیا ورته اړتیا وي.
• د چمتووالي/ژوندانه پروبونو ناسمه ګټه اخیستنه کولی شي د کمښت او کاسکیډینګ ناکامۍ لامل شي.

په موضوع کې اضافي توکي

• د کوبرنیټس اسناد: د ژوندانه او چمتووالي تحقیقات تنظیم کړئ;
• د کبرنیټس ژوند او چمتووالي تحقیقات بیاکتل شوي: څنګه په بل پښه کې د ځان د ډزو څخه مخنیوی وکړئ;
• د NRE لابراتوار بندیدل پوسټ مارټم (هغه د LivenessProbe په اړه هم خبرې کوي).

تازه شمیره 1 له 2019-09-29 څخه

د ډیټابیس مهاجرت لپاره د init کانټینرونو په اړه: فوټ نوټ اضافه شو.

EJ ما ته یادونه وکړه د PDB په اړه: د ژوندانه چکونو یوه ستونزه د پوډونو ترمنځ د همغږۍ نشتوالی دی. Kubernetes لري د پوډ خنډ بودیجه (PDB) د ورته ناکامیو شمیر محدودولو لپاره یو غوښتنلیک تجربه کولی شي، که څه هم چکونه PDB په پام کې نه نیسي. په عین حال کې، موږ کولی شو K8s ته ووایو چې "یو پوډ بیا پیل کړئ که دا ازموینه ناکامه شي، مګر دا ټول بیا پیل مه کوئ ترڅو د شیانو د خرابیدو مخه ونیسي."

براین دا په سمه توګه واچوله: "کله چې تاسو په ریښتیا پوهیږئ څه شی د ژوندانه تحقیقاتو څخه کار واخلئ د ترسره کولو لپاره غوره شی د غوښتنلیک وژل دي"(بیا بیا، مه لیرې کیږئ).

تازه شمیره 2 له 2019-09-29 څخه

د کارولو دمخه د اسنادو لوستلو په اړه: ما ورته غوښتنه جوړه کړه (د ب featureې غوښتنهد ژوندانه تحقیقاتو په اړه اسناد اضافه کول.

PS د ژباړونکي څخه

زموږ په بلاګ کې هم ولولئ:

• «Kubernetes: د پوډ ژوند»
• «د ګوګل په وینا د کانټینرونو کارولو لپاره 7 غوره تمرینونه»
• «د کانټینر پر بنسټ غوښتنلیکونو ډیزاین کولو لپاره 7 اصول".

سرچینه: www.habr.com