Kubernetes контейнерлери үчүн мыкты тажрыйбалар: Ден соолукту текшерүү

TL; DR

• Контейнерлердин жана микросервистердин жогорку байкалышына жетишүү үчүн журналдар жана баштапкы көрсөткүчтөр жетишсиз.
• Тезирээк калыбына келтирүү жана ийкемдүүлүктү жогорулатуу үчүн, тиркемелер Жогорку байкоо жүргүзүү принцибин (HOP) колдонушу керек.
• Колдонмо деңгээлинде NOP төмөнкүлөрдү талап кылат: туура каттоо, жакын мониторинг, акыл-эсти текшерүү жана аткаруу/өткөөлгө байкоо жүргүзүү.
• Чектерди NOR элементи катары колдонуңуз даярдыгыПроб и livenessProbe Kubernetes.

Ден соолукту текшерүү шаблону деген эмне?

Критикалык жана жеткиликтүү тиркемени иштеп чыгууда, катага чыдамдуулук сыяктуу аспект жөнүндө ойлонуу абдан маанилүү. Тиркеме катадан тез калыбына келсе, катага чыдамдуу деп эсептелет. Кадимки булут колдонмосу микросервис архитектурасын колдонот - мында ар бир компонент өзүнчө контейнерге жайгаштырылат. Жана кластерди иштеп чыгууда k8s тиркемесинин жеткиликтүү болушуна ынануу үчүн, сиз белгилүү үлгүлөрдү карманышыңыз керек. Алардын арасында Ден соолукту текшерүү шаблону бар. Бул колдонмонун ден-соолукта экенин k8s менен кантип байланыштырарын аныктайт. Бул подкасттын иштеп жаткандыгы жөнүндө гана маалымат эмес, ошондой эле анын суроо-талаптарды кантип кабыл алып, аларга жооп берери жөнүндө. Кубернетес поддондун ден соолугу жөнүндө канчалык көп билсе, трафиктин маршруту жана жүктү тең салмактоо боюнча ошончолук акылдуу чечимдерди кабыл алат. Ошентип, High Observability Principle өтүнмө өз убагында суроо-талаптарга жооп берет.

Жогорку байкоо жүргүзүү принциби (HOP)

Жогорку байкоочулук принциби бири болуп саналат контейнердик колдонмолорду долбоорлоо принциптери. Микросервис архитектурасында кызматтар алардын суроо-талаптары кандайча иштетилип жатканына маани бербейт (жана туура), бирок алар кабыл алуучу кызматтардан кандай жооп алаары маанилүү. Мисалы, колдонуучунун аутентификациясы үчүн, бир контейнер HTTP суроо-талапты экинчисине жөнөтүп, белгилүү бир форматта жооп күтөт - ушунча. PythonJS да өтүнүчтү иштете алат жана Python Flask жооп бере алат. Контейнерлер бири-бирине жашыруун мазмуну бар кара кутучалар сыяктуу. Бирок, NOP принциби ар бир кызматтан анын канчалык ден-соолукта экенин, ошондой эле даярдыгын жана катага чыдамдуулук абалын көрсөткөн бир нече API акыркы чекиттерин көрсөтүүнү талап кылат. Kubernetes бул көрсөткүчтөрдү маршрутташтыруу жана жүктү тең салмактоо боюнча кийинки кадамдарды ойлонуу үчүн сурайт.

Жакшы иштелип чыккан булут колдонмосу STDERR жана STDOUT стандарттык киргизүү/чыгаруу агымдарын колдонуу менен өзүнүн негизги окуяларын журналга жазат. Андан кийин көмөкчү кызмат келет, мисалы filebeat, logstash же fluentd, журналдарды борборлоштурулган мониторинг системасына (мисалы, Prometheus) жана журналдарды чогултуу тутумуна (ELK программалык комплекси). Төмөнкү диаграмма булут тиркемесинин Ден соолук тестинин үлгүсүнө жана Жогорку байкоого жөндөмдүүлүк принцибине ылайык кантип иштээрин көрсөтөт.

