د کبرنیټ کانټینرونو لپاره غوره تمرینونه: روغتیا معاینه

د تمديد؛ DR

• د کانټینرونو او مایکرو خدماتو لوړ لید ترلاسه کولو لپاره ، لاګونه او لومړني میټریکونه کافي ندي.
• د ګړندي رغیدو او ډیر مقاومت لپاره ، غوښتنلیکونه باید د عالي مشاهدې اصول (HOP) پلي کړي.
• د غوښتنلیک په کچه، NOP ته اړتیا لري: مناسب ننوتل، نږدې څارنه، د هوښیارتیا چک، او د فعالیت / لیږد تعقیب.
• چکونه د NOR د عنصر په توګه وکاروئ چمتووالی پروب и ژوندیتوب Kubernetes.

د روغتیا چیک ټیمپلیټ څه شی دی؟

کله چې د ماموریت مهم او خورا شتون لرونکي غوښتنلیک ډیزاین کړئ ، نو دا خورا مهم دي چې د داسې اړخ په اړه فکر وکړئ لکه د غلطۍ زغم. یو غوښتنلیک د غلطۍ زغمونکی ګڼل کیږي که چیرې دا د ناکامۍ څخه ژر تر ژره روغ شي. یو عادي کلاوډ غوښتنلیک د مایکرو خدماتو جوړښت کاروي - چیرې چې هره برخه په جلا کانټینر کې ځای پرځای کیږي. او د دې لپاره چې ډاډ ترلاسه کړئ چې په k8s کې غوښتنلیک خورا شتون لري کله چې تاسو کلستر ډیزاین کړئ ، تاسو اړتیا لرئ ځینې نمونې تعقیب کړئ. د دوی په مینځ کې د روغتیا چیک ټیمپلیټ دی. دا تعریفوي چې څنګه غوښتنلیک k8s ته خبر ورکوي چې دا صحي دی. دا نه یوازې د دې په اړه معلومات دي چې آیا پوډ روان دی، بلکې دا هم په دې اړه چې دا څنګه غوښتنې ترلاسه کوي او ځواب ورکوي. هرڅومره چې کوبرنیټس د پوډ روغتیا په اړه پوهیږي ، هومره هوښیار پریکړې چې دا د ترافیک روټینګ او بار توازن په اړه کوي. په دې توګه، د لوړ کتنې اصول غوښتنلیک ته اجازه ورکوي چې په وخت سره غوښتنو ته ځواب ووايي.

د لوړ کتنې اصول (HOP)

د لوړې مشاهدې اصول یو له دې څخه دی د کانټینر شوي غوښتنلیکونو ډیزاین کولو اصول. د مایکرو خدماتو جوړښت کې، خدمتونه پروا نه کوي چې د دوی غوښتنې څنګه پروسس کیږي (او په سمه توګه)، مګر څه مهم دي چې دوی څنګه د ترلاسه کونکي خدماتو څخه ځوابونه ترلاسه کوي. د مثال په توګه، د یو کاروونکي تصدیق کولو لپاره، یو کانټینر بل ته د HTTP غوښتنه لیږي، په یو ځانګړي بڼه کې د ځواب تمه لري - دا ټول دي. PythonJS کولی شي غوښتنه هم پروسس کړي، او Python فلاسک ځواب کولی شي. کانټینرونه د تور بکسونو په څیر دي چې یو بل ته پټ مواد لري. په هرصورت، د NOP اصول هر خدمت ته اړتیا لري څو د API ډیری پای ټکي افشا کړي چې دا په ګوته کوي چې دا څومره صحي دی، او همدارنګه د هغې چمتووالی او د غلطی زغم حالت. Kubernetes د دې شاخصونو غوښتنه کوي ترڅو د روټینګ او بار توازن لپاره د راتلونکو مرحلو په اړه فکر وکړي.

یو ښه ډیزاین شوی کلاوډ غوښتنلیک د معیاري I/O جریانونو STDERR او STDOUT په کارولو سره خپلې اصلي پیښې ثبتوي. بیا یو مرستندویه خدمت راځي، د بیلګې په توګه فایل بیټ، لوګسټاش یا روانی، د مرکزي څارنې سیسټم (د بیلګې په توګه پرومیتیس) او د لاګ راټولولو سیسټم (ELK سافټویر سویټ) ته لاګونه وړاندې کوي. لاندې ډیاګرام ښیې چې د بادل غوښتنلیک څنګه د روغتیا ازموینې نمونې او د لوړ لید لید اصول سره سم کار کوي.

