Kubernetes માં જીવંતતાની તપાસ ખતરનાક બની શકે છે

નૉૅધ. અનુવાદ: ઝાલેન્ડોના લીડ એન્જિનિયર, હેનિંગ જેકોબ્સે, લાઇવનેસ (અને તત્પરતા) ચકાસણીના હેતુ અને તેમના સાચા ઉપયોગને સમજવામાં કુબરનેટ્સ વપરાશકર્તાઓમાં વારંવાર સમસ્યાઓ નોંધી છે. તેથી, તેણે આ ક્ષમતાવાળી નોંધમાં તેના વિચારો એકત્રિત કર્યા, જે આખરે 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. HTTP એન્ડપોઇન્ટ (REST, વગેરે) સાથે માઇક્રોસર્વિસિસ માટે હંમેશા રેડીનેસ પ્રોબ વ્યાખ્યાયિત કરો, જે એપ્લીકેશન (પોડ) ટ્રાફિક સ્વીકારવા માટે તૈયાર છે કે કેમ તે તપાસે છે.
2. તૈયારી તપાસની ખાતરી કરો વાસ્તવિક વેબ સર્વર પોર્ટની ઉપલબ્ધતાને આવરી લે છે:
   • વહીવટી હેતુઓ માટે પોર્ટનો ઉપયોગ, જેને "એડમિન" અથવા "મેનેજમેન્ટ" કહેવાય છે (ઉદાહરણ તરીકે, 9090), માટે readinessProbe, ખાતરી કરો કે જો પ્રાથમિક HTTP પોર્ટ (જેમ કે 8080) ટ્રાફિક* સ્વીકારવા માટે તૈયાર હોય તો જ એન્ડપોઇન્ટ બરાબર પરત કરે છે;

     *હું ઝાલેન્ડો ખાતે ઓછામાં ઓછા એક કેસથી વાકેફ છું જ્યાં આવું બન્યું ન હતું, એટલે કે. readinessProbe મેં "મેનેજમેન્ટ" પોર્ટ તપાસ્યું, પરંતુ કેશ લોડ કરવામાં સમસ્યાઓને કારણે સર્વર પોતે કામ કરવાનું શરૂ કરતું નથી.

   • એક અલગ પોર્ટ પર રેડીનેસ પ્રોબ જોડવાથી એ હકીકત તરફ દોરી શકે છે કે મુખ્ય પોર્ટ પરનો ઓવરલોડ આરોગ્ય તપાસમાં પ્રતિબિંબિત થશે નહીં (એટલે ​​​​કે, સર્વર પરનો થ્રેડ પૂલ ભરાયેલો છે, પરંતુ આરોગ્ય તપાસ હજી પણ બતાવે છે કે બધું બરાબર છે. ).
