Kubernetes බහාලුම් සඳහා හොඳම භාවිතයන්: සෞඛ්‍ය පරීක්ෂණ

TL; ඩී

• බහාලුම් සහ ක්ෂුද්‍ර සේවාවල ඉහළ නිරීක්ෂණ හැකියාවක් ලබා ගැනීම සඳහා, ලඝු-සටහන් සහ ප්‍රාථමික මිනුම් ප්‍රමාණවත් නොවේ.
• වේගවත් ප්‍රතිසාධනය සහ වැඩි ඔරොත්තු දීමේ හැකියාව සඳහා, යෙදුම් ඉහළ නිරීක්ෂණ මූලධර්මය (HOP) යෙදිය යුතුය.
• යෙදුම් මට්ටමේදී, NOP සඳහා අවශ්‍ය වන්නේ: නිසි ලොග් වීම, සමීප අධීක්ෂණය, සනීපාරක්ෂාව පරීක්ෂා කිරීම සහ කාර්ය සාධනය/සංක්‍රාන්ති ලුහුබැඳීම.
• NOR හි අංගයක් ලෙස චෙක්පත් භාවිතා කරන්න සූදානම විමර්ශනය и සජීවී පරීක්ෂණ කුබර්නෙටස්.

සෞඛ්ය පිරික්සුම් ආකෘතියක් යනු කුමක්ද?

මෙහෙවර-විවේචනාත්මක සහ බෙහෙවින් පවතින යෙදුමක් සැලසුම් කිරීමේදී, වැරදි ඉවසීම වැනි එවැනි අංගයක් ගැන සිතීම ඉතා වැදගත් වේ. යෙදුම අසාර්ථක වීමෙන් ඉක්මනින් යථා තත්ත්වයට පත් වුවහොත් එය වැරදි ඉවසීමක් ලෙස සැලකේ. සාමාන්‍ය වලාකුළු යෙදුමක් ක්ෂුද්‍ර සේවා ගෘහ නිර්මාණ ශිල්පයක් භාවිතා කරයි - එහිදී එක් එක් සංරචක වෙනම බහාලුමක තබා ඇත. ඔබ පොකුරක් නිර්මාණය කරන විට k8s හි යෙදුම ඉතා ඉහළ මට්ටමක පවතින බව සහතික කර ගැනීම සඳහා, ඔබ යම් රටාවන් අනුගමනය කළ යුතුය. ඒ අතර සෞඛ්‍ය පරීක්‍ෂණ අච්චුව ද වේ. යෙදුම සෞඛ්‍ය සම්පන්න බව k8s වෙත සන්නිවේදනය කරන ආකාරය එය අර්ථ දක්වයි. මෙය පොඩ් එක ක්‍රියාත්මක වන්නේද යන්න පිළිබඳ තොරතුරු පමණක් නොව, එය ඉල්ලීම් ලැබෙන සහ ප්‍රතිචාර දක්වන ආකාරය පිළිබඳ තොරතුරු වේ. කුබර්නෙටේස් පෝඩ්ගේ සෞඛ්‍යය ගැන වැඩි වැඩියෙන් දන්නා තරමට, එය රථවාහන මාර්ගගත කිරීම සහ බර සමතුලිත කිරීම පිළිබඳ බුද්ධිමත් තීරණ ගනී. මේ අනුව, ඉහළ නිරීක්ෂණ මූලධර්මය මඟින් ඉල්ලීම් වලට නියමිත වේලාවට ප්‍රතිචාර දැක්වීමට යෙදුමට ඉඩ ලබා දේ.

ඉහළ නිරීක්ෂණ මූලධර්මය (HOP)

ඉහළ නිරීක්ෂණ මූලධර්මය එකකි බහාලුම් යෙදුම් සැලසුම් කිරීමේ මූලධර්ම. ක්ෂුද්‍ර සේවා ගෘහනිර්මාණ ශිල්පය තුළ, සේවා ඔවුන්ගේ ඉල්ලීම සකසන ආකාරය ගැන සැලකිල්ලක් නොදක්වයි (සහ නිවැරදිව එසේ), නමුත් වැදගත් වන්නේ ලැබෙන සේවාවන්ගෙන් ප්‍රතිචාර ලැබෙන්නේ කෙසේද යන්නයි. උදාහරණයක් ලෙස, පරිශීලකයෙකු සත්‍යාපනය කිරීම සඳහා, එක් බහාලුමක් තවත් කෙනෙකුට HTTP ඉල්ලීමක් යවයි, යම් ආකෘතියකින් ප්‍රතිචාරයක් අපේක්ෂා කරයි - එපමණයි. PythonJS හට ඉල්ලීම සැකසීමටද හැකි අතර Python Flask හට ප්‍රතිචාර දැක්විය හැක. කන්ටේනර් එකිනෙක සැඟවුණු අන්තර්ගතයන් සහිත කළු පෙට්ටි වැනි ය. කෙසේ වෙතත්, NOP මූලධර්මය අනුව සෑම සේවාවක්ම එය කෙතරම් සෞඛ්‍ය සම්පන්නද යන්න මෙන්ම එහි සූදානම සහ වැරදි ඉවසීමේ තත්ත්වය පෙන්නුම් කරන බහු API අන්ත ලක්ෂ්‍ය හෙළිදරව් කිරීමට අවශ්‍ය වේ. Kubernetes මෙම දර්ශක ඉල්ලා සිටින්නේ මාර්ගගත කිරීම සහ පැටවීම තුලනය කිරීම සඳහා ඊළඟ පියවර ගැන සිතා බැලීම සඳහා ය.