په کبرنیټس کې د روغتیا چک نمونه څنګه پلي کول؟

د بکس څخه بهر، k8s د یو کنټرولر په کارولو سره د پوډونو حالت څارنه کوي (پلي کول, ReplicaSets, DaemonSets, StatefulSets وغیره، وغيره). د موندلو سره چې پوډ د کوم دلیل لپاره راوتلی، کنټرولر هڅه کوي چې دا بیا پیل کړي یا بل نوډ ته یې واړوي. په هرصورت، یو پوډ ممکن راپور ورکړي چې دا پورته او روان دی، مګر دا پخپله کار نه کوي. راځئ چې یو مثال ورکړو: ستاسو غوښتنلیک اپاپي د ویب سرور په توګه کاروي، تاسو د کلستر په څو پوډونو کې برخه نصب کړې. څرنګه چې کتابتون په غلط ډول ترتیب شوی و، د غوښتنلیک ټولې غوښتنې د کوډ 500 سره ځواب ورکوي (د سرور داخلي تېروتنه). کله چې تحویلي چک کول ، د پوډونو حالت چیک کول بریالۍ پایله ورکوي ، مګر پیرودونکي بل ډول فکر کوي. موږ به دا ناغوښتل حالت په لاندې ډول تشریح کړو:

زموږ په مثال کې، k8s کوي د فعالیت چک. په دې ډول تایید کې، کوبیلټ په دوامداره توګه په کانټینر کې د پروسې حالت ګوري. یوځل چې هغه پوه شي چې پروسه بنده شوې، هغه به بیا پیل کړي. که چیرې تېروتنه په ساده ډول د غوښتنلیک په بیا پیلولو سره حل شي، او برنامه د هرې غلطۍ بندولو لپاره ډیزاین شوې، نو بیا د پروسې روغتیا معاینه ټول هغه څه دي چې تاسو ورته اړتیا لرئ د NOP او روغتیا ازموینې نمونه تعقیب کړئ. یوازینۍ خواشینۍ دا ده چې ټولې غلطۍ د بیا پیل کولو سره نه له مینځه وړل کیږي. په دې حالت کې، k8s د پوډ سره د ستونزو پیژندلو لپاره 2 ژورې لارې وړاندې کوي: ژوندیتوب и چمتووالی پروب.

LivenessProbe

په دوران کې ژوندیتوب کوبیلټ 3 ډوله چکونه ترسره کوي: نه یوازې دا مشخص کوي چې ایا پوډ روان دی، بلکې دا هم د ترلاسه کولو لپاره چمتو دی او غوښتنو ته په کافي اندازه ځواب ورکوي:

• پوډ ته د HTTP غوښتنه ترتیب کړئ. ځواب باید د 200 څخه تر 399 پورې رینج کې د HTTP ځواب کوډ ولري. په دې توګه، کوډونه 5xx او 4xx سیګنال کوي چې پوډ ستونزې لري، که څه هم پروسه روانه وي.
• د غیر HTTP خدماتو سره د پوډونو ازموینې لپاره (د مثال په توګه ، د پوسټ فکس میل سرور) ، تاسو اړتیا لرئ د TCP پیوستون رامینځته کړئ.
• د پوډ (داخلي) لپاره خپل سري قومانده اجرا کړئ. چک بریالی ګڼل کیږي که چیرې د کمانډ بشپړولو کوډ 0 وي.

یو مثال چې دا څنګه کار کوي. راتلونکی پوډ تعریف د NodeJS غوښتنلیک لري چې د 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 به یوازې کانټینر بیا پیل کړي که چیرې ناکام شي. که بیا پیل کول هغه تېروتنه سمه نه کړي چې د کانټینر د چلولو مخه نیسي، کیوبیلټ به ونه شي کولی د ستونزې سمولو لپاره اقدام وکړي.

چمتووالی پروب