3. તે પાકું કરી લો રેડીનેસ પ્રોબ ડેટાબેઝ આરંભ/માઇગ્રેશનને સક્રિય કરે છે;
   • આ હાંસલ કરવાનો સૌથી સહેલો રસ્તો એ છે કે આરંભ પૂર્ણ થયા પછી જ HTTP સર્વરનો સંપર્ક કરવો (ઉદાહરણ તરીકે, ડેટાબેઝનું સ્થળાંતર ફ્લાયવે અને તેથી વધુ.); એટલે કે, હેલ્થ ચેક સ્ટેટસ બદલવાને બદલે, જ્યાં સુધી ડેટાબેઝ સ્થળાંતર પૂર્ણ ન થાય ત્યાં સુધી વેબ સર્વર શરૂ કરશો નહીં*.

     * તમે પોડની બહાર ઇનિટ કન્ટેનરમાંથી ડેટાબેઝ સ્થળાંતર પણ ચલાવી શકો છો. હું હજુ પણ સ્વ-સમાયેલ એપ્લિકેશનનો ચાહક છું, એટલે કે, જેમાં એપ્લિકેશન કન્ટેનર જાણે છે કે બાહ્ય સંકલન વિના ડેટાબેઝને ઇચ્છિત સ્થિતિમાં કેવી રીતે લાવવું.

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 સાથેના કાર્યકારી કનેક્શન પર આધાર રાખે છે, ત્યારે નેટવર્ક/DB બાજુ પર વિલંબ થાય તો તમામ 10 પોડ્સ નિષ્ફળ થઈ શકે છે - સામાન્ય રીતે તે બધા અંત તે કરી શકે કરતાં વધુ ખરાબ છે;
   • મહેરબાની કરીને નોંધ કરો કે સ્પ્રિંગ ડેટા મૂળભૂત રીતે ડેટાબેઝ કનેક્શન તપાસે છે*;

     * આ સ્પ્રિંગ ડેટા રેડિસનું ડિફોલ્ટ વર્તન છે (ઓછામાં ઓછું તે છેલ્લી વખત મેં તપાસ્યું હતું), જે "આપત્તિજનક" નિષ્ફળતા તરફ દોરી ગયું: જ્યારે રેડિસ ટૂંકા સમય માટે અનુપલબ્ધ હતું, ત્યારે તમામ પોડ્સ "ક્રેશ થઈ ગયા".

   • આ અર્થમાં "બાહ્ય" નો અર્થ સમાન એપ્લિકેશનના અન્ય શીંગો પણ હોઈ શકે છે, એટલે કે, આદર્શ રીતે કેસ્કેડિંગ ક્રેશને રોકવા માટે ચેક સમાન ક્લસ્ટરના અન્ય શીંગોની સ્થિતિ પર આધાર રાખવો જોઈએ નહીં:
     • ડિસ્ટ્રિબ્યુટેડ સ્ટેટ (ઉદાહરણ તરીકે, પોડ્સમાં ઇન-મેમરી કેશીંગ) સાથેની એપ્લિકેશનો માટે પરિણામો બદલાઈ શકે છે.
2. જીવંતતા ચકાસણીનો ઉપયોગ કરશો નહીં શીંગો માટે (અપવાદો એવા કિસ્સાઓ છે જ્યારે તેઓ ખરેખર જરૂરી હોય અને તમે તેમના ઉપયોગની વિશિષ્ટતાઓ અને પરિણામોથી સંપૂર્ણપણે વાકેફ હોવ):
   • લાઇવનેસ પ્રોબ હેંગ કન્ટેનરને પુનઃપ્રાપ્ત કરવામાં મદદ કરી શકે છે, પરંતુ તમારી એપ્લિકેશન પર તમારું સંપૂર્ણ નિયંત્રણ હોવાથી, હંગ પ્રક્રિયાઓ અને ડેડલૉક્સ જેવી બાબતો આદર્શ રીતે થવી જોઈએ નહીં: શ્રેષ્ઠ વિકલ્પ એ છે કે એપ્લિકેશનને ઇરાદાપૂર્વક ક્રેશ કરવી અને તેને પાછલી સ્થિર સ્થિતિમાં લાવવા;
   • નિષ્ફળ લાઇવનેસ પ્રોબ કન્ટેનરને પુનઃપ્રારંભ કરવા માટેનું કારણ બનશે, જેનાથી બૂટ-સંબંધિત ભૂલોની અસરોમાં સંભવિત વધારો થશે: કન્ટેનરને પુનઃપ્રારંભ કરવાથી ડાઉનટાઇમ થશે (ઓછામાં ઓછા એપ્લિકેશન સ્ટાર્ટઅપની અવધિ માટે, 30+ સેકંડ કહો), નવી ભૂલોનું કારણ બનશે, અન્ય કન્ટેનર પર ભાર વધારવો અને તેમની નિષ્ફળતાની સંભાવના વધારવી, વગેરે;
   • બાહ્ય અવલંબન સાથે સંયોજિત જીવંતતા તપાસો એ સૌથી ખરાબ સંભવિત સંયોજન છે, જે કેસ્કેડિંગ નિષ્ફળતાઓને ધમકી આપે છે: ડેટાબેઝ બાજુ પર થોડો વિલંબ તમારા બધા કન્ટેનરને પુનઃપ્રારંભ તરફ દોરી જશે!
3. જીવંતતા અને તત્પરતા તપાસના પરિમાણો અલગ હોવું જોઈએ:
   • તમે સમાન આરોગ્ય તપાસ સાથે જીવંતતા ચકાસણીનો ઉપયોગ કરી શકો છો, પરંતુ ઉચ્ચ પ્રતિભાવ થ્રેશોલ્ડ (failureThreshold), ઉદાહરણ તરીકે, સ્થિતિ સોંપો તૈયાર નથી 3 પ્રયાસો પછી અને ધ્યાનમાં લો કે 10 પ્રયાસો પછી જીવંતતાની તપાસ નિષ્ફળ ગઈ છે;