හොඳින් සැලසුම් කරන ලද වලාකුළු යෙදුමක් සම්මත I/O ප්‍රවාහ STDERR සහ STDOUT භාවිතයෙන් එහි ප්‍රධාන සිදුවීම් ලොග් කරයි. ඊළඟට පැමිණෙන්නේ සහායක සේවාවකි, උදාහරණයක් ලෙස filebeat, logstash හෝ fluentd, මධ්‍යගත අධීක්ෂණ පද්ධතියකට (උදාහරණයක් ලෙස Prometheus) සහ ලොග් එකතු කිරීමේ පද්ධතියකට (ELK මෘදුකාංග කට්ටලය) ලඝු-සටහන් බෙදා හැරීම. සෞඛ්‍ය පරීක්ෂණ රටාවට සහ ඉහළ නිරීක්ෂණ මූලධර්මයට අනුව ක්ලවුඩ් යෙදුමක් ක්‍රියා කරන ආකාරය පහත රූප සටහනේ දැක්වේ.

Kubernetes හි සෞඛ්‍ය පරීක්‍ෂණ රටාව යොදන්නේ කෙසේද?

කොටුවෙන් පිටත, k8s පාලකයන්ගෙන් එකක් භාවිතයෙන් කරල්වල තත්ත්වය නිරීක්ෂණය කරයි (යෙදවීම, අනුරූ කට්ටල, DaemonSets, StatefulSets ආදිය, ආදිය). කිසියම් හේතුවක් නිසා පොඩ් එක වැටී ඇති බව සොයා ගැනීමෙන් පසු, පාලකය එය නැවත ආරම්භ කිරීමට හෝ වෙනත් නෝඩයකට ගෙන යාමට උත්සාහ කරයි. කෙසේ වෙතත්, පොඩ් එකක් එය ක්‍රියාත්මක වන බව වාර්තා කළ හැකි නමුත් එයම ක්‍රියාත්මක නොවේ. අපි උදාහරණයක් දෙන්නෙමු: ඔබගේ යෙදුම වෙබ් සේවාදායකයක් ලෙස Apache භාවිතා කරයි, ඔබ පොකුරේ කරල් කිහිපයක සංරචකය ස්ථාපනය කර ඇත. පුස්තකාලය වැරදි ලෙස වින්‍යාස කර ඇති බැවින්, යෙදුම සඳහා වන සියලුම ඉල්ලීම් කේතය 500 (අභ්‍යන්තර සේවාදායක දෝෂය) සමඟ ප්‍රතිචාර දක්වයි. බෙදාහැරීම පරීක්ෂා කිරීමේදී, කරල් වල තත්ත්වය පරීක්ෂා කිරීම සාර්ථක ප්රතිඵලයක් ලබා දෙයි, නමුත් ගනුදෙනුකරුවන් සිතන්නේ වෙනස් ආකාරයකටය. මෙම නුසුදුසු තත්වය අපි පහත පරිදි විස්තර කරන්නෙමු:

අපගේ උදාහරණයේ, k8s කරයි ක්රියාකාරිත්වය පරීක්ෂා කිරීම. මෙම ආකාරයේ සත්යාපනය තුළ, kubelet අඛණ්ඩව කන්ටේනරයේ ක්රියාවලියේ තත්වය පරීක්ෂා කරයි. ක්රියාවලිය නතර වී ඇති බව ඔහු තේරුම් ගත් පසු, ඔහු එය නැවත ආරම්භ කරයි. යෙදුම යලි ආරම්භ කිරීමෙන් දෝෂය නිරාකරණය කළ හැකි නම් සහ ඕනෑම දෝෂයක් මත වසා දැමීමට වැඩසටහන සැලසුම් කර තිබේ නම්, NOP සහ සෞඛ්‍ය පරීක්ෂණ රටාව අනුගමනය කිරීමට ඔබට අවශ්‍ය වන්නේ ක්‍රියාවලි සෞඛ්‍ය පරීක්ෂාවකි. එකම අනුකම්පාව වන්නේ නැවත ආරම්භ කිරීමෙන් සියලුම දෝෂ ඉවත් නොකිරීමයි. මෙම අවස්ථාවේදී, k8s මඟින් පොඩ් සමඟ ගැටලු හඳුනා ගැනීමට ගැඹුරු ක්‍රම 2ක් ඉදිරිපත් කරයි: සජීවී පරීක්ෂණ и සූදානම විමර්ශනය.

