Kubernetes හි සජීවී පරීක්ෂණ අනතුරුදායක විය හැකිය

සටහන. පරිවර්තනය.: Zalando හි ප්‍රධාන ඉංජිනේරු Henning Jacobs, සජීවී (සහ සූදානම) පරීක්ෂණවල අරමුණ සහ ඒවායේ නිවැරදි භාවිතය අවබෝධ කර ගැනීමේදී Kubernetes භාවිතා කරන්නන් අතර ගැටලු නැවත නැවතත් දැක ඇත. එමනිසා, ඔහු මෙම ධාරිතාවයෙන් යුත් සටහනෙහි ඔහුගේ සිතුවිලි එකතු කර ඇති අතර, එය අවසානයේ K8s ලේඛනගත කිරීමේ කොටසක් බවට පත්වනු ඇත.

සෞඛ්‍ය පරීක්‍ෂණ, Kubernetes ලෙස හැඳින්වේ සජීවී පරීක්ෂණ (එනම්, වචනාර්ථයෙන්, “ශක්‍යතා පරීක්ෂණ” - දළ වශයෙන් පරිවර්තනය.), තරමක් භයානක විය හැක. හැකි නම් ඒවා වළක්වා ගැනීමට මම නිර්දේශ කරමි: ව්‍යතිරේකයක් වන්නේ ඒවා සැබවින්ම අවශ්‍ය වූ විට සහ ඒවායේ භාවිතයේ විශේෂතා සහ ප්‍රතිවිපාක පිළිබඳව ඔබ සම්පූර්ණයෙන්ම දැනුවත් ය. මෙම ප්‍රකාශනය සජීවී බව සහ සූදානම පරීක්ෂා කිරීම ගැන කතා කරනු ඇති අතර, කුමන අවස්ථා වලදීද යන්න ඔබට කියනු ඇත වටිනවා සහ ඔබ ඒවා භාවිතා නොකළ යුතුය.

මගේ සගයා වන සැන්ඩෝර් මෑතකදී ට්විටර් හි ඔහු මුහුණ දෙන වඩාත් පොදු දෝෂ, සූදානම/සජීවී පරීක්ෂණ භාවිතයට අදාළ ඒවා ඇතුළුව බෙදාගත්තේය:

වැරදි ලෙස වින්‍යාස කර ඇත livenessProbe ඉහළ බරක් ඇති තත්ත්වයන් උග්‍ර කළ හැකිය (හිමබෝල වසා දැමීම + දිගු බහාලුම්/යෙදුම් ආරම්භක කාලය) සහ පරායත්තතා පහත වැටීම් වැනි වෙනත් සෘණාත්මක ප්‍රතිවිපාකවලට තුඩු දිය හැකිය (මෙයද බලන්න මගේ මෑත ලිපිය K3s+ACME සංයෝජනයේ ඉල්ලීම් ගණන සීමා කිරීම ගැන). සජීවී පරීක්ෂණය බාහිර දත්ත ගබඩාවක් වන සෞඛ්‍ය පරීක්‍ෂණයක් සමඟ ඒකාබද්ධ වූ විට එය වඩාත් නරක ය: එක් DB අසාර්ථක වීමක් ඔබගේ සියලුම බහාලුම් නැවත ආරම්භ කරනු ඇත!

සාමාන්ය පණිවිඩය "සජීවී පරීක්ෂණ භාවිතා නොකරන්න" මෙම අවස්ථාවේ දී එය බොහෝ සෙයින් උපකාරී නොවේ, එබැවින් සූදානම සහ සජීවී පරීක්ෂාවන් කුමක් සඳහා දැයි බලමු.

සටහන: පහත පරීක්‍ෂණයෙන් බොහොමයක් මුලින් Zalando හි අභ්‍යන්තර සංවර්ධක ලේඛනගත කර ඇත.

සූදානම සහ සජීවී බව පරීක්ෂා කිරීම

Kubernetes නමින් හැඳින්වෙන වැදගත් යාන්ත්‍රණ දෙකක් සපයයි සජීවී පරීක්ෂණ සහ සූදානම පරීක්ෂණ. යෙදුම අපේක්ෂිත පරිදි ක්‍රියා කරන බව තහවුරු කිරීම සඳහා ඔවුන් වරින් වර HTTP ඉල්ලීමක් යැවීම, TCP සම්බන්ධතාවයක් විවෘත කිරීම හෝ බහාලුම් තුළ විධානයක් ක්‍රියාත්මක කිරීම වැනි යම් ක්‍රියාවක් සිදු කරයි.

