કુબરનેટ્સ કન્ટેનર માટે શ્રેષ્ઠ પદ્ધતિઓ: આરોગ્ય તપાસો

TL; DR

• કન્ટેનર અને માઇક્રોસર્વિસિસની ઉચ્ચ અવલોકનક્ષમતા પ્રાપ્ત કરવા માટે, લોગ અને પ્રાથમિક મેટ્રિક્સ પૂરતા નથી.
• ઝડપી પુનઃપ્રાપ્તિ અને વધેલી સ્થિતિસ્થાપકતા માટે, એપ્લિકેશનોએ ઉચ્ચ અવલોકનક્ષમતા સિદ્ધાંત (HOP) લાગુ કરવો જોઈએ.
• એપ્લિકેશન સ્તરે, NOP માટે જરૂરી છે: યોગ્ય લોગીંગ, ક્લોઝ મોનિટરિંગ, સેનિટી ચેક્સ અને પરફોર્મન્સ/ટ્રાન્ઝીશન ટ્રેસિંગ.
• NOR ના તત્વ તરીકે ચેકનો ઉપયોગ કરો તૈયારી તપાસ и જીવંતતાપ્રોબ કુબરનેટ્સ.

હેલ્થ ચેક ટેમ્પલેટ શું છે?

મિશન-ક્રિટીકલ અને અત્યંત ઉપલબ્ધ એપ્લિકેશનની રચના કરતી વખતે, દોષ સહિષ્ણુતા જેવા પાસા વિશે વિચારવું ખૂબ જ મહત્વપૂર્ણ છે. જો એપ્લિકેશન નિષ્ફળતામાંથી ઝડપથી પુનઃપ્રાપ્ત થાય તો તેને દોષ સહિષ્ણુ ગણવામાં આવે છે. એક લાક્ષણિક ક્લાઉડ એપ્લિકેશન માઇક્રોસર્વિસિસ આર્કિટેક્ચરનો ઉપયોગ કરે છે - જ્યાં દરેક ઘટક અલગ કન્ટેનરમાં મૂકવામાં આવે છે. અને જ્યારે તમે ક્લસ્ટર ડિઝાઇન કરો ત્યારે k8s પર એપ્લિકેશન ખૂબ જ ઉપલબ્ધ છે તેની ખાતરી કરવા માટે, તમારે ચોક્કસ પેટર્નને અનુસરવાની જરૂર છે. તે પૈકી હેલ્થ ચેક ટેમ્પલેટ છે. તે વ્યાખ્યાયિત કરે છે કે એપ્લિકેશન કેવી રીતે k8s ને સંચાર કરે છે કે તે સ્વસ્થ છે. આ માત્ર પોડ ચાલી રહ્યું છે કે કેમ તે વિશેની માહિતી નથી, પણ તે કેવી રીતે વિનંતીઓ પ્રાપ્ત કરે છે અને તેનો પ્રતિસાદ આપે છે તે વિશે પણ છે. કુબરનેટીસ પોડના સ્વાસ્થ્ય વિશે જેટલા વધુ જાણે છે, તે ટ્રાફિક રૂટીંગ અને લોડ બેલેન્સિંગ વિશે વધુ સ્માર્ટ નિર્ણયો લે છે. આમ, ઉચ્ચ અવલોકનક્ષમતા સિદ્ધાંત એપ્લીકેશનને સમયસર વિનંતીઓનો પ્રતિસાદ આપવાની મંજૂરી આપે છે.

ઉચ્ચ અવલોકનક્ષમતા સિદ્ધાંત (HOP)

ઉચ્ચ અવલોકનક્ષમતાનો સિદ્ધાંત તેમાંનો એક છે કન્ટેનરાઇઝ્ડ એપ્લિકેશન ડિઝાઇન કરવા માટેના સિદ્ધાંતો. માઇક્રોસર્વિસીસ આર્કિટેક્ચરમાં, સેવાઓ તેમની વિનંતી પર કેવી રીતે પ્રક્રિયા કરવામાં આવે છે તેની કાળજી લેતી નથી (અને યોગ્ય રીતે), પરંતુ જે મહત્વનું છે તે છે કે તેઓ પ્રાપ્ત સેવાઓ તરફથી કેવી રીતે પ્રતિસાદ મેળવે છે. ઉદાહરણ તરીકે, વપરાશકર્તાને પ્રમાણિત કરવા માટે, એક કન્ટેનર ચોક્કસ ફોર્મેટમાં પ્રતિસાદની અપેક્ષા રાખીને બીજાને HTTP વિનંતી મોકલે છે - બસ. PythonJS વિનંતી પર પ્રક્રિયા પણ કરી શકે છે, અને Python Flask પ્રતિસાદ આપી શકે છે. કન્ટેનર એકબીજા સાથે છુપાયેલા સમાવિષ્ટો સાથે બ્લેક બોક્સ જેવા છે. જો કે, NOP સિદ્ધાંત માટે દરેક સેવાને બહુવિધ API એન્ડપોઇન્ટ્સનો પર્દાફાશ કરવાની જરૂર છે જે દર્શાવે છે કે તે કેટલું સ્વસ્થ છે, તેમજ તેની તૈયારી અને ખામી સહનશીલતા સ્થિતિ. કુબરનેટ્સ રૂટીંગ અને લોડ બેલેન્સિંગ માટેના આગળના પગલાઓ પર વિચાર કરવા માટે આ સૂચકાંકોની વિનંતી કરે છે.

