ការស៊ើបអង្កេតលើភាពរស់រវើកនៅក្នុង Kubernetes អាចមានគ្រោះថ្នាក់

ចំណាំ។ បកប្រែ៖ វិស្វករនាំមុខមកពី Zalando លោក Henning Jacobs បានកត់សម្គាល់ឃើញបញ្ហាជាច្រើនដងក្នុងចំណោមអ្នកប្រើប្រាស់ Kubernetes ក្នុងការយល់ដឹងអំពីគោលបំណងនៃការស៊ើបអង្កេតភាពរស់រវើក (និងការត្រៀមខ្លួន) និងការប្រើប្រាស់ត្រឹមត្រូវរបស់ពួកគេ។ ហេតុដូច្នេះហើយ គាត់បានប្រមូលគំនិតរបស់គាត់នៅក្នុងកំណត់ត្រាដ៏មានសក្តានុពលនេះ ដែលនៅទីបំផុតនឹងក្លាយជាផ្នែកមួយនៃឯកសារ K8s ។

ការពិនិត្យសុខភាព ដែលត្រូវបានគេស្គាល់នៅក្នុង Kubernetes ជា ការស៊ើបអង្កេតជីវិត (ឧ. ព្យញ្ជនៈ "ការធ្វើតេស្តលទ្ធភាពជោគជ័យ" - ប្រហែលបកប្រែ។ ), អាច​មាន​គ្រោះ​ថ្នាក់​ខ្លាំង​ណាស់​។ ខ្ញុំសូមណែនាំឱ្យជៀសវាងពួកវាប្រសិនបើអាចធ្វើទៅបាន៖ ករណីលើកលែងតែមួយគត់គឺនៅពេលដែលពួកគេពិតជាចាំបាច់ ហើយអ្នកដឹងច្បាស់អំពីភាពជាក់លាក់ និងផលវិបាកនៃការប្រើប្រាស់របស់វា។ ការបោះពុម្ភផ្សាយនេះនឹងនិយាយអំពីការពិនិត្យមើលភាពរស់រវើក និងការត្រៀមខ្លួន ហើយនឹងប្រាប់អ្នកផងដែរនៅក្នុងករណីណា មានតម្លៃវា ហើយអ្នកមិនគួរប្រើវាទេ។

សហសេវិករបស់ខ្ញុំ Sandor ថ្មីៗនេះបានចែករំលែកនៅលើ Twitter នូវកំហុសទូទៅបំផុតដែលគាត់បានជួបប្រទះ រួមទាំងបញ្ហាទាក់ទងនឹងការប្រើប្រាស់ការស៊ើបអង្កេតការត្រៀមខ្លួន/រស់រានមានជីវិត៖

កំណត់រចនាសម្ព័ន្ធមិនត្រឹមត្រូវ livenessProbe អាចធ្វើឱ្យស្ថានភាពផ្ទុកបន្ទុកខ្ពស់កាន់តែធ្ងន់ធ្ងរ (ការបិទបាល់ព្រិល + ធុងផ្ទុក / ពេលវេលាចាប់ផ្តើមកម្មវិធីយូរដែលមានសក្តានុពល) និងនាំទៅរកផលវិបាកអវិជ្ជមានផ្សេងទៀតដូចជាការធ្លាក់ចុះនៃភាពអាស្រ័យ។ (សូម​មើល​ផង​ដែរ អត្ថបទថ្មីៗរបស់ខ្ញុំ អំពីការកំណត់ចំនួនសំណើក្នុងបន្សំ K3s+ACME). វាកាន់តែអាក្រក់នៅពេលដែលការស៊ើបអង្កេតជីវិតត្រូវបានផ្សំជាមួយការពិនិត្យសុខភាព ដែលជាមូលដ្ឋានទិន្នន័យខាងក្រៅ៖ ការបរាជ័យ DB តែមួយនឹងចាប់ផ្តើមកុងតឺន័ររបស់អ្នកឡើងវិញ!