Kubernetes භාවිතා කරයි සූදානම පරීක්ෂණකන්ටේනරය ගමනාගමනය පිළිගැනීමට සූදානම් වන විට තේරුම් ගැනීමට. කරලක් එහි සියලුම බහාලුම් සූදානම් නම් භාවිතයට සූදානම් යැයි සැලකේ. මෙම යාන්ත්‍රණයේ එක් ප්‍රයෝජනයක් වන්නේ 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 වැනි) ගමනාගමනය පිළිගැනීමට සූදානම් නම් පමණක් අවසන් ලක්ෂ්‍යය OK ලබා දෙන බවට වග බලා ගන්න*;

     *මෙය සිදු නොවූ Zalando හි අවම වශයෙන් එක් සිද්ධියක් ගැන මම දනිමි, එනම්. readinessProbe මම "කළමනාකරණ" වරාය පරීක්ෂා කළෙමි, නමුත් හැඹිලිය පැටවීමේ ගැටළු හේතුවෙන් සේවාදායකයම වැඩ කිරීමට පටන් ගත්තේ නැත.

   • වෙනම වරායකට සූදානම පරීක්ෂණයක් ඇමිණීමෙන් ප්‍රධාන වරායේ අධික බර සෞඛ්‍ය පරීක්‍ෂණයෙන් පිළිබිඹු නොවනු ඇත (එනම්, සේවාදායකයේ නූල් සංචිතය පිරී ඇත, නමුත් සෞඛ්‍ය පරීක්‍ෂණය තවමත් සියල්ල හරි බව පෙන්වයි )
3. එය සහතික කර ගන්න සූදානම විමර්ශනය මඟින් දත්ත සමුදාය ආරම්භ කිරීම/සංක්‍රමණය සක්‍රීය කරයි;
   • මෙය සාක්ෂාත් කර ගැනීමට ඇති පහසුම ක්‍රමය නම් ආරම්භ කිරීම සම්පූර්ණ වූ පසුව පමණක් HTTP සේවාදායකය සම්බන්ධ කර ගැනීමයි (උදාහරණයක් ලෙස, දත්ත සමුදායක් සංක්‍රමණය කිරීම පියාසර මාර්ගය සහ යනාදි.); එනම්, සෞඛ්‍ය පිරික්සුම් තත්ත්වය වෙනස් කරනවා වෙනුවට, දත්ත සමුදා සංක්‍රමණය සම්පූර්ණ වන තෙක් වෙබ් සේවාදායකය ආරම්භ නොකරන්න*.

     * ඔබට Pod එකෙන් පිටත init බහාලුම් වලින් දත්ත සමුදා සංක්‍රමණයන් ද ධාවනය කළ හැක. මම තවමත් ස්වයං අන්තර්ගත යෙදුම්වල රසිකයෙක්, එනම් බාහිර සම්බන්ධීකරණයකින් තොරව දත්ත සමුදාය අපේක්ෂිත තත්වයට ගෙන එන්නේ කෙසේදැයි යෙදුම් බහාලුම දන්නා ඒවාය.

4. භාවිත httpGet සාමාන්‍ය සෞඛ්‍ය පිරික්සුම් අන්ත ලක්ෂ්‍ය හරහා සූදානම පරීක්ෂා කිරීම සඳහා (උදාහරණයක් ලෙස, /health).
5. පෙරනිමි පිරික්සුම් පරාමිතීන් තේරුම් ගන්න (interval: 10s, timeout: 1s, successThreshold: 1, failureThreshold: 3):
   • පෙරනිමි විකල්ප වලින් අදහස් වන්නේ පොඩ් බවට පත් වනු ඇති බවයි සුදානම් නැ තත්පර 30කට පමණ පසු (3 අසාර්ථක වූ සනීපාරක්ෂාව පරීක්ෂා කිරීම).
6. සාමාන්‍ය ගමනාගමනයෙන් සෞඛ්‍ය සහ ප්‍රමිතික කළමනාකරණය වෙන් කිරීමට තාක්‍ෂණ තොගය (උදා: Java/Spring) එයට ඉඩ දෙන්නේ නම්, "පරිපාලක" හෝ "කළමනාකරණය" සඳහා වෙනම වරායක් භාවිතා කරන්න:
   • නමුත් 2 වන කරුණ ගැන අමතක නොකරන්න.
7. අවශ්‍ය නම්, කැචය උණුසුම් කිරීමට/පූරණය කිරීමට සහ කන්ටේනරය උණුසුම් වන තෙක් 503 තත්ව කේතයක් ලබා දීමට සූදානම පරීක්ෂාව භාවිතා කළ හැක:
   • ඔබ නව චෙක්පත කියවන ලෙසද මම නිර්දේශ කරමි startupProbe, 1.16 අනුවාදයේ පෙනී සිටියේය (අපි ඒ ගැන රුසියානු භාෂාවෙන් ලිව්වා මෙහි - ආසන්න වශයෙන්. පරිවර්තනය.).