સારી રીતે ડિઝાઇન કરેલ ક્લાઉડ એપ્લિકેશન પ્રમાણભૂત I/O સ્ટ્રીમ્સ STDERR અને STDOUT નો ઉપયોગ કરીને તેની મુખ્ય ઇવેન્ટ્સને લૉગ કરે છે. આગળ એક સહાયક સેવા આવે છે, ઉદાહરણ તરીકે ફાઇલબીટ, લોગસ્ટેશ અથવા ફ્લુએન્ટડ, કેન્દ્રિય મોનિટરિંગ સિસ્ટમ (ઉદાહરણ તરીકે પ્રોમિથિયસ) અને લોગ કલેક્શન સિસ્ટમ (ELK સોફ્ટવેર સ્યુટ) પર લોગ પહોંચાડે છે. નીચેનો આકૃતિ બતાવે છે કે આરોગ્ય પરીક્ષણ પેટર્ન અને ઉચ્ચ અવલોકનક્ષમતા સિદ્ધાંત અનુસાર ક્લાઉડ એપ્લિકેશન કેવી રીતે કાર્ય કરે છે.

કુબરનેટ્સમાં હેલ્થ ચેક પેટર્ન કેવી રીતે લાગુ કરવી?

બૉક્સની બહાર, k8s એક નિયંત્રકનો ઉપયોગ કરીને શીંગોની સ્થિતિનું નિરીક્ષણ કરે છે (જમાવટ, પ્રતિકૃતિસેટ્સ, ડેમનસેટ્સ, સ્ટેટફુલસેટ્સ વગેરે, વગેરે). કોઈ કારણસર પોડ પડી ગયો છે તે શોધ્યા પછી, નિયંત્રક તેને ફરીથી શરૂ કરવાનો અથવા તેને બીજા નોડ પર ખસેડવાનો પ્રયાસ કરે છે. જો કે, પોડ જાણ કરી શકે છે કે તે ચાલુ છે અને ચાલી રહ્યું છે, પરંતુ તે પોતે કાર્ય કરી રહ્યું નથી. ચાલો એક ઉદાહરણ આપીએ: તમારી એપ્લિકેશન વેબ સર્વર તરીકે અપાચેનો ઉપયોગ કરે છે, તમે ક્લસ્ટરના ઘણા પોડ્સ પર ઘટક ઇન્સ્ટોલ કર્યું છે. લાઇબ્રેરી ખોટી રીતે ગોઠવેલી હોવાથી, એપ્લિકેશનની તમામ વિનંતીઓ કોડ 500 (આંતરિક સર્વર ભૂલ) સાથે પ્રતિસાદ આપે છે. ડિલિવરી તપાસતી વખતે, શીંગોની સ્થિતિ તપાસવાથી સફળ પરિણામ મળે છે, પરંતુ ગ્રાહકો અલગ રીતે વિચારે છે. અમે આ અનિચ્છનીય પરિસ્થિતિનું વર્ણન નીચે મુજબ કરીશું:

અમારા ઉદાહરણમાં, k8s કરે છે કાર્યક્ષમતા તપાસ. આ પ્રકારની ચકાસણીમાં, કુબેલેટ કન્ટેનરમાં પ્રક્રિયાની સ્થિતિને સતત તપાસે છે. એકવાર તે સમજે છે કે પ્રક્રિયા બંધ થઈ ગઈ છે, તે તેને ફરીથી શરૂ કરશે. જો એપ્લિકેશનને ફરીથી શરૂ કરીને ભૂલને ઉકેલી શકાય છે, અને પ્રોગ્રામ કોઈપણ ભૂલ પર બંધ કરવા માટે રચાયેલ છે, તો તમારે NOP અને આરોગ્ય પરીક્ષણ પેટર્નને અનુસરવા માટે પ્રક્રિયા આરોગ્ય તપાસની જરૂર છે. એકમાત્ર દયા એ છે કે બધી ભૂલો ફરીથી પ્રારંભ કરીને દૂર થતી નથી. આ કિસ્સામાં, k8s પોડ સાથે સમસ્યાઓ ઓળખવા માટે 2 ઊંડા માર્ગો પ્રદાન કરે છે: જીવંતતાપ્રોબ и તૈયારી તપાસ.

