Kubernetes контейнерлеріне арналған ең жақсы тәжірибелер: денсаулықты тексеру

TL; DR

• Контейнерлер мен микросервистердің жоғары байқалатындығына қол жеткізу үшін журналдар мен бастапқы көрсеткіштер жеткіліксіз.
• Тезірек қалпына келтіру және икемділікті арттыру үшін қолданбалар жоғары бақылау принципін (HOP) қолдануы керек.
• Қолданба деңгейінде NOP мыналарды талап етеді: дұрыс тіркеу, мұқият бақылау, ақыл-ойды тексеру және өнімділік/өтпелі кезеңді бақылау.
• NOR элементі ретінде чектерді пайдаланыңыз дайындығын тексеру и жандылықЗонд Кубернетес.

Денсаулықты тексеру үлгісі дегеніміз не?

Өте маңызды және қол жетімді қолданбаны құрастырған кезде ақауларға төзімділік сияқты аспекті туралы ойлану өте маңызды. Қолданба ақаулықтан тез қалпына келсе, қатеге төзімді болып саналады. Әдеттегі бұлттық қолданба микросервис архитектурасын пайдаланады - мұнда әрбір құрамдас бөлек контейнерге орналастырылады. Кластерді құрастырған кезде k8s қолданбасының қол жетімді екеніне көз жеткізу үшін белгілі бір үлгілерді орындау қажет. Олардың арасында Денсаулықты тексеру үлгісі бар. Ол қолданбаның сау екенін k8s-ге қалай хабарлайтынын анықтайды. Бұл подкасттың жұмыс істеп тұрғаны туралы ғана емес, сонымен қатар оның сұрауларды қалай қабылдайтыны және оларға жауап беретіні туралы ақпарат. Кубернетес подкасттың денсаулығы туралы неғұрлым көп білсе, трафикті бағыттау және жүктемені теңестіру туралы соғұрлым ақылды шешімдер қабылдайды. Осылайша, жоғары бақылау принципі қолданбаға сұрауларға дер кезінде жауап беруге мүмкіндік береді.

Жоғары бақылау принципі (HOP)

Жоғары байқалу принципі бірі болып табылады контейнерлік қосымшаларды жобалау принциптері. Микросервистердің архитектурасында қызметтер олардың сұрауының қалай өңделетініне (және дұрыс) мән бермейді, бірақ олардың қабылдаушы қызметтерден жауаптарды қалай алатыны маңызды. Мысалы, пайдаланушының аутентификациясы үшін бір контейнер басқасына HTTP сұрауын жібереді, белгілі бір пішімдегі жауапты күтеді - барлығы осы. PythonJS да сұрауды өңдей алады және Python Flask жауап бере алады. Контейнерлер бір-біріне жасырылған мазмұны бар қара жәшіктер сияқты. Дегенмен, NOP принципі әрбір қызметтен оның қаншалықты сау екенін, сондай-ақ оның дайындығы мен ақауларға төзімділік күйін көрсететін бірнеше API соңғы нүктелерін көрсетуді талап етеді. Кубернетес маршруттау және жүктемені теңестіру үшін келесі қадамдарды ойластыру үшін осы көрсеткіштерді сұрайды.

Жақсы жобаланған бұлттық қолданба стандартты енгізу/шығару ағындары STDERR және STDOUT арқылы негізгі оқиғаларын тіркейді. Одан кейін орталықтандырылған бақылау жүйесіне (мысалы, Prometheus) журналдарды және журналдарды жинау жүйесіне (ELK бағдарламалық жасақтама жиынтығы) жеткізетін, мысалы, filebeat, logstash немесе fluentd сияқты көмекші қызмет келеді. Төмендегі диаграмма денсаулық сынағы үлгісіне және жоғары бақылау принципіне сәйкес бұлттық қолданбаның қалай жұмыс істейтінін көрсетеді.

Кубернетестегі денсаулықты тексеру үлгісін қалай қолдануға болады?

Қораптан тыс, k8s контроллерлердің бірін пайдаланып, блоктардың күйін бақылайды (Орналастыру, ReplicaSets, DaemonSets, StatefulSets т.б. және т.б.). Қондырғының қандай да бір себептермен құлағанын анықтаған контроллер оны қайта іске қосуға немесе басқа түйінге жылжытуға тырысады. Дегенмен, подвод жұмыс істеп тұрғанын хабарлауы мүмкін, бірақ оның өзі жұмыс істемейді. Мысал келтірейік: сіздің қолданбаңыз Apache-ті веб-сервер ретінде пайдаланады, сіз компонентті кластердің бірнеше подкағына орнаттыңыз. Кітапхана дұрыс конфигурацияланбағандықтан, қолданбаның барлық сұраулары 500 кодымен жауап береді (ішкі сервер қатесі). Жеткізуді тексергенде, бөтелкелердің күйін тексеру сәтті нәтиже береді, бірақ тұтынушылар басқаша ойлайды. Біз бұл жағымсыз жағдайды былай сипаттаймыз:

Біздің мысалда k8s жасайды функционалдығын тексеру. Тексерудің бұл түрінде кубелет контейнердегі процестің күйін үздіксіз тексереді. Процестің тоқтағанын түсінгеннен кейін ол оны қайта бастайды. Қатені қолданбаны жай ғана қайта іске қосу арқылы шешуге болатын болса және бағдарлама кез келген қатені өшіруге арналған болса, NOP және Денсаулықты тексеру үлгісін орындау үшін процестің күйін тексеру қажет. Жалғыз өкініштісі, барлық қателер қайта іске қосу арқылы жойылмайды. Бұл жағдайда k8s подводтағы ақауларды анықтаудың 2 тереңірек әдісін ұсынады: жандылықЗонд и дайындығын тексеру.

LivenessProbe

Уақытында жандылықЗонд 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')
})

Докер файлы

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

Мынаны ескеру маңызды: livenessProbe егер ол сәтсіз болса ғана контейнерді қайта іске қосады. Қайта іске қосу контейнердің жұмыс істеуіне кедергі келтіретін қатені түзетпесе, kubelet мәселені түзету үшін әрекет ете алмайды.

дайындығын тексеру

ReadinessProbe ақауларды жою әрекеттерін қоспағанда livenessProbes (GET сұраулары, TCP байланысы және пәрменді орындау) сияқты жұмыс істейді. Ақаулық анықталған контейнер қайта іске қосылмайды, бірақ кіріс трафиктен оқшауланған. Контейнерлердің бірі көп есептеулерді орындап жатқанын немесе ауыр жүктеме астында екенін елестетіп көріңіз, бұл жауап беру уақытының артуына әкеледі. livenessProbe жағдайында жауаптың қолжетімділігін тексеру іске қосылады (timeoutSeconds тексеру параметрі арқылы), содан кейін кубелет контейнерді қайта іске қосады. Іске қосылған кезде, контейнер ресурсты көп қажет ететін тапсырмаларды орындай бастайды және қайта іске қосылады. Бұл жауап беру жылдамдығын қажет ететін қолданбалар үшін өте маңызды болуы мүмкін. Мысалы, жолда келе жатқан көлік серверден жауап күтуде, жауап кешіктіріліп, көлік апатқа ұшырайды.

GET сұрауының жауап беру уақытын екі секундтан аспайтын етіп орнататын redinessProbe анықтамасын жазайық және қолданба GET сұрауына 5 секундтан кейін жауап береді. 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

Бірнеше секунд күтейік, содан кейін ReadinessProbe қалай жұмыс істегенін көрейік:

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
Бұлтты қолданбалар пайда болғанға дейін журналдар қолданбаның күйін бақылаудың және тексерудің негізгі құралы болды. Алайда, ешқандай түзету шараларын қолдануға мүмкіндік болмады. Журналдар бүгінгі күні де пайдалы; оларды жинау және төтенше жағдайларды талдау және шешім қабылдау үшін журналдарды жинау жүйесіне жіберу қажет. [Мұның бәрін, мысалы, monit көмегімен бұлттық қолданбалардысыз жасауға болады, бірақ k8s көмегімен бұл әлдеқайда жеңіл болды :) – редактордың ескертпесі. ]

Бүгінгі күні түзетулер іс жүзінде нақты уақытта жасалуы керек, сондықтан қосымшалар енді қара жәшіктер болмауы керек. Жоқ, олар мониторинг жүйелеріне қажет болған жағдайда дереу жауап беруі үшін процестердің күйі туралы құнды деректерді сұрауға және жинауға мүмкіндік беретін соңғы нүктелерді көрсетуі керек. Бұл жоғары бақылау принципіне (HOP) сәйкес келетін өнімділік сынағы дизайн үлгісі деп аталады.

Kubernetes әдепкі бойынша денсаулықты тексерудің 2 түрін ұсынады: readinessProbe және livenessProbe. Екеуі де бірдей тексеру түрлерін пайдаланады (HTTP GET сұраулары, TCP байланысы және пәрменді орындау). Олар түйіршіктердегі мәселелерге жауап ретінде қандай шешімдер қабылдайтындығымен ерекшеленеді. livenessProbe қате қайталанбайды деген үмітпен контейнерді қайта іске қосады және readinessProbe мәселенің себебі шешілгенге дейін кіріс трафиктен подкастты оқшаулайды.

Тиісті қолданба дизайны тексерудің екі түрін де қамтуы керек және олардың жеткілікті деректерді жинауын қамтамасыз етуі керек, әсіресе ерекшелік жойылған кезде. Ол сондай-ақ бақылау жүйесін (Прометей) маңызды денсаулық көрсеткіштерімен қамтамасыз ететін қажетті API соңғы нүктелерін көрсетуі керек.

Ақпарат көзі: www.habr.com