Кубернетес савны шилдэг туршлага: Эрүүл мэндийн үзлэг

TL, DR

• Контейнер болон микро үйлчилгээний өндөр ажиглалтад хүрэхийн тулд бүртгэл, үндсэн хэмжигдэхүүн хангалтгүй байна.
• Илүү хурдан сэргэж, уян хатан чанарыг нэмэгдүүлэхийн тулд програмууд нь Ажиглалтын өндөр зарчмыг (HOP) ашиглах ёстой.
• Хэрэглээний түвшинд NOP нь дараахь зүйлийг шаарддаг: зохих бүртгэл, нягт хяналт, эрүүл саруул байдлыг шалгах, гүйцэтгэл/шилжилтийг хянах.
• Чекийг NOR-ийн элемент болгон ашигла бэлэн байдлыг шалгах и амьд байдлыг шалгах Кубернетес.

Эрүүл мэндийн үзлэгийн загвар гэж юу вэ?

Чухал ач холбогдолтой, өндөр хүртээмжтэй програмыг зохион бүтээхдээ алдааг тэсвэрлэх чадвар гэх мэт талыг бодох нь маш чухал юм. Аппликейшн нь бүтэлгүйтлээс хурдан сэргэж байвал алдаатай гэж үзнэ. Ердийн үүл програм нь микро үйлчилгээний архитектурыг ашигладаг - бүрэлдэхүүн хэсэг бүрийг тусдаа саванд байрлуулдаг. Кластер зохион бүтээхдээ k8s дээрх програмыг ашиглах боломжтой эсэхийг шалгахын тулд та тодорхой хэв маягийг дагах хэрэгтэй. Тэдний дунд Эрүүл мэндийн үзлэгийн загвар бий. Энэ нь тухайн программ нь эрүүл гэдгийг k8s-д хэрхэн дамжуулж байгааг тодорхойлдог. Энэ нь зөвхөн pod ажиллаж байгаа эсэхээс гадна хүсэлтийг хэрхэн хүлээн авч, хариу үйлдэл үзүүлэх тухай мэдээлэл юм. Кубернетес хонгилын эрүүл мэндийн талаар илүү ихийг мэдэх тусам замын хөдөлгөөний чиглүүлэлт, ачааллыг тэнцвэржүүлэх талаар илүү ухаалаг шийдвэр гаргадаг. Тиймээс Ажиглалтын өндөр зарчим нь програмд ​​хүсэлтэд цаг тухайд нь хариу өгөх боломжийг олгодог.

Ажиглалтын өндөр зарчим (HOP)

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

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

Кубернетес дэх эрүүл мэндийн үзлэгийн загварыг хэрхэн ашиглах вэ?

Хайрцагнаас гарсан k8s нь хянагчуудын аль нэгийг ашиглан хонгилын төлөвийг хянадаг (Ажиллах байр, ReplicaSets, DaemonSets, Stateful Sets гэх мэт). Под ямар нэг шалтгаанаар унасан болохыг олж мэдээд хянагч үүнийг дахин эхлүүлэх эсвэл өөр зангилаа руу шилжүүлэхийг оролддог. Гэсэн хэдий ч, pod нь ажиллаж байгаа гэж мэдээлж болох ч өөрөө ажиллахгүй байна. Нэг жишээ хэлье: таны програм Apache-г вэб сервер болгон ашигладаг, та бүрэлдэхүүн хэсгийг кластерын хэд хэдэн pods дээр суулгасан. Номын сангийн тохиргоо буруу байсан тул програмын бүх хүсэлтэд 500 (дотоод серверийн алдаа) кодоор хариу өгдөг. Хүргэлтийг шалгахдаа хонхорцог байдлыг шалгах нь амжилттай үр дүнг өгдөг боловч үйлчлүүлэгчид өөрөөр боддог. Энэ хүсээгүй нөхцөл байдлыг бид дараах байдлаар тайлбарлах болно.

Бидний жишээнд k8s үүнийг хийдэг функциональ шалгалт. Энэ төрлийн баталгаажуулалтын хувьд kubelet нь саванд байгаа процессын төлөвийг тасралтгүй шалгадаг. Тэр процесс зогссон гэдгийг ойлгосны дараа дахин эхлүүлэх болно. Хэрэв програмыг зүгээр л дахин эхлүүлснээр алдааг шийдэж болох бөгөөд програм нь аливаа алдаа гарсан тохиолдолд унтрах зориулалттай бол үйл явцын эрүүл мэндийг шалгах нь NOP болон Эрүүл мэндийн тестийн загварыг дагахад л хангалттай. Цорын ганц харамсалтай зүйл бол бүх алдааг дахин эхлүүлэх замаар арилгадаггүй. Энэ тохиолдолд k8s нь хонхорцогтой холбоотой асуудлыг тодорхойлох 2 илүү гүнзгий аргыг санал болгодог. амьд байдлыг шалгах и бэлэн байдлыг шалгах.