សារទូទៅ "កុំប្រើការស៊ើបអង្កេតរស់" ក្នុងករណីនេះវាមិនអាចជួយអ្វីបានច្រើនទេ ដូច្នេះសូមក្រឡេកមើលថាតើការត្រៀមលក្ខណៈ និងការត្រួតពិនិត្យជីវិតគឺសម្រាប់អ្វីខ្លះ។

ចំណាំ៖ ការធ្វើតេស្តខាងក្រោមភាគច្រើនត្រូវបានបញ្ចូលក្នុងឯកសារអ្នកអភិវឌ្ឍន៍ខាងក្នុងរបស់ Zalando ។

ការត្រួតពិនិត្យការត្រៀមខ្លួន និងការរស់នៅ

Kubernetes ផ្តល់នូវយន្តការសំខាន់ពីរដែលហៅថា ការស៊ើបអង្កេតការរស់នៅ និងការស៊ើបអង្កេតការត្រៀមខ្លួន. ពួកគេអនុវត្តសកម្មភាពមួយចំនួនជាទៀងទាត់ ដូចជាការផ្ញើសំណើ HTTP ការបើកការតភ្ជាប់ TCP ឬប្រតិបត្តិពាក្យបញ្ជានៅក្នុងកុងតឺន័រ ដើម្បីបញ្ជាក់ថាកម្មវិធីកំពុងដំណើរការដូចការរំពឹងទុក។

Kubernetes ប្រើ ការស៊ើបអង្កេតការត្រៀមខ្លួនដើម្បីយល់ពីពេលដែលកុងតឺន័ររួចរាល់ដើម្បីទទួលយកចរាចរណ៍។ ផតត្រូវបានចាត់ទុកថារួចរាល់សម្រាប់ការប្រើប្រាស់ ប្រសិនបើធុងទាំងអស់របស់វារួចរាល់។ ការប្រើប្រាស់មួយនៃយន្តការនេះគឺដើម្បីគ្រប់គ្រង pods ណាដែលត្រូវបានប្រើជា backend សម្រាប់សេវាកម្ម Kubernetes (និងជាពិសេស Ingress) ។

ការស៊ើបអង្កេតភាពរស់រវើក ជួយ Kubernetes យល់នៅពេលដែលវាដល់ពេលត្រូវចាប់ផ្តើមកុងតឺន័រឡើងវិញ។ ជាឧទាហរណ៍ ការត្រួតពិនិត្យបែបនេះអនុញ្ញាតឱ្យអ្នកស្ទាក់ចាប់ការជាប់គាំងនៅពេលដែលកម្មវិធីមួយជាប់គាំងនៅកន្លែងតែមួយ។ ការចាប់ផ្តើមកុងតឺន័រឡើងវិញក្នុងស្ថានភាពនេះជួយឱ្យកម្មវិធីមិនដំណើរការ ទោះបីជាមានកំហុសក៏ដោយ ប៉ុន្តែវាក៏អាចនាំទៅរកការបរាជ័យជាបន្តបន្ទាប់ (សូមមើលខាងក្រោម)។

ប្រសិនបើអ្នកព្យាយាមដាក់ពង្រាយការអាប់ដេតកម្មវិធីដែលបរាជ័យក្នុងការត្រួតពិនិត្យភាពរស់រវើក/ការត្រៀមខ្លួន ការដាក់ឱ្យដំណើរការរបស់វានឹងត្រូវជាប់គាំង ដោយសារ Kubernetes រង់ចាំស្ថានភាព 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 containers នៅខាងក្រៅ pod ផងដែរ។ ខ្ញុំនៅតែជាអ្នកគាំទ្រកម្មវិធីដែលមានផ្ទុកដោយខ្លួនឯង ពោលគឺអ្នកដែលនៅក្នុងធុងកម្មវិធីដឹងពីរបៀបនាំយកមូលដ្ឋានទិន្នន័យទៅក្នុងស្ថានភាពដែលចង់បានដោយគ្មានការសម្របសម្រួលពីខាងក្រៅ។

