കുബർനെറ്റസ് കണ്ടെയ്‌നറുകൾക്കുള്ള മികച്ച രീതികൾ: ആരോഗ്യ പരിശോധനകൾ

അച്ചു ഡി.ആർ.

• കണ്ടെയ്‌നറുകളുടെയും മൈക്രോസർവീസുകളുടെയും ഉയർന്ന നിരീക്ഷണക്ഷമത കൈവരിക്കുന്നതിന്, ലോഗുകളും പ്രാഥമിക അളവുകളും മതിയാകില്ല.
• വേഗത്തിലുള്ള വീണ്ടെടുക്കലിനും വർദ്ധിച്ച പ്രതിരോധശേഷിക്കും, ആപ്ലിക്കേഷനുകൾ ഉയർന്ന നിരീക്ഷണ തത്വം (HOP) പ്രയോഗിക്കണം.
• ആപ്ലിക്കേഷൻ തലത്തിൽ, NOP-ന് ആവശ്യമാണ്: ശരിയായ ലോഗിംഗ്, ക്ലോസ് മോണിറ്ററിംഗ്, സാനിറ്റി ചെക്കുകൾ, പ്രകടനം/ട്രാൻസിഷൻ ട്രെയ്‌സിംഗ്.
• NOR-ന്റെ ഒരു ഘടകമായി ചെക്കുകൾ ഉപയോഗിക്കുക റെഡിനെസ്സ് പ്രോബ് и ജീവനുള്ള അന്വേഷണം കുബെർനെറ്റസ്.

എന്താണ് ആരോഗ്യ പരിശോധന ടെംപ്ലേറ്റ്?

ഒരു ദൗത്യ-നിർണ്ണായകവും വളരെ ലഭ്യമായതുമായ ആപ്ലിക്കേഷൻ രൂപകൽപ്പന ചെയ്യുമ്പോൾ, തെറ്റ് സഹിഷ്ണുത പോലുള്ള ഒരു വശത്തെക്കുറിച്ച് ചിന്തിക്കേണ്ടത് വളരെ പ്രധാനമാണ്. ഒരു ആപ്ലിക്കേഷൻ പരാജയത്തിൽ നിന്ന് വേഗത്തിൽ വീണ്ടെടുക്കുകയാണെങ്കിൽ അത് തെറ്റ് സഹിഷ്ണുതയായി കണക്കാക്കപ്പെടുന്നു. ഒരു സാധാരണ ക്ലൗഡ് ആപ്ലിക്കേഷൻ മൈക്രോസർവീസസ് ആർക്കിടെക്ചർ ഉപയോഗിക്കുന്നു - ഇവിടെ ഓരോ ഘടകഭാഗവും പ്രത്യേകം കണ്ടെയ്നറിൽ സ്ഥാപിച്ചിരിക്കുന്നു. നിങ്ങൾ ഒരു ക്ലസ്റ്റർ രൂപകൽപ്പന ചെയ്യുമ്പോൾ k8s-ലെ ആപ്ലിക്കേഷൻ വളരെ ലഭ്യമാണെന്ന് ഉറപ്പാക്കാൻ, നിങ്ങൾ ചില പാറ്റേണുകൾ പിന്തുടരേണ്ടതുണ്ട്. അവയിൽ ഹെൽത്ത് ചെക്ക് ടെംപ്ലേറ്റ് ഉൾപ്പെടുന്നു. ആപ്ലിക്കേഷൻ ആരോഗ്യകരമാണെന്ന് കെ8എസുമായി എങ്ങനെ ആശയവിനിമയം നടത്തുന്നുവെന്ന് ഇത് നിർവചിക്കുന്നു. ഇത് പോഡ് പ്രവർത്തിക്കുന്നുണ്ടോ എന്നതിനെക്കുറിച്ചുള്ള വിവരങ്ങൾ മാത്രമല്ല, അത് എങ്ങനെ അഭ്യർത്ഥനകൾ സ്വീകരിക്കുകയും പ്രതികരിക്കുകയും ചെയ്യുന്നു എന്നതിനെ കുറിച്ചും കൂടിയാണ്. പോഡിന്റെ ആരോഗ്യത്തെക്കുറിച്ച് കുബെർനെറ്റുകൾക്ക് എത്രത്തോളം അറിയാം, ട്രാഫിക് റൂട്ടിംഗിനെയും ലോഡ് ബാലൻസിനെയും കുറിച്ച് അത് മികച്ച തീരുമാനങ്ങൾ എടുക്കുന്നു. അതിനാൽ, അഭ്യർത്ഥനകളോട് സമയബന്ധിതമായി പ്രതികരിക്കാൻ ഉയർന്ന നിരീക്ഷണ തത്വം അപ്ലിക്കേഷനെ അനുവദിക്കുന്നു.