LivenessProbe

દરમિયાન જીવંતતાપ્રોબ કુબેલેટ 3 પ્રકારની તપાસ કરે છે: માત્ર પોડ ચાલી રહ્યું છે કે કેમ તે નક્કી કરતું નથી, પણ તે વિનંતીઓ પ્રાપ્ત કરવા અને પર્યાપ્ત રીતે પ્રતિસાદ આપવા માટે તૈયાર છે કે કેમ તે પણ નક્કી કરે છે:

• પોડ પર HTTP વિનંતી સેટ કરો. પ્રતિભાવમાં 200 થી 399 ની રેન્જમાં HTTP પ્રતિસાદ કોડ હોવો આવશ્યક છે. આમ, 5xx અને 4xx કોડ સંકેત આપે છે કે પ્રક્રિયા ચાલી રહી હોવા છતાં પોડમાં સમસ્યા આવી રહી છે.
• બિન-HTTP સેવાઓ (ઉદાહરણ તરીકે, પોસ્ટફિક્સ મેઇલ સર્વર) સાથે પોડ્સનું પરીક્ષણ કરવા માટે, તમારે TCP કનેક્શન સ્થાપિત કરવાની જરૂર છે.
• પોડ (આંતરિક રીતે) માટે મનસ્વી આદેશ ચલાવો. જો આદેશ પૂર્ણતા કોડ 0 હોય તો ચેક સફળ ગણવામાં આવે છે.

આ કેવી રીતે કાર્ય કરે છે તેનું ઉદાહરણ. આગળની પોડ વ્યાખ્યામાં નોડજેએસ એપ્લિકેશન છે જે HTTP વિનંતીઓ પર 500 ભૂલ ફેંકે છે. આવી ભૂલ પ્રાપ્ત કરતી વખતે કન્ટેનર પુનઃપ્રારંભ થાય છે તેની ખાતરી કરવા માટે, અમે livenessProbe પરિમાણનો ઉપયોગ કરીએ છીએ:

apiVersion: v1
kind: Pod
metadata:
 name: node500
spec:
 containers:
   - image: magalix/node500
     name: node500
     ports:
       - containerPort: 3000
         protocol: TCP
     livenessProbe:
       httpGet:
         path: /
         port: 3000
       initialDelaySeconds: 5

આ અન્ય કોઈપણ પોડ વ્યાખ્યાથી અલગ નથી, પરંતુ અમે એક ઑબ્જેક્ટ ઉમેરી રહ્યા છીએ .spec.containers.livenessProbe. પરિમાણ httpGet જે પાથ પર HTTP GET વિનંતી મોકલવામાં આવે છે તે સ્વીકારે છે (અમારા ઉદાહરણમાં આ છે /, પરંતુ લડાઇના સંજોગોમાં એવું કંઈક હોઈ શકે છે /api/v1/status). અન્ય livenessProbe પરિમાણ સ્વીકારે છે initialDelaySeconds, જે વેરિફિકેશન ઑપરેશનને નિર્દિષ્ટ સંખ્યામાં સેકંડ રાહ જોવાની સૂચના આપે છે. વિલંબ જરૂરી છે કારણ કે કન્ટેનરને શરૂ થવા માટે સમયની જરૂર છે, અને જ્યારે પુનઃપ્રારંભ કરવામાં આવે ત્યારે તે થોડા સમય માટે અનુપલબ્ધ રહેશે.

આ સેટિંગને ક્લસ્ટર પર લાગુ કરવા માટે, આનો ઉપયોગ કરો:

kubectl apply -f pod.yaml

થોડીક સેકન્ડો પછી, તમે નીચેના આદેશનો ઉપયોગ કરીને પોડની સામગ્રીને ચકાસી શકો છો:

kubectl describe pods node500

આઉટપુટના અંતે, શોધો તે શું છે.