LivenessProbe

Үеэр амьд байдлыг шалгах kubelet нь 3 төрлийн шалгалтыг гүйцэтгэдэг: зөвхөн под ажиллаж байгаа эсэхийг тодорхойлохоос гадна хүсэлтийг хүлээн авч, зохих ёсоор хариулахад бэлэн эсэхийг тодорхойлдог.

• Pod-д HTTP хүсэлтийг тохируулна уу. Хариулт нь 200-аас 399 хүртэлх хугацаанд HTTP хариултын кодыг агуулсан байх ёстой. Тиймээс 5xx болон 4xx кодууд нь процесс ажиллаж байгаа хэдий ч pod-д асуудал гарч байгааг илтгэнэ.
• HTTP бус үйлчилгээтэй (жишээ нь Postfix мэйл сервер) подкуудыг туршихын тулд та TCP холболт үүсгэх хэрэгтэй.
• Под (дотоод) дээр дурын командыг гүйцэтгэх. Хэрэв командын гүйцэтгэлийн код 0 байвал шалгалт амжилттай болсон гэж үзнэ.

Энэ хэрхэн ажилладаг тухай жишээ. Дараагийн pod тодорхойлолт нь 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

Энэ нь бусад pod тодорхойлолтоос ялгаатай биш боловч бид объект нэмж байна .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 шалгах параметрээр), үүний дараа 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-тэй pod байрлуулцгаая:

kubectl apply -f pod.yaml

Хэдэн секунд хүлээгээд, бэлэн байдлын шалгалт хэрхэн ажилласныг харцгаая.

kubectl describe pods nodedelayed

Гаралтын төгсгөлд зарим үйл явдал ижил төстэй байгааг харж болно энэ нэг.

Таны харж байгаагаар шалгах хугацаа 2 секундээс хэтэрсэн үед kubectl pod-ыг дахин эхлүүлээгүй. Харин тэр хүсэлтээ цуцалсан. Ирж буй харилцаа холбоог бусад, ажиллаж байгаа pods руу дахин чиглүүлдэг.

Под ачааллаа алдсаны дараа 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 ашиглан үүлэн программгүйгээр хийх боломжтой байсан ч k8-ийн тусламжтайгаар энэ нь илүү хялбар болсон :) - редакторын тэмдэглэл. ]

Өнөөдөр бараг бодит цаг хугацаанд засвар хийх шаардлагатай болсон тул програмууд хар хайрцаг байх шаардлагагүй болсон. Үгүй ээ, тэдгээр нь хяналтын системд процессын төлөв байдлын талаар үнэ цэнэтэй мэдээллийг асууж, цуглуулах боломжийг олгодог төгсгөлийн цэгүүдийг харуулах ёстой бөгөөд ингэснээр шаардлагатай бол тэр даруй хариу өгөх боломжтой болно. Үүнийг Ажиглалтын өндөр зарчмыг (HOP) дагадаг Гүйцэтгэлийн туршилтын дизайны загвар гэж нэрлэдэг.

Kubernetes нь анхдагч байдлаар 2 төрлийн эрүүл мэндийн үзлэгийг санал болгодог: readinessProbe болон livenessProbe. Хоёулаа ижил төрлийн шалгалтыг ашигладаг (HTTP GET хүсэлт, TCP холбоо болон тушаалын гүйцэтгэл). Тэд хонхорцог дахь асуудлын хариуд ямар шийдвэр гаргахдаа ялгаатай байдаг. livenessProbe нь алдаа дахин гарахгүй гэж найдаж савыг дахин эхлүүлж, readinessProbe нь асуудлын шалтгааныг арилгах хүртэл ирж буй урсгалаас pod-ыг тусгаарладаг.

Хэрэглээний зөв загвар нь шалгалтын хоёр төрлийг багтаасан байх ёстой бөгөөд ялангуяа онцгой тохиолдлын үед хангалттай мэдээлэл цуглуулсан байх ёстой. Энэ нь хяналтын системийг (Прометей) эрүүл мэндийн чухал хэмжүүрээр хангадаг шаардлагатай API төгсгөлийн цэгүүдийг харуулах ёстой.

Эх сурвалж: www.habr.com