4. ប្រើ httpGet សម្រាប់ការត្រួតពិនិត្យការត្រៀមខ្លួនតាមរយៈចំណុចបញ្ចប់ការពិនិត្យសុខភាពធម្មតា (ឧទាហរណ៍ /health).
5. ស្វែងយល់ពីប៉ារ៉ាម៉ែត្រពិនិត្យលំនាំដើម (interval: 10s, timeout: 1s, successThreshold: 1, failureThreshold: 3):
   • ជម្រើសលំនាំដើមមានន័យថា pod នឹងក្លាយជា មិនទាន់​រួចរាល់ បន្ទាប់ពីប្រហែល 30 វិនាទី (ការត្រួតពិនិត្យអនាម័យមិនបានសម្រេចចំនួន 3) ។
6. ប្រើច្រកដាច់ដោយឡែកសម្រាប់ "អ្នកគ្រប់គ្រង" ឬ "ការគ្រប់គ្រង" ប្រសិនបើជង់បច្ចេកវិទ្យា (ឧ. Java/Spring) អនុញ្ញាតឱ្យវាបំបែកការគ្រប់គ្រងសុខភាព និងម៉ែត្រពីចរាចរណ៍ធម្មតា៖
   • ប៉ុន្តែកុំភ្លេចចំណុច 2 ។
7. ប្រសិនបើចាំបាច់ ការស៊ើបអង្កេតការត្រៀមខ្លួនអាចត្រូវបានប្រើដើម្បីកំដៅឡើង/ផ្ទុកឃ្លាំងសម្ងាត់ ហើយត្រឡប់លេខកូដស្ថានភាព 503 រហូតដល់កុងតឺន័រក្តៅឡើង៖
   • ខ្ញុំក៏សូមណែនាំឱ្យអ្នកអានការត្រួតពិនិត្យថ្មី។ startupProbe, បានបង្ហាញខ្លួននៅក្នុងកំណែ 1.16 (យើងបានសរសេរអំពីវាជាភាសារុស្សី នៅទីនេះ - ប្រហែល បកប្រែ។ ).

ដាស់តឿន

1. កុំពឹងផ្អែកលើភាពអាស្រ័យខាងក្រៅ (ដូចជាឃ្លាំងទិន្នន័យ) នៅពេលដំណើរការការធ្វើតេស្តត្រៀមខ្លួន/ការរស់នៅ - នេះអាចនាំឱ្យមានការបរាជ័យជាបន្តបន្ទាប់៖
   • ជាឧទាហរណ៍ ចូរយើងយកសេវា REST រដ្ឋដែលមាន 10 pods អាស្រ័យលើមូលដ្ឋានទិន្នន័យ Postgres មួយ៖ នៅពេលដែលការត្រួតពិនិត្យអាស្រ័យលើការភ្ជាប់ដំណើរការទៅ DB នោះ pods ទាំង 10 អាចនឹងបរាជ័យប្រសិនបើមានការពន្យាពេលនៅលើបណ្តាញ/DB - ជាធម្មតាវា ចុងបញ្ចប់ទាំងអស់អាក្រក់ជាងវាអាចទៅរួច;
   • សូមចំណាំថា Spring Data ពិនិត្យមើលការភ្ជាប់មូលដ្ឋានទិន្នន័យតាមលំនាំដើម*;

     * នេះគឺជាឥរិយាបទលំនាំដើមរបស់ Spring Data Redis (យ៉ាងហោចណាស់វាជាពេលចុងក្រោយដែលខ្ញុំបានពិនិត្យ) ដែលនាំឱ្យមានការបរាជ័យ "មហន្តរាយ"៖ នៅពេលដែល Redis មិនអាចប្រើបានក្នុងរយៈពេលខ្លី ផតទាំងអស់ "គាំង" ។

   • "ខាងក្រៅ" ក្នុងន័យនេះក៏អាចមានន័យថា pods ផ្សេងទៀតនៃកម្មវិធីដូចគ្នា នោះគឺជា, តាមឧត្ដមគតិការត្រួតពិនិត្យមិនគួរអាស្រ័យលើស្ថានភាពនៃ pods ផ្សេងទៀតនៃ cluster ដូចគ្នាដើម្បីការពារការធ្លាក់ cascading:
     • លទ្ធផលអាចប្រែប្រួលសម្រាប់កម្មវិធីដែលមានស្ថានភាពចែកចាយ (ឧទាហរណ៍ ឃ្លាំងសម្ងាត់ក្នុងអង្គចងចាំក្នុងផត)។