රැවටි

1. බාහිර යැපීම් මත රඳා නොසිටින්න (දත්ත ගබඩා වැනි) සූදානම/සජීවී පරීක්ෂණ ක්‍රියාත්මක වන විට - මෙය කඩා වැටීමේ අසාර්ථකත්වයට හේතු විය හැක:
   • උදාහරණයක් ලෙස, එක් Postgres දත්ත සමුදායක් මත පදනම්ව පොඩ් 10 ක් සහිත රාජ්‍ය REST සේවාවක් ගනිමු: චෙක්පත DB වෙත ක්‍රියාකාරී සම්බන්ධතාවයක් මත රඳා පවතින විට, ජාලය/DB පැත්තේ ප්‍රමාදයක් තිබේ නම්, සියලුම කරල් 10 අසාර්ථක විය හැක - සාමාන්‍යයෙන් එය සියල්ලට වඩා නරක ලෙස අවසන් වේ;
   • වසන්ත දත්ත පෙරනිමියෙන් දත්ත සමුදා සම්බන්ධතාවය පරීක්ෂා කරන බව කරුණාවෙන් සලකන්න*;

     * මෙය Spring Data Redis හි පෙරනිමි හැසිරීමයි (අවම වශයෙන් එය මා පරීක්ෂා කළ අවසන් අවස්ථාවයි), එය "ව්‍යසනකාරී" අසාර්ථකත්වයට හේතු විය: කෙටි කාලයක් සඳහා Redis නොමැති වූ විට, සියලු කරල් "කඩා වැටුණි".

   • මෙම අර්ථයෙන් "බාහිර" යන්නෙන් එකම යෙදුමේ වෙනත් කරල් ද අදහස් විය හැකිය, එනම්, කැස්කැඩිං බිඳ වැටීම් වැළැක්වීම සඳහා චෙක්පත එකම පොකුරේ අනෙකුත් කරල්වල තත්වය මත රඳා නොසිටිය යුතුය:
     • බෙදා හරින ලද තත්වය සහිත යෙදුම් සඳහා ප්‍රතිඵල වෙනස් විය හැක (උදාහරණයක් ලෙස, කරල් වල මතකයේ හැඹිලිගත කිරීම).
2. සජීවී පරීක්ෂණයක් භාවිතා නොකරන්න කරල් සඳහා (ව්‍යතිරේක යනු ඒවා සැබවින්ම අවශ්‍ය වන අවස්ථා වන අතර ඒවායේ භාවිතයේ විශේෂතා සහ ප්‍රතිවිපාක පිළිබඳව ඔබ සම්පූර්ණයෙන් දන්නා):
   • සජීවී පරීක්ෂණයක් එල්ලා ඇති බහාලුම් ප්‍රතිසාධනය කිරීමට උදවු විය හැක, නමුත් ඔබට ඔබගේ යෙදුමේ පූර්ණ පාලනය ඇති බැවින්, එල්ලෙන ක්‍රියාවලි සහ අවහිර කිරීම් වැනි දේවල් ඉතා මැනවින් සිදු නොවිය යුතුය: හොඳම විකල්පය වන්නේ හිතාමතාම යෙදුම බිඳ දමා පෙර ස්ථාවර තත්වයට ගෙන ඒමයි;
   • අසාර්ථක සජීවී පරීක්ෂණයක් කන්ටේනරය නැවත ආරම්භ කිරීමට හේතු වනු ඇත, එමඟින් පැටවීම සම්බන්ධ දෝෂවල ප්‍රතිවිපාක උග්‍ර කළ හැකිය: කන්ටේනරය නැවත ආරම්භ කිරීම අක්‍රීය වීමට හේතු වේ (අවම වශයෙන් යෙදුම් ආරම්භයේ කාලසීමාව සඳහා, තත්පර 30-ඔත්තේ) නව දෝෂ ඇති කරයි , අනෙකුත් බහාලුම් මත බර වැඩි කිරීම සහ ඔවුන්ගේ අසාර්ථක වීමේ සම්භාවිතාව වැඩි කිරීම ආදිය.
   • බාහිර පරායත්තතාවක් සමඟ සංයෝජිත සජීවී චෙක්පත් විය හැකි නරකම සංයෝජනයකි, කඳුරැල්ල අසාර්ථක වීමට තර්ජනය කරයි: දත්ත සමුදාය පැත්තේ සුළු ප්‍රමාදයක් ඔබගේ සියලුම බහාලුම් නැවත ආරම්භ කිරීමට හේතු වේ!