ReadinessProbe د ژوندانه پروبس (GET غوښتنې، د TCP مخابراتو او د قوماندې اجرا کول) سره ورته کار کوي، پرته له دې چې د ستونزو حل کولو کړنو څخه. هغه کانټینر چې په کې ناکامي وموندل شوه بیا نه پیل کیږي، مګر د راتلونکی ټرافیک څخه جلا شوی. تصور وکړئ چې یو کانټینر ډیری محاسبې ترسره کوي یا د ډیر بار لاندې دي، د غبرګون وخت زیاتوالي لامل کیږي. د LivenessProbe په حالت کې، د ځواب شتون چک پیل کیږي (د وخت پای د ثانیو چیک پیرامیټر له لارې)، وروسته له دې چې کیوبیل کانټینر بیا پیل کوي. کله چې پیل شي، کانټینر د سرچینو ژورې دندې ترسره کول پیل کوي او بیا بیا پیل کیږي. دا د غوښتنلیکونو لپاره مهم کیدی شي چې د غبرګون سرعت ته اړتیا لري. د مثال په توګه، یو موټر په داسې حال کې چې په سړک کې د سرور څخه ځواب ته انتظار کوي، ځواب ځنډول کیږي - او موټر په حادثه کې راځي.

راځئ چې د redinessProbe تعریف ولیکئ چې د 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 ثانیو څخه ډیر شو. پرځای یې، هغه غوښتنه رد کړه. راتلونکی مخابرات نورو، کاري پوډونو ته لیږدول کیږي.

په یاد ولرئ چې اوس چې پوډ اپلوډ شوی، د کوبکټل لارې بیا ورته غوښتنه کوي: د 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')
})

د تمديد؛ DR
د کلاوډ غوښتنلیکونو له راتګ دمخه ، لاګونه د غوښتنلیک روغتیا نظارت او چک کولو لومړنۍ وسیله وه. په هرصورت، د اصلاحي ګام پورته کولو لپاره هیڅ وسیله شتون نلري. لاګونه نن ورځ هم ګټور دي؛ دوی باید راټول شي او د بیړني حالتونو تحلیل او پریکړې کولو لپاره د لاګ راټولولو سیسټم ته واستول شي. [دا ټول د مونیټ په کارولو سره د کلاوډ غوښتنلیکونو پرته ترسره کیدی شي ، د مثال په توګه ، مګر د k8s سره دا خورا اسانه شو :) - د مدیر یادونه. ]

نن ورځ، سمون باید په ریښتیني وخت کې ترسره شي، نو غوښتنلیکونه نور اړتیا نلري تور بکسونه وي. نه، دوی باید پای ټکي وښيي چې د څارنې سیسټمونو ته اجازه ورکوي چې د پروسو د حالت په اړه ارزښتناک معلومات پوښتنې او راټول کړي ترڅو دوی د اړتیا په صورت کې سمدستي ځواب ووايي. دې ته د فعالیت ازموینې ډیزاین نمونه ویل کیږي، کوم چې د لوړ کتنې اصول (HOP) تعقیبوي.

Kubernetes په ډیفالټ ډول دوه ډوله روغتیایی معاینات وړاندیز کوي: ReadinessProbe او livenessProbe. دواړه ورته چکونه کاروي (HTTP GET غوښتنې، د TCP مخابرات او د قوماندې اجرا کول). دوی په پوډونو کې د ستونزو په ځواب کې د کومې پریکړې په اړه توپیر لري. livenessProbe په دې هیله کانټینر بیا پیلوي چې تېروتنه به بیا نه پیښیږي، او ReadinessProbe پوډ د راتلونکو ترافیکو څخه جلا کوي تر هغه چې د ستونزې لامل حل نشي.

د غوښتنلیک مناسب ډیزاین باید دواړه ډوله چکونه پکې شامل وي او ډاډ ترلاسه کړي چې دوی کافي ډیټا راټولوي ، په ځانګړي توګه کله چې یو استثنا وغورځول شي. دا باید د API اړین پای ټکي هم وښیې چې د څارنې سیسټم (Prometheus) د مهم روغتیا میټریکونو سره چمتو کوي.

سرچینه: www.habr.com