2. កុំប្រើឧបករណ៍ស្ទង់ជីវិត សម្រាប់ pods (ករណីលើកលែងគឺជាករណីនៅពេលដែលពួកគេពិតជាចាំបាច់ ហើយអ្នកដឹងច្បាស់អំពីភាពជាក់លាក់ និងផលវិបាកនៃការប្រើប្រាស់របស់ពួកគេ)៖
   • ការស៊ើបអង្កេតភាពរស់រវើកអាចជួយស្ដារធុងដែលព្យួរបាន ប៉ុន្តែដោយសារអ្នកមានការគ្រប់គ្រងពេញលេញលើកម្មវិធីរបស់អ្នក អ្វីៗដូចជាដំណើរការព្យួរ និងការជាប់គាំងមិនគួរកើតឡើងតាមឧត្ដមគតិទេ៖ ជម្រើសដ៏ល្អបំផុតគឺការគាំងកម្មវិធីដោយចេតនា ហើយនាំវាត្រឡប់ទៅសភាពដើមវិញ។
   • ការស៊ើបអង្កេតភាពរស់រវើកដែលបរាជ័យនឹងធ្វើឱ្យកុងតឺន័រចាប់ផ្តើមឡើងវិញ ដោយហេតុនេះអាចធ្វើឱ្យផលប៉ះពាល់នៃកំហុសដែលទាក់ទងនឹងការចាប់ផ្ដើមឡើងវិញមានសក្តានុពល៖ ការចាប់ផ្ដើមកុងតឺន័រឡើងវិញនឹងនាំឱ្យមានការផ្អាក (យ៉ាងហោចណាស់សម្រាប់រយៈពេលនៃការចាប់ផ្តើមកម្មវិធី និយាយថា 30+ វិនាទី) បណ្តាលឱ្យមានកំហុសថ្មី ការបង្កើនការផ្ទុកនៅលើធុងផ្សេងទៀតនិងបង្កើនលទ្ធភាពនៃការបរាជ័យរបស់ពួកគេ, ល។
   • ការត្រួតពិនិត្យភាពរស់រវើករួមបញ្ចូលគ្នាជាមួយនឹងការពឹងផ្អែកខាងក្រៅគឺជាការរួមបញ្ចូលគ្នាដ៏អាក្រក់បំផុតដែលអាចគំរាមកំហែងដល់ការបរាជ័យជាលំៗ៖ ការពន្យារពេលបន្តិចនៅលើផ្នែកមូលដ្ឋានទិន្នន័យនឹងនាំទៅដល់ការចាប់ផ្ដើមធុងរបស់អ្នកទាំងអស់ឡើងវិញ!