4. exec ચેક્સનો ઉપયોગ કરશો નહીં, કારણ કે તેઓ જાણીતી સમસ્યાઓ સાથે સંકળાયેલા છે જે ઝોમ્બી પ્રક્રિયાઓના દેખાવ તરફ દોરી જાય છે:
   • વિગતો: જુઓ ડેટાડોગ નિષ્ણાતો દ્વારા પ્રસ્તુતિ.

સારાંશ

• જ્યારે પોડ ટ્રાફિક મેળવવા માટે તૈયાર છે ત્યારે તે નિર્ધારિત કરવા માટે રેડીનેસ પ્રોબ્સનો ઉપયોગ કરો.
• લાઇવનેસ પ્રોબ્સનો ઉપયોગ ત્યારે જ કરો જ્યારે તેમની ખરેખર જરૂર હોય.
• તત્પરતા/જીવંત ચકાસણીઓનો અયોગ્ય ઉપયોગ ઉપલબ્ધતામાં ઘટાડો અને કાસ્કેડિંગ નિષ્ફળતા તરફ દોરી શકે છે.

વિષય પર વધારાની સામગ્રી

• કુબરનેટ્સ ડોક્સ: લાઈવનેસ અને રેડીનેસ પ્રોબ્સ ગોઠવો;
• કુબરનેટસ લાઈવનેસ અને રેડીનેસ પ્રોબ્સની ફરી મુલાકાત: બીજા પગમાં પોતાને મારવાનું કેવી રીતે ટાળવું;
• NRE લેબ્સ આઉટેજ પોસ્ટ-મોર્ટમ (તે livenessProbe વિશે પણ વાત કરે છે).

1-2019-09 થી અપડેટ નંબર 29

ડેટાબેઝ સ્થળાંતર માટે init કન્ટેનર વિશે: ફૂટનોટ ઉમેરી.

EJએ મને યાદ કરાવ્યું PDB વિશે: જીવંતતા તપાસમાંની એક સમસ્યા શીંગો વચ્ચે સંકલનનો અભાવ છે. કુબરનેટ્સ પાસે છે પોડ ડિસ્પર્શન બજેટ્સ (PDB) સહવર્તી નિષ્ફળતાઓની સંખ્યા મર્યાદિત કરવા માટે એપ્લિકેશન અનુભવી શકે છે, જો કે ચેક PDB ને ધ્યાનમાં લેતા નથી. આદર્શરીતે, અમે K8s ને કહી શકીએ કે "જો તેનો ટેસ્ટ નિષ્ફળ જાય તો એક પોડ પુનઃપ્રારંભ કરો, પરંતુ વસ્તુઓને વધુ ખરાબ ન કરવા માટે તે બધાને ફરીથી શરૂ કરશો નહીં."

બ્રાયન તેને સંપૂર્ણ રીતે મૂકે છે: “જ્યારે તમને બરાબર શું ખબર હોય ત્યારે લાઇવનેસ પ્રોબિંગનો ઉપયોગ કરો એપ્લિકેશનને મારી નાખવાની શ્રેષ્ઠ વસ્તુ છે"(ફરીથી, દૂર વહી જશો નહીં).

2-2019-09 થી અપડેટ નંબર 29

ઉપયોગ કરતા પહેલા દસ્તાવેજો વાંચવા અંગે: મેં અનુરૂપ વિનંતી બનાવી છે (લક્ષણ વિનંતી) જીવંતતા ચકાસણીઓ વિશે દસ્તાવેજીકરણ ઉમેરવા માટે.

અનુવાદક તરફથી પીએસ

અમારા બ્લોગ પર પણ વાંચો:

• «કુબરનેટ્સ: પોડ લાઇફ»;
• «Google અનુસાર કન્ટેનરનો ઉપયોગ કરવા માટેની 7 શ્રેષ્ઠ પદ્ધતિઓ»;
• «કન્ટેનર-આધારિત એપ્લિકેશન ડિઝાઇન કરવા માટેના 7 સિદ્ધાંતો».

સોર્સ: www.habr.com