കുബർനെറ്റസിലെ ലൈവ്‌നെസ് പ്രോബുകൾ അപകടകരമാണ്

കുറിപ്പ്. വിവർത്തനം.: സലാൻഡോയിൽ നിന്നുള്ള ലീഡ് എഞ്ചിനീയർ, ഹെന്നിംഗ് ജേക്കബ്സ്, കുബർനെറ്റസ് ഉപയോക്താക്കൾക്കിടയിൽ ലൈവനെസ് (ഒപ്പം സന്നദ്ധത) പേടകങ്ങളുടെ ഉദ്ദേശ്യവും അവയുടെ ശരിയായ ഉപയോഗവും മനസ്സിലാക്കുന്നതിൽ പ്രശ്നങ്ങൾ ആവർത്തിച്ച് ശ്രദ്ധിച്ചിട്ടുണ്ട്. അതിനാൽ, ഈ ശേഷിയുള്ള കുറിപ്പിൽ അദ്ദേഹം തൻ്റെ ചിന്തകൾ ശേഖരിച്ചു, അത് ഒടുവിൽ K8s ഡോക്യുമെൻ്റേഷൻ്റെ ഭാഗമാകും.

ആരോഗ്യ പരിശോധനകൾ, കുബർനെറ്റുകളിൽ അറിയപ്പെടുന്നത് ജീവനുള്ള അന്വേഷണങ്ങൾ (അതായത്, അക്ഷരാർത്ഥത്തിൽ, "വയബിലിറ്റി ടെസ്റ്റുകൾ" - ഏകദേശം. വിവർത്തനം.), തികച്ചും അപകടകരമായേക്കാം. സാധ്യമെങ്കിൽ അവ ഒഴിവാക്കാൻ ഞാൻ ശുപാർശ ചെയ്യുന്നു: അവ ശരിക്കും ആവശ്യമുള്ളപ്പോൾ മാത്രമാണ് ഒഴിവാക്കലുകൾ, അവയുടെ ഉപയോഗത്തിൻ്റെ പ്രത്യേകതകളും അനന്തരഫലങ്ങളും നിങ്ങൾക്ക് പൂർണ്ണമായി അറിയാം. ഈ പ്രസിദ്ധീകരണം സജീവതയെയും സന്നദ്ധതയെയും കുറിച്ച് സംസാരിക്കും, കൂടാതെ ഏതൊക്കെ സന്ദർഭങ്ങളിൽ നിങ്ങളോട് പറയും അതു വിലമതിക്കുന്നു നിങ്ങൾ അവ ഉപയോഗിക്കരുത്.

എൻ്റെ സഹപ്രവർത്തകനായ സാൻഡോർ ഈയിടെ ട്വിറ്ററിൽ താൻ അഭിമുഖീകരിക്കുന്ന ഏറ്റവും സാധാരണമായ പിശകുകൾ പങ്കിട്ടു, റെഡിനെസ്/ലൈവ്നെസ് പ്രോബുകളുടെ ഉപയോഗവുമായി ബന്ധപ്പെട്ടവ ഉൾപ്പെടെ:

തെറ്റായി ക്രമീകരിച്ചിരിക്കുന്നു livenessProbe ഉയർന്ന ലോഡ് സാഹചര്യങ്ങൾ (സ്നോബോൾ ഷട്ട്ഡൗൺ + ദൈർഘ്യമേറിയ കണ്ടെയ്നർ/ആപ്ലിക്കേഷൻ സ്റ്റാർട്ടപ്പ് സമയം) വർദ്ധിപ്പിക്കുകയും ഡിപൻഡൻസി ഡ്രോപ്പുകൾ പോലുള്ള മറ്റ് നെഗറ്റീവ് പ്രത്യാഘാതങ്ങളിലേക്ക് നയിക്കുകയും ചെയ്യും (ഇതും കാണുക എൻ്റെ സമീപകാല ലേഖനം K3s+ACME കോമ്പിനേഷനിലെ അഭ്യർത്ഥനകളുടെ എണ്ണം പരിമിതപ്പെടുത്തുന്നതിനെക്കുറിച്ച്). ഒരു ബാഹ്യ ഡാറ്റാബേസായ ആരോഗ്യ പരിശോധനയുമായി ലൈവ്‌നെസ് പ്രോബ് സംയോജിപ്പിക്കുമ്പോൾ ഇത് കൂടുതൽ മോശമാണ്: ഒരൊറ്റ DB പരാജയം നിങ്ങളുടെ എല്ലാ കണ്ടെയ്‌നറുകളും പുനരാരംഭിക്കും!