જેમ તમે જોઈ શકો છો, livenessProbe એ HTTP GET વિનંતી શરૂ કરી, કન્ટેનર એ ભૂલ 500 જનરેટ કરી (જે તે કરવા માટે પ્રોગ્રામ કરવામાં આવ્યું હતું), અને કુબેલેટે તેને પુનઃશરૂ કર્યું.

જો તમે આશ્ચર્ય પામી રહ્યાં છો કે NideJS એપ્લિકેશન કેવી રીતે પ્રોગ્રામ કરવામાં આવી હતી, તો અહીં app.js અને Dockerfile છે જેનો ઉપયોગ કરવામાં આવ્યો હતો:

app.js

var http = require('http');

var server = http.createServer(function(req, res) {
    res.writeHead(500, { "Content-type": "text/plain" });
    res.end("We have run into an errorn");
});

server.listen(3000, function() {
    console.log('Server is running at 3000')
})

ડોકરફાઇલ

FROM node
COPY app.js /
EXPOSE 3000
ENTRYPOINT [ "node","/app.js" ]

આ નોંધવું અગત્યનું છે: livenessProbe માત્ર કન્ટેનરને ફરીથી શરૂ કરશે જો તે નિષ્ફળ જાય. જો પુનઃપ્રારંભ એ ભૂલને સુધારતું નથી કે જે કન્ટેનરને ચાલતા અટકાવે છે, તો કુબેલેટ સમસ્યાને સુધારવા માટે પગલાં લેવા માટે સમર્થ હશે નહીં.

તૈયારી તપાસ

રેડીનેસપ્રોબ મુશ્કેલીનિવારણ ક્રિયાઓ સિવાય, livenessProbes (GET વિનંતીઓ, TCP સંચાર અને આદેશ અમલીકરણ) ની જેમ જ કામ કરે છે. કન્ટેનર કે જેમાં નિષ્ફળતા મળી છે તે પુનઃપ્રારંભ કરવામાં આવતું નથી, પરંતુ આવનારા ટ્રાફિકથી અલગ છે. કલ્પના કરો કે એક કન્ટેનર ઘણી બધી ગણતરીઓ કરી રહ્યું છે અથવા ભારે ભાર હેઠળ છે, જેના કારણે પ્રતિસાદનો સમય વધી રહ્યો છે. livenessProbe ના કિસ્સામાં, પ્રતિભાવ ઉપલબ્ધતા તપાસ ટ્રિગર થાય છે (સમયઆઉટ સેકન્ડ ચેક પેરામીટર દ્વારા), જે પછી ક્યુબેલેટ કન્ટેનરને પુનઃપ્રારંભ કરે છે. જ્યારે શરૂ થાય છે, ત્યારે કન્ટેનર સંસાધન-સઘન કાર્યો કરવાનું શરૂ કરે છે અને ફરીથી શરૂ થાય છે. આ એપ્લીકેશનો માટે મહત્વપૂર્ણ હોઈ શકે છે જેને પ્રતિભાવ ગતિની જરૂર હોય છે. ઉદાહરણ તરીકે, જ્યારે કાર રસ્તા પર સર્વર તરફથી પ્રતિસાદની રાહ જોઈ રહી છે, પ્રતિસાદમાં વિલંબ થાય છે - અને કાર અકસ્માતમાં પડે છે.

ચાલો એક રેડીનેસપ્રોબ વ્યાખ્યા લખીએ જે GET વિનંતીના પ્રતિભાવ સમયને બે સેકન્ડથી વધુ નહીં સેટ કરશે, અને એપ્લિકેશન 5 સેકન્ડ પછી GET વિનંતીનો પ્રતિસાદ આપશે. pod.yaml ફાઇલ આના જેવી હોવી જોઈએ:

apiVersion: v1
kind: Pod
metadata:
 name: nodedelayed
spec:
 containers:
   - image: afakharany/node_delayed
     name: nodedelayed
     ports:
       - containerPort: 3000
         protocol: TCP
     readinessProbe:
       httpGet:
         path: /
         port: 3000
       timeoutSeconds: 2

ચાલો kubectl સાથે પોડ ગોઠવીએ:

kubectl apply -f pod.yaml

ચાલો થોડી સેકંડ રાહ જોઈએ અને પછી જોઈએ કે રેડીનેસપ્રોબ કેવી રીતે કામ કરે છે:

kubectl describe pods nodedelayed

આઉટપુટના અંતે તમે જોઈ શકો છો કે કેટલીક ઘટનાઓ સમાન છે આ એક.