ഉയർന്ന നിരീക്ഷണ തത്വം (HOP)

ഉയർന്ന നിരീക്ഷണത്തിന്റെ തത്വം അതിലൊന്നാണ് കണ്ടെയ്നറൈസ്ഡ് ആപ്ലിക്കേഷനുകൾ രൂപകൽപ്പന ചെയ്യുന്നതിനുള്ള തത്വങ്ങൾ. ഒരു മൈക്രോസർവീസസ് ആർക്കിടെക്ചറിൽ, സേവനങ്ങൾ അവരുടെ അഭ്യർത്ഥന എങ്ങനെ പ്രോസസ്സ് ചെയ്യപ്പെടുന്നു എന്നത് ശ്രദ്ധിക്കുന്നില്ല (അത് ശരിയാണ്), എന്നാൽ സ്വീകരിക്കുന്ന സേവനങ്ങളിൽ നിന്ന് അവർക്ക് എങ്ങനെ പ്രതികരണങ്ങൾ ലഭിക്കുന്നു എന്നതാണ് പ്രധാനം. ഉദാഹരണത്തിന്, ഒരു ഉപയോക്താവിനെ ആധികാരികമാക്കാൻ, ഒരു കണ്ടെയ്നർ മറ്റൊന്നിലേക്ക് HTTP അഭ്യർത്ഥന അയയ്‌ക്കുന്നു, ഒരു പ്രത്യേക ഫോർമാറ്റിൽ പ്രതികരണം പ്രതീക്ഷിക്കുന്നു - അത്രമാത്രം. PythonJS-ന് അഭ്യർത്ഥന പ്രോസസ്സ് ചെയ്യാനും പൈത്തൺ ഫ്ലാസ്കിന് പ്രതികരിക്കാനും കഴിയും. പരസ്പരം മറഞ്ഞിരിക്കുന്ന ഉള്ളടക്കങ്ങളുള്ള ബ്ലാക്ക് ബോക്സുകൾ പോലെയാണ് കണ്ടെയ്നറുകൾ. എന്നിരുന്നാലും, NOP തത്വം അനുസരിച്ച്, ഓരോ സേവനവും അത് എത്രത്തോളം ആരോഗ്യകരമാണെന്ന് സൂചിപ്പിക്കുന്ന ഒന്നിലധികം API എൻഡ്‌പോയിന്റുകൾ വെളിപ്പെടുത്തേണ്ടതുണ്ട്, അതുപോലെ തന്നെ അതിന്റെ സന്നദ്ധതയും തെറ്റ് സഹിഷ്ണുത നിലയും. റൂട്ടിംഗിനും ലോഡ് ബാലൻസിംഗിനുമുള്ള അടുത്ത ഘട്ടങ്ങളെക്കുറിച്ച് ചിന്തിക്കാൻ കുബർനെറ്റസ് ഈ സൂചകങ്ങൾ അഭ്യർത്ഥിക്കുന്നു.