പൊതുവായ സന്ദേശം "ജീവനുള്ള പേടകങ്ങൾ ഉപയോഗിക്കരുത്" ഈ സാഹചര്യത്തിൽ ഇത് കാര്യമായി സഹായിക്കില്ല, അതിനാൽ സന്നദ്ധതയും ജീവനുള്ള പരിശോധനയും എന്തിനുവേണ്ടിയാണെന്ന് നോക്കാം.

ശ്രദ്ധിക്കുക: ചുവടെയുള്ള മിക്ക ടെസ്റ്റുകളും യഥാർത്ഥത്തിൽ സലാൻഡോയുടെ ആന്തരിക ഡെവലപ്പർ ഡോക്യുമെൻ്റേഷനിൽ ഉൾപ്പെടുത്തിയിട്ടുണ്ട്.

സന്നദ്ധതയും സജീവതയും പരിശോധിക്കുന്നു

കുബെർനെറ്റസ് രണ്ട് പ്രധാന സംവിധാനങ്ങൾ നൽകുന്നു ജീവനുള്ള പേടകങ്ങളും റെഡിനെസ് പേടകങ്ങളും. അവർ ആനുകാലികമായി ചില പ്രവർത്തനങ്ങൾ ചെയ്യുന്നു-ഒരു HTTP അഭ്യർത്ഥന അയയ്ക്കുക, ഒരു TCP കണക്ഷൻ തുറക്കുക, അല്ലെങ്കിൽ കണ്ടെയ്നറിൽ ഒരു കമാൻഡ് എക്സിക്യൂട്ട് ചെയ്യുക-ആപ്ലിക്കേഷൻ പ്രതീക്ഷിച്ചതുപോലെ പ്രവർത്തിക്കുന്നുവെന്ന് സ്ഥിരീകരിക്കുക.

കുബെർനെറ്റസ് ഉപയോഗിക്കുന്നു സന്നദ്ധത പേടകങ്ങൾട്രാഫിക് സ്വീകരിക്കാൻ കണ്ടെയ്നർ തയ്യാറാകുമ്പോൾ മനസ്സിലാക്കാൻ. ഒരു പോഡ് അതിൻ്റെ എല്ലാ പാത്രങ്ങളും തയ്യാറാണെങ്കിൽ ഉപയോഗത്തിന് തയ്യാറാണെന്ന് കണക്കാക്കുന്നു. കുബെർനെറ്റസ് സേവനങ്ങൾക്ക് (പ്രത്യേകിച്ച് ഇൻഗ്രെസ്സ്) ബാക്കെൻഡുകളായി ഉപയോഗിക്കുന്ന പോഡുകൾ നിയന്ത്രിക്കുക എന്നതാണ് ഈ സംവിധാനത്തിൻ്റെ ഒരു ഉപയോഗം.

ലൈവ്നെസ് പ്രോബുകൾ കണ്ടെയ്നർ പുനരാരംഭിക്കാനുള്ള സമയമായെന്ന് മനസ്സിലാക്കാൻ കുബർനെറ്റുകളെ സഹായിക്കുക. ഉദാഹരണത്തിന്, ഒരു ആപ്ലിക്കേഷൻ ഒരിടത്ത് കുടുങ്ങിക്കിടക്കുമ്പോൾ ഒരു ഡെഡ്‌ലോക്ക് തടസ്സപ്പെടുത്താൻ അത്തരമൊരു പരിശോധന നിങ്ങളെ അനുവദിക്കുന്നു. ഈ അവസ്ഥയിൽ കണ്ടെയ്‌നർ പുനരാരംഭിക്കുന്നത് പിശകുകൾക്കിടയിലും ആപ്ലിക്കേഷൻ നിലത്തുറപ്പിക്കുന്നതിന് സഹായിക്കുന്നു, പക്ഷേ ഇത് കാസ്കേഡിംഗ് പരാജയങ്ങളിലേക്കും നയിച്ചേക്കാം (ചുവടെ കാണുക).

ലൈവ്‌നസ്/റെഡിനസ് പരിശോധനകൾ പരാജയപ്പെടുന്ന ഒരു ആപ്ലിക്കേഷൻ അപ്‌ഡേറ്റ് വിന്യസിക്കാൻ നിങ്ങൾ ശ്രമിക്കുകയാണെങ്കിൽ, കുബർനെറ്റസ് സ്റ്റാറ്റസിനായി കാത്തിരിക്കുന്നതിനാൽ അതിൻ്റെ റോൾഔട്ട് സ്തംഭിക്കും. Ready എല്ലാ കായ്കളിൽ നിന്നും.