LivenessProbe

අතරතුර සජීවී පරීක්ෂණ kubelet චෙක්පත් වර්ග 3 ක් සිදු කරයි: පොඩ් එක ක්‍රියාත්මක වේද යන්න පමණක් නොව, ඉල්ලීම් ලැබීමට සහ ප්‍රමාණවත් ලෙස ප්‍රතිචාර දැක්වීමට එය සූදානම්ද යන්න තීරණය කරයි:

• පොඩ් එකට HTTP ඉල්ලීමක් සකසන්න. ප්‍රතිචාරයේ 200 සිට 399 දක්වා පරාසයක HTTP ප්‍රතිචාර කේතයක් අඩංගු විය යුතුය. මේ අනුව, 5xx සහ 4xx කේත මඟින් ක්‍රියාවලිය ක්‍රියාත්මක වුවද, පොඩ් එකට ගැටලු ඇති බවට සංඥා කරයි.
• HTTP නොවන සේවාවන් සමඟ පොඩ් පරීක්ෂා කිරීමට (උදාහරණයක් ලෙස, Postfix තැපැල් සේවාදායකය), ඔබ TCP සම්බන්ධතාවයක් ස්ථාපිත කළ යුතුය.
• Pod (අභ්‍යන්තරව) සඳහා අත්තනෝමතික විධානයක් ක්‍රියාත්මක කරන්න. විධාන සම්පූර්ණ කිරීමේ කේතය 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')
})

ඩොකර්ෆයිල්

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

මෙය සටහන් කිරීම වැදගත්ය: livenessProbe කන්ටේනරය නැවත ආරම්භ කරන්නේ එය අසාර්ථක වුවහොත් පමණි. නැවත ආරම්භ කිරීම මඟින් කන්ටේනරය ක්‍රියාත්මක වීම වළක්වන දෝෂය නිවැරදි නොකරන්නේ නම්, ගැටළුව නිවැරදි කිරීමට ක්‍රියා කිරීමට kubelet හට නොහැකි වනු ඇත.

සූදානම විමර්ශනය

ReadinessProbe දෝශ නිරාකරණ ක්‍රියාවන් හැර livenessProbes (GET ඉල්ලීම්, TCP සන්නිවේදන සහ විධාන ක්‍රියාත්මක කිරීම) හා සමානව ක්‍රියා කරයි. අසාර්ථකත්වය හඳුනාගත් කන්ටේනරය නැවත ආරම්භ කර නැත, නමුත් එන ගමනාගමනයෙන් හුදකලා වේ. එක් බහාලුමක් බොහෝ ගණනය කිරීම් සිදු කරන බව හෝ අධික බරක් යටතේ පවතින බව සිතන්න, ප්‍රතිචාර කාලය වැඩි වීමට හේතු වේ. livenessProbe සම්බන්ධයෙන්, ප්‍රතිචාර ලබා ගැනීමේ පරීක්‍ෂණය ක්‍රියාරම්භ කරනු ලැබේ (කාලය අවසන් තත්පර පරීක්‍ෂා කිරීමේ පරාමිතිය හරහා), ඉන් පසුව kubelet කන්ටේනරය නැවත ආරම්භ කරයි. ආරම්භ කරන විට, කන්ටේනරය සම්පත්-දැඩි කාර්යයන් ඉටු කිරීමට පටන් ගන්නා අතර නැවත නැවත ආරම්භ වේ. ප්‍රතිචාර වේගය අවශ්‍ය යෙදුම් සඳහා මෙය ඉතා වැදගත් විය හැක. උදාහරණයක් ලෙස, පාරේ යන විට මෝටර් රථයක් සේවාදායකයෙන් ප්‍රතිචාරයක් බලාපොරොත්තුවෙන් සිටී, ප්‍රතිචාරය ප්‍රමාද වේ - සහ මෝටර් රථය අනතුරකට ලක් වේ.