3. ប៉ារ៉ាម៉ែត្រនៃភាពរស់រវើកនិងការត្រួតពិនិត្យការត្រៀមខ្លួន ត្រូវតែខុសគ្នា:
   • អ្នកអាចប្រើការស្ទង់មើលភាពរស់រវើកជាមួយនឹងការត្រួតពិនិត្យសុខភាពដូចគ្នា ប៉ុន្តែកម្រិតឆ្លើយតបខ្ពស់ជាង (failureThresholdឧទាហរណ៍ កំណត់ស្ថានភាព មិនទាន់​រួចរាល់ បន្ទាប់ពីការប៉ុនប៉ង 3 ដងហើយពិចារណាថាការស៊ើបអង្កេតរស់បានបរាជ័យបន្ទាប់ពីការប៉ុនប៉ង 10;
4. កុំប្រើការត្រួតពិនិត្យ execចាប់តាំងពីពួកគេត្រូវបានផ្សារភ្ជាប់ជាមួយនឹងបញ្ហាដែលគេស្គាល់ដែលនាំឱ្យមានរូបរាងនៃដំណើរការ zombie:
   • ព័ត៌មានលម្អិត៖ សូមមើល បទបង្ហាញដោយអ្នកឯកទេស Datadog.

សង្ខេប

• ប្រើការស៊ើបអង្កេតការត្រៀមខ្លួនដើម្បីកំណត់ថាតើនៅពេលណាដែលផតផតរួចរាល់ដើម្បីទទួលចរាចរណ៍។
• ប្រើការស៊ើបអង្កេតរស់រវើកតែនៅពេលដែលពួកគេត្រូវការពិតប្រាកដ។
• ការប្រើប្រាស់មិនត្រឹមត្រូវនៃការស៊ើបអង្កេតការត្រៀមខ្លួន/ការរស់រានមានជីវិតអាចនាំឱ្យមានការថយចុះភាពអាចរកបាន និងការបរាជ័យជាបណ្តើរៗ។

សម្ភារៈបន្ថែមលើប្រធានបទ

• ឯកសារ Kubernetes៖ កំណត់រចនាសម្ព័ន្ធការស៊ើបអង្កេតលើភាពរស់រវើក និងការត្រៀមខ្លួន;
• ការស៊ើបអង្កេតលើភាពរស់រវើក និងការត្រៀមខ្លួនរបស់ Kubernetes ត្រូវបានពិនិត្យឡើងវិញ៖ របៀបជៀសវាងការបាញ់ខ្លួនឯងនៅជើងផ្សេងទៀត;
• NRE Labs Outage Post-mortem (គាត់ក៏និយាយអំពី livenessProbe)។

ធ្វើបច្ចុប្បន្នភាពលេខ 1 ពី 2019-09-29

អំពីកុងតឺន័រ init សម្រាប់ការផ្លាស់ប្តូរមូលដ្ឋានទិន្នន័យ៖ បានបន្ថែមលេខយោង។

EJ បានរំលឹកខ្ញុំ អំពី PDB៖ បញ្ហាមួយជាមួយនឹងការត្រួតពិនិត្យជីវិតគឺកង្វះការសម្របសម្រួលរវាងផត។ Kubernetes មាន Pod Disruption Budgets (PDB) ដើម្បីកំណត់ចំនួននៃការបរាជ័យក្នុងពេលដំណាលគ្នា កម្មវិធីអាចជួបប្រទះ ទោះជាយ៉ាងណាក៏ដោយ ការត្រួតពិនិត្យមិនគិតពី PDB ទេ។ តាមឧត្ដមគតិ យើងអាចប្រាប់ K8s ឱ្យ "ចាប់ផ្ដើមផតមួយឡើងវិញ ប្រសិនបើការធ្វើតេស្តរបស់វាបរាជ័យ ប៉ុន្តែកុំចាប់ផ្ដើមពួកវាឡើងវិញទាំងអស់ ដើម្បីចៀសវាងការធ្វើឱ្យអ្វីៗកាន់តែអាក្រក់។"

Bryan ដាក់វាយ៉ាងល្អឥតខ្ចោះ៖ “ប្រើការស្ទង់មើលភាពរស់រវើក នៅពេលអ្នកដឹងច្បាស់ពីអ្វី អ្វីដែលល្អបំផុតដែលត្រូវធ្វើគឺសម្លាប់កម្មវិធី"(ម្តងទៀត កុំយកវាទៅ)។

ធ្វើបច្ចុប្បន្នភាពលេខ 2 ពី 2019-09-29

ទាក់ទងនឹងការអានឯកសារមុនពេលប្រើប្រាស់៖ ខ្ញុំបានបង្កើតសំណើដែលត្រូវគ្នា (សំណើរលក្ខណៈពិសេស) ដើម្បីបន្ថែមឯកសារអំពីការស៊ើបអង្កេតជីវិត។

PS ពីអ្នកបកប្រែ

សូមអានផងដែរនៅលើប្លក់របស់យើង៖

• «Kubernetes: Pod Life»
• «ការអនុវត្តល្អបំផុតចំនួន 7 សម្រាប់ការប្រើប្រាស់កុងតឺន័រយោងទៅតាម Google»
• «7 គោលការណ៍សម្រាប់ការរចនាកម្មវិធីដែលមានមូលដ្ឋានលើកុងតឺន័រ"។

ប្រភព: www.habr.com