3. සජීවී බව සහ සූදානම පරීක්ෂා කිරීමේ පරාමිතීන් වෙනස් විය යුතුය:
   • ඔබට එම සෞඛ්‍ය පරීක්ෂාව සමඟ සජීවී පරීක්ෂණයක් භාවිතා කළ හැකිය, නමුත් ඉහළ ප්‍රතිචාර සීමාවක් (failureThreshold), උදාහරණයක් ලෙස, තත්ත්වය පවරන්න සුදානම් නැ උත්සාහයන් 3 කට පසුව සහ උත්සාහයන් 10 කට පසු සජීවී පරීක්ෂණය අසාර්ථක වූ බව සලකන්න;
4. exec චෙක්පත් භාවිතා නොකරන්න, ඒවා zombie ක්‍රියාවලීන්ගේ පෙනුමට තුඩු දෙන දන්නා ගැටළු සමඟ සම්බන්ධ වී ඇති බැවින්:
   • විස්තර: බලන්න Datadog විශේෂඥයින් විසින් ඉදිරිපත් කිරීම.

සාරාංශය

• පොඩ් එකක් ගමනාගමනය ලැබීමට සූදානම් වන්නේ කවදාද යන්න තීරණය කිරීමට සූදානම පරීක්ෂණ භාවිත කරන්න.
• සජීවී පරීක්ෂණ ඇත්තටම අවශ්‍ය වූ විට පමණක් භාවිතා කරන්න.
• සූදානම/සජීවී පරීක්ෂණ අනිසි ලෙස භාවිතා කිරීම ලබා ගැනීමේ හැකියාව අඩුවීමට සහ කඩා වැටීමේ අසාර්ථකත්වයට හේතු විය හැක.

මාතෘකාව පිළිබඳ අතිරේක ද්‍රව්‍ය

• Kubernetes docs: Liveness සහ Readiness Probes වින්‍යාස කරන්න;
• Kubernetes Liveness සහ Readiness Probes Revisited: අනෙක් පාදයට වෙඩි තැබීමෙන් වැළකී සිටින්නේ කෙසේද?;
• NRE රසායනාගාර ඇනහිටීම් පශ්චාත් මරණ පරීක්ෂණය (ඔහු livenessProbe ගැනද කතා කරයි).

1-2019-09 සිට අංක 29 යාවත්කාලීන කරන්න

දත්ත සමුදා සංක්‍රමණය සඳහා init බහාලුම් ගැන: පාද සටහන එකතු කරන ලදී.

EJ මට මතක් කළා PDB ගැන: සජීවී චෙක්පත් වල එක් ගැටළුවක් වන්නේ කරල් අතර සම්බන්ධීකරණය නොමැතිකමයි. Kubernetes සතුව ඇත Pod Disruption Budgets (PDB) යෙදුමකට අත්විඳිය හැකි සමගාමී අසමත්වීම් සංඛ්‍යාව සීමා කිරීමට, කෙසේ වෙතත් චෙක්පත් PDB සැලකිල්ලට නොගනී. ඉතා මැනවින්, අපට K8s වලට පැවසිය හැක්කේ "එක් පොඩ් එකක් එහි පරීක්ෂණය අසාර්ථක වුවහොත් නැවත ආරම්භ කරන්න, නමුත් තත්වය නරක අතට හැරීම වැළැක්වීම සඳහා ඒවා සියල්ලම නැවත ආරම්භ නොකරන්න."

බ්‍රයන් ඒක නියමෙටම දැම්මා: "ඔබ හරියටම දන්නා විට සජීවී පරීක්ෂණ භාවිතා කරන්න හොඳම දෙය නම් යෙදුම විනාශ කිරීමයි"(නැවතත්, රැගෙන යන්න එපා).

2-2019-09 සිට අංක 29 යාවත්කාලීන කරන්න

භාවිතයට පෙර ලේඛන කියවීම සම්බන්ධයෙන්: මම අදාල ඉල්ලීම හැදුවා (විශේෂාංග ඉල්ලීම) සජීවී පරීක්ෂණ පිළිබඳ ලේඛන එකතු කිරීමට.

පරිවර්තකගෙන් PS

අපගේ බ්ලොග් අඩවියේ ද කියවන්න:

• «Kubernetes: Pod Life»;
• «Google අනුව බහාලුම් භාවිතා කිරීම සඳහා හොඳම භාවිතයන් 7 ක්»;
• «බහාලුම් පාදක යෙදුම් සැලසුම් කිරීම සඳහා 7 මූලධර්ම".

මූලාශ්රය: www.habr.com