GET ඉල්ලීම් ප්‍රතිචාර කාලය තත්පර දෙකකට නොවැඩි ලෙස සකසන redinessProbe අර්ථ දැක්වීමක් ලියමු, සහ යෙදුම තත්පර 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

අපි තත්පර කිහිපයක් බලා සිටිමු, පසුව සූදානමProbe ක්‍රියා කළේ කෙසේදැයි බලමු:

kubectl describe pods nodedelayed

ප්‍රතිදානය අවසානයේ සමහර සිදුවීම් සමාන බව ඔබට පෙනෙනු ඇත මේක.

ඔබට පෙනෙන පරිදි, පරීක්ෂා කිරීමේ කාලය තත්පර 2 ඉක්මවන විට kubectl පොඩ් එක නැවත ආරම්භ කළේ නැත. ඒ වෙනුවට ඔහු ඉල්ලීම අවලංගු කළේය. එන සන්නිවේදනයන් වෙනත් වැඩ කරන පොඩ් වෙත හරවා යවනු ලැබේ.

දැන් පොඩ් එක ඕෆ්ලෝඩ් වී ඇති බැවින්, kubectl routes නැවත එයට ඉල්ලීම් කරන බව සලකන්න: 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; ඩී
වලාකුළු යෙදුම් පැමිණීමට පෙර, යෙදුම් සෞඛ්‍යය නිරීක්ෂණය කිරීමේ සහ පරීක්ෂා කිරීමේ මූලික මාධ්‍යයන් වූයේ ලඝු-සටහන් ය. කෙසේ වෙතත්, නිවැරදි ක්‍රියාමාර්ගයක් ගැනීමට ක්‍රමයක් නොතිබුණි. ලඝු-සටහන් අදටත් ප්‍රයෝජනවත් වේ; හදිසි අවස්ථා විශ්ලේෂණය කිරීමට සහ තීරණ ගැනීමට ඒවා එකතු කර ලොග් එකතු කිරීමේ පද්ධතියකට යැවිය යුතුය. [උදාහරණයක් ලෙස, මොනිට් භාවිතයෙන් වලාකුළු යෙදුම් නොමැතිව මේ සියල්ල කළ හැකිය, නමුත් k8s සමඟ එය වඩාත් පහසු විය :) - සංස්කාරක සටහන. ]

අද, නිවැරදි කිරීම් තථ්‍ය කාලීනව සිදු කළ යුතු බැවින් යෙදුම් තවදුරටත් කළු පෙට්ටි විය යුතු නැත. නැත, අවශ්‍ය නම් ක්‍ෂණිකව ප්‍රතිචාර දැක්වීමට හැකි වන පරිදි ක්‍රියාවලි තත්ත්වය පිළිබඳ වටිනා දත්ත විමසීමට සහ රැස් කිරීමට අධීක්ෂණ පද්ධතිවලට ඉඩ සලසන අන්ත ලක්ෂ්‍ය ඔවුන් පෙන්විය යුතුය. මෙය ඉහළ නිරීක්ෂණ මූලධර්මය (HOP) අනුගමනය කරන කාර්ය සාධන පරීක්ෂණ සැලසුම් රටාව ලෙස හැඳින්වේ.

Kubernetes පෙරනිමියෙන් සෞඛ්‍ය පරීක්‍ෂණ වර්ග 2ක් පිරිනමයි: ReadinessProbe සහ livenessProbe. දෙකම එකම වර්ගයේ චෙක්පත් භාවිතා කරයි (HTTP GET ඉල්ලීම්, TCP සන්නිවේදන සහ විධාන ක්‍රියාත්මක කිරීම). කරල් වල ගැටළු වලට ප්‍රතිචාර වශයෙන් ඔවුන් ගන්නා තීරණ වෙනස් වේ. livenessProbe දෝෂය නැවත සිදු නොවනු ඇතැයි යන බලාපොරොත්තුවෙන් කන්ටේනරය නැවත ආරම්භ කරන අතර, ගැටලුවට හේතුව විසඳන තෙක් ReadinessProbe පැමිණෙන තදබදයෙන් පොඩ් එක හුදකලා කරයි.

නිසි යෙදුම් සැලසුමට පරීක්ෂා කිරීම් වර්ග දෙකම ඇතුළත් විය යුතු අතර, විශේෂයෙන් ව්‍යතිරේකයක් දමන විට ඒවා ප්‍රමාණවත් දත්ත රැස් කරන බවට සහතික විය යුතුය. එය වැදගත් සෞඛ්‍ය ප්‍රමිතික සමඟ අධීක්ෂණ පද්ධතිය (Prometheus) සපයන අවශ්‍ය API අන්ත ලක්ෂ්‍ය ද පෙන්විය යුතුය.

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