നന്നായി രൂപകല്പന ചെയ്ത ക്ലൗഡ് ആപ്ലിക്കേഷൻ അതിന്റെ പ്രധാന ഇവന്റുകൾ സ്റ്റാൻഡേർഡ് I/O സ്ട്രീമുകളായ STDERR, STDOUT എന്നിവ ഉപയോഗിച്ച് ലോഗ് ചെയ്യുന്നു. അടുത്തതായി ഒരു സഹായ സേവനം വരുന്നു, ഉദാഹരണത്തിന് filebeat, logstash അല്ലെങ്കിൽ fluentd, ഒരു കേന്ദ്രീകൃത മോണിറ്ററിംഗ് സിസ്റ്റത്തിലേക്കും (ഉദാഹരണത്തിന് Prometheus) ഒരു ലോഗ് ശേഖരണ സംവിധാനത്തിലേക്കും (ELK സോഫ്റ്റ്‌വെയർ സ്യൂട്ട്) ലോഗുകൾ എത്തിക്കുന്നു. ഹെൽത്ത് ടെസ്റ്റ് പാറ്റേണും ഉയർന്ന നിരീക്ഷണ തത്വവും അനുസരിച്ച് ഒരു ക്ലൗഡ് ആപ്ലിക്കേഷൻ എങ്ങനെ പ്രവർത്തിക്കുന്നുവെന്ന് ചുവടെയുള്ള ഡയഗ്രം കാണിക്കുന്നു.

കുബർനെറ്റസിൽ ആരോഗ്യ പരിശോധന പാറ്റേൺ എങ്ങനെ പ്രയോഗിക്കാം?

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

ഞങ്ങളുടെ ഉദാഹരണത്തിൽ, k8s ചെയ്യുന്നു പ്രവർത്തനക്ഷമത പരിശോധന. ഇത്തരത്തിലുള്ള സ്ഥിരീകരണത്തിൽ, കണ്ടെയ്നറിലെ പ്രക്രിയയുടെ അവസ്ഥ കുബെലെറ്റ് തുടർച്ചയായി പരിശോധിക്കുന്നു. പ്രക്രിയ നിർത്തിയതായി മനസ്സിലാക്കുമ്പോൾ, അവൻ അത് പുനരാരംഭിക്കും. ആപ്ലിക്കേഷൻ പുനരാരംഭിക്കുന്നതിലൂടെ പിശക് പരിഹരിക്കാൻ കഴിയുമെങ്കിൽ, ഏതെങ്കിലും പിശക് അടച്ചുപൂട്ടാൻ പ്രോഗ്രാം രൂപകൽപ്പന ചെയ്‌തിട്ടുണ്ടെങ്കിൽ, നിങ്ങൾ NOP-യും ഹെൽത്ത് ടെസ്റ്റ് പാറ്റേണും പിന്തുടരാൻ ഒരു പ്രോസസ് ഹെൽത്ത് ചെക്ക് മാത്രം മതി. പുനരാരംഭിക്കുന്നതിലൂടെ എല്ലാ പിശകുകളും ഇല്ലാതാക്കപ്പെടുന്നില്ല എന്നതാണ് ഏക ദയനീയം. ഈ സാഹചര്യത്തിൽ, പോഡിലെ പ്രശ്നങ്ങൾ തിരിച്ചറിയാൻ k8s 2 ആഴത്തിലുള്ള വഴികൾ വാഗ്ദാനം ചെയ്യുന്നു: ജീവനുള്ള അന്വേഷണം и റെഡിനെസ്സ് പ്രോബ്.

ലൈവ്നെസ് പ്രോബ്

ഈ കാലയളവിൽ ജീവനുള്ള അന്വേഷണം kubelet 3 തരം പരിശോധനകൾ നടത്തുന്നു: പോഡ് പ്രവർത്തിക്കുന്നുണ്ടോ എന്ന് മാത്രമല്ല, അഭ്യർത്ഥനകൾ സ്വീകരിക്കാനും വേണ്ടത്ര പ്രതികരിക്കാനും തയ്യാറാണോ എന്ന് നിർണ്ണയിക്കുന്നു:

• പോഡിലേക്ക് ഒരു HTTP അഭ്യർത്ഥന സജ്ജീകരിക്കുക. പ്രതികരണത്തിൽ 200 മുതൽ 399 വരെയുള്ള ശ്രേണിയിലുള്ള ഒരു HTTP പ്രതികരണ കോഡ് അടങ്ങിയിരിക്കണം. അങ്ങനെ, പ്രക്രിയ പ്രവർത്തിക്കുന്നുണ്ടെങ്കിലും പോഡിന് പ്രശ്‌നങ്ങളുണ്ടെന്ന് 5xx, 4xx കോഡുകൾ സൂചന നൽകുന്നു.
• HTTP ഇതര സേവനങ്ങളുള്ള പോഡുകൾ പരിശോധിക്കുന്നതിന് (ഉദാഹരണത്തിന്, Postfix മെയിൽ സെർവർ), നിങ്ങൾ ഒരു TCP കണക്ഷൻ സ്ഥാപിക്കേണ്ടതുണ്ട്.
• ഒരു പോഡിനായി (ആന്തരികമായി) ഒരു അനിയന്ത്രിതമായ കമാൻഡ് നടപ്പിലാക്കുക. കമാൻഡ് പൂർത്തീകരണ കോഡ് 0 ആണെങ്കിൽ പരിശോധന വിജയകരമായിരുന്നു.

ഇത് എങ്ങനെ പ്രവർത്തിക്കുന്നു എന്നതിന്റെ ഒരു ഉദാഹരണം. അടുത്ത പോഡ് നിർവചനത്തിൽ HTTP അഭ്യർത്ഥനകളിൽ 500 പിശക് വരുത്തുന്ന ഒരു NodeJS ആപ്ലിക്കേഷൻ അടങ്ങിയിരിക്കുന്നു. അത്തരമൊരു പിശക് ലഭിക്കുമ്പോൾ കണ്ടെയ്നർ പുനരാരംഭിച്ചിട്ടുണ്ടെന്ന് ഉറപ്പാക്കാൻ, ഞങ്ങൾ 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 സൃഷ്ടിച്ചു (ഇത് ചെയ്യാൻ പ്രോഗ്രാം ചെയ്‌തത് ഇതാണ്), kubelet അത് പുനരാരംഭിച്ചു.

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')
})

Dockerfile

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

ഇത് ശ്രദ്ധിക്കേണ്ടത് പ്രധാനമാണ്: ലൈവ്നെസ്പ്രോബ് കണ്ടെയ്നർ പരാജയപ്പെടുകയാണെങ്കിൽ മാത്രമേ അത് പുനരാരംഭിക്കുകയുള്ളൂ. ഒരു റീസ്റ്റാർട്ട് കണ്ടെയ്‌നർ പ്രവർത്തിപ്പിക്കുന്നതിൽ നിന്ന് തടയുന്ന പിശക് ശരിയാക്കിയില്ലെങ്കിൽ, പ്രശ്നം പരിഹരിക്കാൻ kubelet-ന് നടപടിയെടുക്കാൻ കഴിയില്ല.

റെഡിനെസ്സ് പ്രോബ്