Kubernetes'те Ден соолукту текшерүү үлгүсүн кантип колдонсо болот?

Кутудан тышкары, k8s контроллерлордун бирин колдонуп, капчыктардын абалын көзөмөлдөйт (жайгаштыруу, ReplicaSets, DaemonSets, StatefulSets ж.б., ж.б.). Подча кандайдыр бир себептерден улам кулап калганын билип, контроллер аны кайра иштетүүгө же башка түйүнгө жылдырууга аракет кылат. Бирок, поддон иштеп жатат деп кабарлашы мүмкүн, бирок ал иштебей жатат. Мисал келтирели: сиздин тиркемеңиз Apacheди веб-сервер катары колдонот, сиз компонентти кластердин бир нече подкесине орноттуңуз. Китепкана туура эмес конфигурациялангандыктан, колдонмого бардык суроо-талаптар 500 коду менен жооп берет (ички сервер катасы). Жеткирүүнү текшерүүдө, потоктордун абалын текшерүү ийгиликтүү натыйжа берет, бирок кардарлар башкача ойдо. Бул жагымсыз абалды төмөнкүчө сүрөттөйбүз:

Биздин мисалда, k8s кылат функционалдык текшерүү. Текшерүүнүн бул түрүндө кубелет контейнердеги процесстин абалын тынымсыз текшерип турат. Процесс токтоп калганын түшүнгөндөн кийин, аны кайра баштайт. Эгерде катаны жөн гана колдонмону өчүрүп-күйгүзүү менен чечүү мүмкүн болсо жана программа кандайдыр бир катаны өчүрүү үчүн иштелип чыккан болсо, анда процесстин ден соолугун текшерүү сизге NOP жана Ден соолук тестинин үлгүсүн ээрчүү үчүн гана керек. Бир гана өкүнүчтүүсү, бардык каталар кайра иштетүү менен жок кылынбайт. Бул учурда, k8s поддон менен көйгөйлөрдү аныктоо үчүн 2 тереңирээк жолдорун сунуш кылат: livenessProbe и даярдыгыПроб.

LivenessProbe

Убагында 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 менен бул бир топ жеңилдеди :) – редактордун эскертүүсү. ]

Бүгүнкү күндө оңдоолор дээрлик реалдуу убакытта жасалышы керек, андыктан тиркемелер кара кутуча болбошу керек. Жок, алар мониторинг тутумдарына процесстердин абалы жөнүндө баалуу маалыматтарды суроого жана чогултууга мүмкүндүк берген акыркы чекиттерди көрсөтүшү керек, алар зарыл болсо, ошол замат жооп бере алышат. Бул Performance Test Design Pattern деп аталат, ал High Observability Principle (HOP) ээрчийт.

Kubernetes демейки боюнча ден соолукту текшерүүнүн 2 түрүн сунуштайт: readinessProbe жана livenessProbe. Экөө тең текшерүүлөрдүн бирдей түрлөрүн колдонушат (HTTP GET сурамдары, TCP байланышы жана буйруктун аткарылышы). Алар ар кандай чечимдерди кабыл алуу менен айырмаланат. livenessProbe ката кайра кайталанбайт деген үмүт менен контейнерди кайра иштетет, ал эми readinessProbe көйгөйдүн себеби чечилмейинче поддонду кирүүчү трафиктен бөлүп коёт.

Тиешелүү тиркеме дизайны текшерүүнүн эки түрүн камтышы керек жана алар жетиштүү маалыматтарды чогултушун камсыз кылышы керек, өзгөчө өзгөчөлүктөр ташталганда. Ошондой эле мониторинг системасын (Прометей) ден соолуктун маанилүү көрсөткүчтөрү менен камсыз кылган зарыл API акыркы чекиттерин көрсөтүшү керек.

Source: www.habr.com