ഉദാഹരണം:

ഒരു പാത്ത് പരിശോധിക്കുന്നതിനുള്ള ഒരു റെഡിനെസ് പ്രോബിൻ്റെ ഒരു ഉദാഹരണം ഇതാ /health സ്ഥിരസ്ഥിതി ക്രമീകരണങ്ങളുള്ള HTTP വഴി (ഇടവേള: 10 സെക്കൻഡ്, ടൈം ഔട്ട്: 1 സെക്കൻഡ്, വിജയത്തിൻ്റെ പരിധി: 1, പരാജയത്തിൻ്റെ പരിധി: 3):

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

ശുപാർശകൾ

1. എച്ച്ടിടിപി എൻഡ്‌പോയിൻ്റുള്ള മൈക്രോ സർവീസുകൾക്കായി (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 സേവനം എടുക്കാം: ചെക്ക് ഡിബിയിലേക്കുള്ള പ്രവർത്തന കണക്ഷനെ ആശ്രയിച്ചിരിക്കുമ്പോൾ, നെറ്റ്‌വർക്ക്/ഡിബി ഭാഗത്ത് കാലതാമസം ഉണ്ടായാൽ എല്ലാ 10 പോഡുകളും പരാജയപ്പെടാം - സാധാരണയായി ഇത് എല്ലാം കഴിയുന്നതിനേക്കാൾ മോശമായി അവസാനിക്കുന്നു;
   • സ്പ്രിംഗ് ഡാറ്റ സ്ഥിരസ്ഥിതിയായി ഡാറ്റാബേസ് കണക്ഷൻ പരിശോധിക്കുന്നുവെന്നത് ശ്രദ്ധിക്കുക*;

     * ഇത് സ്പ്രിംഗ് ഡാറ്റ റെഡിസിൻ്റെ സ്ഥിരസ്ഥിതി സ്വഭാവമാണ് (കുറഞ്ഞത് ഞാൻ അവസാനമായി പരിശോധിച്ചത്), ഇത് ഒരു "ദുരന്ത" പരാജയത്തിലേക്ക് നയിച്ചു: റെഡിസ് കുറച്ച് സമയത്തേക്ക് ലഭ്യമല്ലാത്തപ്പോൾ, എല്ലാ പോഡുകളും "തകരുന്നു".

   • ഈ അർത്ഥത്തിൽ "ബാഹ്യ" എന്നതിന് ഒരേ ആപ്ലിക്കേഷൻ്റെ മറ്റ് പോഡുകളും അർത്ഥമാക്കാം, അതായത്, കാസ്കേഡിംഗ് ക്രാഷുകൾ തടയുന്നതിന് ഒരേ ക്ലസ്റ്ററിലെ മറ്റ് പോഡുകളുടെ അവസ്ഥയെ ആശ്രയിക്കരുത്.
     • വിതരണം ചെയ്ത നിലയിലുള്ള ആപ്ലിക്കേഷനുകളുടെ ഫലങ്ങൾ വ്യത്യാസപ്പെടാം (ഉദാഹരണത്തിന്, പോഡുകളിലെ ഇൻ-മെമ്മറി കാഷിംഗ്).
2. ലൈവ്നെസ് പ്രോബ് ഉപയോഗിക്കരുത് പോഡുകൾക്ക് (ഒഴിവാക്കലുകൾ അവ ശരിക്കും ആവശ്യമുള്ള സന്ദർഭങ്ങളാണ്, മാത്രമല്ല അവയുടെ ഉപയോഗത്തിൻ്റെ പ്രത്യേകതകളും അനന്തരഫലങ്ങളും നിങ്ങൾക്ക് പൂർണ്ണമായി അറിയാം):
   • ഒരു ലൈവ്‌നെസ് പ്രോബ് ഹാംഗ് കണ്ടെയ്‌നറുകൾ വീണ്ടെടുക്കാൻ സഹായിക്കും, എന്നാൽ നിങ്ങളുടെ ആപ്ലിക്കേഷൻ്റെ മേൽ നിങ്ങൾക്ക് പൂർണ്ണ നിയന്ത്രണമുള്ളതിനാൽ, ഹാംഗ് പ്രോസസുകളും ഡെഡ്‌ലോക്കുകളും പോലെയുള്ള കാര്യങ്ങൾ സംഭവിക്കരുത്: മനഃപൂർവ്വം ആപ്ലിക്കേഷൻ ക്രാഷ് ചെയ്ത് പഴയ സ്ഥിരതയിലേക്ക് കൊണ്ടുവരുന്നതാണ് മികച്ച ബദൽ;
   • പരാജയപ്പെട്ട ലൈവ്‌നെസ് അന്വേഷണം കണ്ടെയ്‌നർ പുനരാരംഭിക്കുന്നതിന് കാരണമാകും, അതുവഴി ലോഡിംഗുമായി ബന്ധപ്പെട്ട പിശകുകളുടെ അനന്തരഫലങ്ങൾ വർദ്ധിപ്പിക്കും: കണ്ടെയ്‌നർ പുനരാരംഭിക്കുന്നത് പ്രവർത്തനരഹിതമാക്കും (കുറഞ്ഞത് ആപ്ലിക്കേഷൻ സ്റ്റാർട്ടപ്പിൻ്റെ സമയത്തേക്ക്, 30-ഒറ്റ സെക്കൻഡ് എങ്കിലും) പുതിയ പിശകുകൾക്ക് കാരണമാകും. , മറ്റ് കണ്ടെയ്നറുകളിൽ ലോഡ് വർദ്ധിപ്പിക്കുകയും അവരുടെ പരാജയത്തിൻ്റെ സാധ്യത വർദ്ധിപ്പിക്കുകയും ചെയ്യുക തുടങ്ങിയവ.
   • ഒരു ബാഹ്യ ആശ്രിതത്വവുമായി സംയോജിപ്പിച്ച ലൈവ്‌നസ് പരിശോധനകൾ സാധ്യമായ ഏറ്റവും മോശമായ സംയോജനമാണ്, കാസ്‌കേഡിംഗ് പരാജയങ്ങളെ ഭീഷണിപ്പെടുത്തുന്നു: ഡാറ്റാബേസ് വശത്ത് ഒരു ചെറിയ കാലതാമസം നിങ്ങളുടെ എല്ലാ കണ്ടെയ്‌നറുകളും പുനരാരംഭിക്കുന്നതിലേക്ക് നയിക്കും!
3. സജീവതയുടെയും സന്നദ്ധതയുടെയും പാരാമീറ്ററുകൾ വ്യത്യസ്തമായിരിക്കണം:
   • അതേ ആരോഗ്യ പരിശോധന ഉപയോഗിച്ച് നിങ്ങൾക്ക് ഒരു ലൈവ്നെസ് പ്രോബ് ഉപയോഗിക്കാം, എന്നാൽ ഉയർന്ന പ്രതികരണ പരിധി (failureThreshold), ഉദാഹരണത്തിന്, സ്റ്റാറ്റസ് അസൈൻ ചെയ്യുക തയ്യാറല്ല 3 ശ്രമങ്ങൾക്ക് ശേഷം, 10 ശ്രമങ്ങൾക്ക് ശേഷം ലൈവ്നെസ് അന്വേഷണം പരാജയപ്പെട്ടുവെന്ന് പരിഗണിക്കുക;
4. എക്സിക് ചെക്കുകൾ ഉപയോഗിക്കരുത്, അവ സോംബി പ്രക്രിയകളുടെ രൂപത്തിലേക്ക് നയിക്കുന്ന അറിയപ്പെടുന്ന പ്രശ്നങ്ങളുമായി ബന്ധപ്പെട്ടിരിക്കുന്നതിനാൽ:
   • വിശദാംശങ്ങൾ: കാണുക ഡാറ്റാഡോഗ് സ്പെഷ്യലിസ്റ്റുകളുടെ അവതരണം.

സംഗ്രഹം

• ഒരു പോഡ് ട്രാഫിക് സ്വീകരിക്കാൻ തയ്യാറാകുമ്പോൾ നിർണ്ണയിക്കാൻ റെഡിനെസ് പ്രോബുകൾ ഉപയോഗിക്കുക.
• ലൈവ്നെസ് പ്രോബുകൾ ശരിക്കും ആവശ്യമുള്ളപ്പോൾ മാത്രം ഉപയോഗിക്കുക.
• റെഡിനെസ്/ലൈവ്‌നെസ് പ്രോബുകളുടെ തെറ്റായ ഉപയോഗം ലഭ്യത കുറയുന്നതിനും കാസ്‌കേഡിംഗ് പരാജയങ്ങൾക്കും ഇടയാക്കും.

വിഷയത്തെക്കുറിച്ചുള്ള അധിക മെറ്റീരിയലുകൾ

• കുബർനെറ്റസ് ഡോക്‌സ്: ലൈവ്‌നെസും റെഡിനെസ് പ്രോബുകളും കോൺഫിഗർ ചെയ്യുക;
• കുബെർനെറ്റസ് ലൈവ്‌നെസ് ആൻഡ് റെഡിനെസ് പ്രോബ്‌സ് വീണ്ടും സന്ദർശിച്ചു: മറ്റേ കാലിൽ സ്വയം വെടിവയ്ക്കുന്നത് എങ്ങനെ ഒഴിവാക്കാം;
• എൻആർഇ ലാബുകളുടെ തകർച്ച പോസ്റ്റ്‌മോർട്ടം (അവൻ livenessProbe-നെക്കുറിച്ചും സംസാരിക്കുന്നു).

1-2019-09 മുതൽ നമ്പർ 29 അപ്ഡേറ്റ് ചെയ്യുക

ഡാറ്റാബേസ് മൈഗ്രേഷനുള്ള init കണ്ടെയ്‌നറുകളെ കുറിച്ച്: അടിക്കുറിപ്പ് ചേർത്തു.

ഇ.ജെ ഓർമ്മിപ്പിച്ചു PDB-യെ കുറിച്ച്: ലൈവ്‌നെസ് ചെക്കുകളിലെ പ്രശ്‌നങ്ങളിലൊന്ന് പോഡുകൾ തമ്മിലുള്ള ഏകോപനത്തിൻ്റെ അഭാവമാണ്. കുബെർനെറ്റസിന് ഉണ്ട് പോഡ് ഡിസ്റപ്ഷൻ ബഡ്ജറ്റുകൾ (PDB) ഒരു ആപ്ലിക്കേഷന് അനുഭവിക്കേണ്ടി വരുന്ന കൺകറൻ്റ് പരാജയങ്ങളുടെ എണ്ണം പരിമിതപ്പെടുത്താൻ, എന്നിരുന്നാലും പരിശോധനകൾ PDB കണക്കിലെടുക്കുന്നില്ല. "പരീക്ഷ പരാജയപ്പെട്ടാൽ ഒരു പോഡ് പുനരാരംഭിക്കുക, എന്നാൽ കാര്യങ്ങൾ കൂടുതൽ വഷളാക്കാതിരിക്കാൻ അവയെല്ലാം പുനരാരംഭിക്കരുത്" എന്ന് നമുക്ക് K8-കളോട് പറയാൻ കഴിയും.

ബ്രയാൻ അത് നന്നായി വെച്ചു: “നിങ്ങൾക്ക് കൃത്യമായി എന്താണെന്ന് അറിയുമ്പോൾ ലൈവ്നെസ് പ്രോബിംഗ് ഉപയോഗിക്കുക ആപ്ലിക്കേഷൻ ഇല്ലാതാക്കുക എന്നതാണ് ഏറ്റവും നല്ല കാര്യം"(വീണ്ടും, കൊണ്ടുപോകരുത്).

2-2019-09 മുതൽ നമ്പർ 29 അപ്ഡേറ്റ് ചെയ്യുക

ഉപയോഗിക്കുന്നതിന് മുമ്പ് ഡോക്യുമെൻ്റേഷൻ വായിക്കുന്നത് സംബന്ധിച്ച്: ഞാൻ അനുബന്ധ അഭ്യർത്ഥന സൃഷ്ടിച്ചു (സവിശേഷത അഭ്യർത്ഥന) ലൈവ്നെസ് പ്രോബുകളെക്കുറിച്ചുള്ള ഡോക്യുമെൻ്റേഷൻ ചേർക്കാൻ.

വിവർത്തകനിൽ നിന്ന് പി.എസ്

ഞങ്ങളുടെ ബ്ലോഗിലും വായിക്കുക:

• «കുബെർനെറ്റസ്: പോഡ് ലൈഫ്";
• «Google-ന്റെ 7 കണ്ടെയ്‌നർ മികച്ച സമ്പ്രദായങ്ങൾ";
• «കണ്ടെയ്നർ അടിസ്ഥാനമാക്കിയുള്ള ആപ്ലിക്കേഷനുകൾ രൂപകൽപ്പന ചെയ്യുന്നതിനുള്ള 7 തത്വങ്ങൾ".

അവലംബം: www.habr.com