જેમ તમે જોઈ શકો છો, જ્યારે ચેકનો સમય 2 સેકન્ડથી વધી ગયો ત્યારે kubectl પોડને પુનઃપ્રારંભ કરતું નથી. તેના બદલે, તેણે વિનંતી રદ કરી. ઇનકમિંગ કોમ્યુનિકેશન્સ અન્ય, વર્કિંગ પોડ્સ પર રીડાયરેક્ટ કરવામાં આવે છે.

નોંધ કરો કે હવે જ્યારે પોડ ઓફલોડ થઈ ગયું છે, ત્યારે kubectl તેને ફરીથી વિનંતી કરે છે: GET વિનંતીઓના જવાબોમાં હવે વિલંબ થતો નથી.

સરખામણી માટે, નીચે સંશોધિત app.js ફાઇલ છે:

var http = require('http');

var server = http.createServer(function(req, res) {
   const sleep = (milliseconds) => {
       return new Promise(resolve => setTimeout(resolve, milliseconds))
   }
   sleep(5000).then(() => {
       res.writeHead(200, { "Content-type": "text/plain" });
       res.end("Hellon");
   })
});

server.listen(3000, function() {
   console.log('Server is running at 3000')
})

TL; DR
ક્લાઉડ એપ્લીકેશનના આગમન પહેલા, લૉગ એ એપ્લીકેશનના આરોગ્યની દેખરેખ અને તપાસનું પ્રાથમિક માધ્યમ હતું. જો કે, કોઈ સુધારાત્મક પગલાં લેવાનું કોઈ સાધન નહોતું. લૉગ્સ આજે પણ ઉપયોગી છે; કટોકટીની પરિસ્થિતિઓનું પૃથ્થકરણ કરવા અને નિર્ણયો લેવા માટે તેને એકત્રિત કરીને લોગ કલેક્શન સિસ્ટમમાં મોકલવાની જરૂર છે. [આ બધું મોનિટનો ઉપયોગ કરીને ક્લાઉડ એપ્લિકેશન વિના કરી શકાય છે, ઉદાહરણ તરીકે, પરંતુ k8s સાથે તે ખૂબ સરળ બન્યું :) - સંપાદકની નોંધ. ]

આજે, લગભગ રીઅલ ટાઇમમાં સુધારા કરવા પડે છે, તેથી એપ્લિકેશનને હવે બ્લેક બોક્સની જરૂર નથી. ના, તેઓએ અંતિમ બિંદુઓ દર્શાવવા જોઈએ જે મોનિટરિંગ સિસ્ટમ્સને પ્રક્રિયાઓની સ્થિતિ વિશે મૂલ્યવાન ડેટા ક્વેરી કરવા અને એકત્રિત કરવાની મંજૂરી આપે છે જેથી જો જરૂરી હોય તો તેઓ તરત જ જવાબ આપી શકે. તેને પર્ફોર્મન્સ ટેસ્ટ ડિઝાઇન પેટર્ન કહેવામાં આવે છે, જે ઉચ્ચ અવલોકનક્ષમતા સિદ્ધાંત (HOP) ને અનુસરે છે.

કુબરનેટ્સ મૂળભૂત રીતે 2 પ્રકારની આરોગ્ય તપાસો ઓફર કરે છે: રેડીનેસપ્રોબ અને લાઇવનેસપ્રોબ. બંને એક જ પ્રકારના ચેકનો ઉપયોગ કરે છે (HTTP GET વિનંતીઓ, TCP સંચાર અને આદેશ અમલ). શીંગોમાં સમસ્યાઓના જવાબમાં તેઓ કયા નિર્ણયો લે છે તેમાં તેઓ અલગ પડે છે. livenessProbe એ આશા સાથે કન્ટેનરને પુનઃપ્રારંભ કરે છે કે ભૂલ ફરીથી થશે નહીં, અને રેડીનેસપ્રોબ સમસ્યાનું કારણ ઉકેલાય ત્યાં સુધી પોડને ઇનકમિંગ ટ્રાફિકથી અલગ રાખે છે.

યોગ્ય એપ્લિકેશન ડિઝાઇનમાં બંને પ્રકારની ચકાસણીનો સમાવેશ થવો જોઈએ અને ખાતરી કરો કે તેઓ પૂરતો ડેટા એકત્રિત કરે છે, ખાસ કરીને જ્યારે અપવાદ ફેંકવામાં આવે. તે જરૂરી એપીઆઈ એન્ડપોઈન્ટ્સ પણ દર્શાવવા જોઈએ જે મહત્વપૂર્ણ આરોગ્ય મેટ્રિક્સ સાથે મોનિટરિંગ સિસ્ટમ (પ્રોમિથિયસ) પ્રદાન કરે છે.

સોર્સ: www.habr.com