റെഡിനെസ് പ്രോബ്, ട്രബിൾഷൂട്ടിംഗ് പ്രവർത്തനങ്ങൾ ഒഴികെ, livenessProbes (GET അഭ്യർത്ഥനകൾ, TCP ആശയവിനിമയങ്ങളും കമാൻഡ് എക്‌സിക്യൂഷനും) സമാനമായി പ്രവർത്തിക്കുന്നു. പരാജയം കണ്ടെത്തിയ കണ്ടെയ്‌നർ പുനരാരംഭിച്ചിട്ടില്ല, പക്ഷേ ഇൻകമിംഗ് ട്രാഫിക്കിൽ നിന്ന് ഒറ്റപ്പെട്ടതാണ്. കണ്ടെയ്‌നറുകളിലൊന്ന് ധാരാളം കണക്കുകൂട്ടലുകൾ നടത്തുന്നതായി സങ്കൽപ്പിക്കുക അല്ലെങ്കിൽ കനത്ത ലോഡിന് വിധേയമാണ്, ഇത് പ്രതികരണ സമയം വർദ്ധിപ്പിക്കുന്നതിന് കാരണമാകുന്നു. livenessProbe-ന്റെ കാര്യത്തിൽ, പ്രതികരണ ലഭ്യത പരിശോധന ട്രിഗർ ചെയ്യപ്പെടുന്നു (timeoutSeconds ചെക്ക് പാരാമീറ്റർ വഴി), അതിനുശേഷം kubelet കണ്ടെയ്നർ പുനരാരംഭിക്കുന്നു. ആരംഭിക്കുമ്പോൾ, കണ്ടെയ്നർ റിസോഴ്സ്-ഇന്റൻസീവ് ജോലികൾ ചെയ്യാൻ തുടങ്ങുകയും വീണ്ടും പുനരാരംഭിക്കുകയും ചെയ്യുന്നു. പ്രതികരണ വേഗത ആവശ്യമുള്ള ആപ്ലിക്കേഷനുകൾക്ക് ഇത് നിർണായകമാണ്. ഉദാഹരണത്തിന്, റോഡിലായിരിക്കുമ്പോൾ ഒരു കാർ സെർവറിൽ നിന്നുള്ള പ്രതികരണത്തിനായി കാത്തിരിക്കുന്നു, പ്രതികരണം വൈകുന്നു - കാർ അപകടത്തിൽ പെടുന്നു.

നമുക്ക് ഒരു rednessProbe നിർവചനം എഴുതാം, അത് 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')
})

അച്ചു ഡി.ആർ.
ക്ലൗഡ് ആപ്ലിക്കേഷനുകളുടെ ആവിർഭാവത്തിന് മുമ്പ്, ആപ്ലിക്കേഷന്റെ ആരോഗ്യം നിരീക്ഷിക്കുന്നതിനും പരിശോധിക്കുന്നതിനുമുള്ള പ്രാഥമിക മാർഗമായിരുന്നു ലോഗുകൾ. എന്നിരുന്നാലും, ഒരു തിരുത്തൽ നടപടിയെടുക്കാൻ മാർഗമില്ല. ലോഗുകൾ ഇന്നും ഉപയോഗപ്രദമാണ്; അടിയന്തിര സാഹചര്യങ്ങൾ വിശകലനം ചെയ്യുന്നതിനും തീരുമാനങ്ങൾ എടുക്കുന്നതിനുമായി അവ ശേഖരിച്ച് ഒരു ലോഗ് ശേഖരണ സംവിധാനത്തിലേക്ക് അയയ്ക്കേണ്ടതുണ്ട്. [മോണിറ്റ് ഉപയോഗിച്ച് ക്ലൗഡ് ആപ്ലിക്കേഷനുകൾ ഇല്ലാതെ ഇതെല്ലാം ചെയ്യാൻ കഴിയും, ഉദാഹരണത്തിന്, k8s ഉപയോഗിച്ച് ഇത് വളരെ എളുപ്പമായി :) - എഡിറ്ററുടെ കുറിപ്പ്. ]

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

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

ശരിയായ ആപ്ലിക്കേഷൻ രൂപകൽപ്പനയിൽ രണ്ട് തരത്തിലുള്ള പരിശോധനകളും ഉൾപ്പെടുത്തുകയും അവ ആവശ്യമായ ഡാറ്റ ശേഖരിക്കുന്നുവെന്ന് ഉറപ്പാക്കുകയും വേണം, പ്രത്യേകിച്ച് ഒരു അപവാദം എറിയുമ്പോൾ. പ്രധാനപ്പെട്ട ഹെൽത്ത് മെട്രിക്കുകൾക്കൊപ്പം മോണിറ്ററിംഗ് സിസ്റ്റം (പ്രോമിത്യൂസ്) നൽകുന്ന ആവശ്യമായ API എൻഡ് പോയിന്റുകളും ഇത് കാണിക്കണം.

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