საუკეთესო პრაქტიკა Kubernetes კონტეინერებისთვის: ჯანმრთელობის შემოწმებები

TL; DR

• კონტეინერებისა და მიკროსერვისების მაღალი დაკვირვებადობის მისაღწევად, მორები და პირველადი მეტრიკა საკმარისი არ არის.
• უფრო სწრაფი აღდგენისა და გაზრდილი გამძლეობისთვის, აპლიკაციებმა უნდა გამოიყენონ მაღალი დაკვირვებადობის პრინციპი (HOP).
• განაცხადის დონეზე, NOP მოითხოვს: სათანადო ხე-ტყის აღრიცხვას, მჭიდრო მონიტორინგს, საღი აზროვნების შემოწმებას და შესრულების/ტრანზიციის მიკვლევას.
• გამოიყენეთ ჩეკები NOR-ის ელემენტად მზადყოფნის ზონდი и livenessProbe კუბერნეტები.

რა არის ჯანმრთელობის შემოწმების შაბლონი?

მისიისთვის კრიტიკული და ძალიან ხელმისაწვდომი აპლიკაციის შემუშავებისას, ძალიან მნიშვნელოვანია ვიფიქროთ ისეთ ასპექტზე, როგორიცაა შეცდომის ტოლერანტობა. განაცხადი ითვლება შეცდომის ტოლერანტად, თუ ის სწრაფად აღდგება მარცხისგან. ტიპიური ღრუბლოვანი აპლიკაცია იყენებს მიკროსერვისების არქიტექტურას - სადაც თითოეული კომპონენტი მოთავსებულია ცალკე კონტეინერში. და იმისათვის, რომ დარწმუნდეთ, რომ k8s-ზე აპლიკაცია ძალიან ხელმისაწვდომია კლასტერის დიზაინის დროს, თქვენ უნდა დაიცვას გარკვეული შაბლონები. მათ შორის არის ჯანმრთელობის შემოწმების შაბლონი. ის განსაზღვრავს, თუ როგორ აცნობებს აპლიკაცია k8-ს, რომ ის ჯანმრთელია. ეს არის არა მხოლოდ ინფორმაცია იმის შესახებ, მუშაობს თუ არა პოდი, არამედ იმაზე, თუ როგორ იღებს და პასუხობს თხოვნებს. რაც უფრო მეტი იცის Kubernetes-მა პოდის ჯანმრთელობის შესახებ, მით უფრო ჭკვიანურ გადაწყვეტილებებს იღებს ის ტრაფიკის მარშრუტიზაციისა და დატვირთვის დაბალანსების შესახებ. ამრიგად, მაღალი დაკვირვებადობის პრინციპი საშუალებას აძლევს აპლიკაციას დროულად უპასუხოს მოთხოვნებს.

მაღალი დაკვირვებადობის პრინციპი (HOP)

მაღალი დაკვირვებადობის პრინციპი ერთ-ერთია კონტეინერირებული აპლიკაციების დიზაინის პრინციპები. მიკროსერვისების არქიტექტურაში, სერვისებს არ აინტერესებთ როგორ განიხილება მათი მოთხოვნა (და მართებულადაც ასეა), მაგრამ მთავარია, როგორ იღებენ პასუხებს მიმღები სერვისებისგან. მაგალითად, მომხმარებლის ავთენტიფიკაციისთვის, ერთი კონტეინერი უგზავნის HTTP მოთხოვნას მეორეს და ელოდება პასუხს გარკვეულ ფორმატში - ეს ყველაფერია. PythonJS-ს ასევე შეუძლია მოთხოვნის დამუშავება და Python Flask-ს შეუძლია უპასუხოს. კონტეინერები შავ ყუთებს ჰგავს, ერთმანეთის ფარული შიგთავსით. თუმცა, NOP პრინციპი მოითხოვს თითოეულ სერვისს გამოავლინოს მრავალი API საბოლოო წერტილი, რომელიც მიუთითებს იმაზე, თუ რამდენად ჯანსაღია ის, ასევე მზადყოფნა და შეცდომების ტოლერანტობის სტატუსი. Kubernetes ითხოვს ამ ინდიკატორებს, რათა იფიქროს მარშრუტიზაციისა და დატვირთვის დაბალანსების შემდგომ ნაბიჯებზე.

კარგად შემუშავებული ღრუბლოვანი აპლიკაცია აღრიცხავს თავის ძირითად მოვლენებს სტანდარტული I/O ნაკადების STDERR და STDOUT გამოყენებით. შემდეგ მოდის დამხმარე სერვისი, მაგალითად filebeat, logstash ან fluentd, რომელიც აწვდის ჟურნალებს ცენტრალიზებულ მონიტორინგის სისტემას (მაგალითად, პრომეთე) და ჟურნალების შეგროვების სისტემას (ELK პროგრამული კომპლექტი). ქვემოთ მოცემული დიაგრამა გვიჩვენებს, თუ როგორ მუშაობს ღრუბლოვანი აპლიკაცია ჯანმრთელობის ტესტის ნიმუშისა და მაღალი დაკვირვებადობის პრინციპის მიხედვით.

როგორ გამოვიყენოთ ჯანმრთელობის შემოწმების ნიმუში Kubernetes-ში?

ყუთიდან, k8s აკონტროლებს პოდების სტატუსს ერთ-ერთი კონტროლერის გამოყენებით (განლაგება, ReplicaSets, DaemonSets, StatefulSets და ა.შ.). როდესაც აღმოაჩინა, რომ პოდი რაღაც მიზეზით დაეცა, კონტროლერი ცდილობს მის გადატვირთვას ან სხვა კვანძში გადატანას. თუმცა, pod შეიძლება აცნობოს, რომ ის მუშაობს და მუშაობს, მაგრამ ის თავად არ ფუნქციონირებს. მოვიყვანოთ მაგალითი: თქვენი აპლიკაცია იყენებს Apache-ს, როგორც ვებ სერვერს, თქვენ დააინსტალირეთ კომპონენტი კლასტერის რამდენიმე პოდზე. ვინაიდან ბიბლიოთეკა არასწორად იყო კონფიგურირებული, აპლიკაციის ყველა მოთხოვნა პასუხობს კოდით 500 (შიდა სერვერის შეცდომა). მიწოდების შემოწმებისას, პოდნების სტატუსის შემოწმება წარმატებულ შედეგს იძლევა, მაგრამ მომხმარებლები სხვაგვარად ფიქრობენ. ჩვენ აღვწერთ ამ არასასურველ მდგომარეობას შემდეგნაირად:

ჩვენს მაგალითში, k8s აკეთებს ფუნქციონირების შემოწმება. ამ ტიპის გადამოწმებისას, კუბელეტი მუდმივად ამოწმებს პროცესის მდგომარეობას კონტეინერში. როგორც კი გაიგებს, რომ პროცესი შეჩერებულია, განაახლებს მას. თუ შეცდომის მოგვარება შესაძლებელია აპლიკაციის უბრალოდ გადატვირთვით, და პროგრამა შექმნილია ნებისმიერი შეცდომის გამორთვისთვის, მაშინ პროცესის ჯანმრთელობის შემოწმება არის ყველაფერი, რაც გჭირდებათ NOP-ის და ჯანმრთელობის ტესტის ნიმუშის შესაბამისად. ერთადერთი სამწუხაროა, რომ ყველა შეცდომა არ აღმოიფხვრება გადატვირთვით. ამ შემთხვევაში, k8s გთავაზობთ 2 უფრო ღრმა გზას პოდთან დაკავშირებული პრობლემების დასადგენად: livenessProbe и მზადყოფნის ზონდი.

LivenessProbe

დროს livenessProbe kubelet ახორციელებს 3 ტიპის შემოწმებას: არა მხოლოდ განსაზღვრავს, მუშაობს თუ არა პოდი, არამედ არის თუ არა ის მზად, მიიღოს და ადეკვატურად უპასუხოს მოთხოვნებს:

• დააყენეთ HTTP მოთხოვნა პოდზე. პასუხი უნდა შეიცავდეს HTTP საპასუხო კოდს 200-დან 399-მდე დიაპაზონში. ამრიგად, კოდები 5xx და 4xx მიუთითებენ, რომ პოდს აქვს პრობლემები, მიუხედავად იმისა, რომ პროცესი მიმდინარეობს.
• პოდების შესამოწმებლად არასამთავრობო HTTP სერვისებით (მაგალითად, Postfix ფოსტის სერვერი), თქვენ უნდა დაამყაროთ TCP კავშირი.
• შეასრულეთ თვითნებური ბრძანება პოდისთვის (შინაგანად). შემოწმება წარმატებულად ითვლება, თუ ბრძანების დასრულების კოდი არის 0.

მაგალითი იმისა, თუ როგორ მუშაობს ეს. შემდეგი pod განმარტება შეიცავს NodeJS აპლიკაციას, რომელიც უშვებს 500 შეცდომას HTTP მოთხოვნებზე. იმისათვის, რომ დავრწმუნდეთ, რომ კონტეინერი გადატვირთულია ასეთი შეცდომის მიღებისას, ვიყენებთ 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')
})

dockerfile

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

მნიშვნელოვანია აღინიშნოს ეს: livenessProbe გადატვირთავს კონტეინერს მხოლოდ იმ შემთხვევაში, თუ ის ვერ მოხერხდება. თუ გადატვირთვა არ გამოასწორებს შეცდომას, რომელიც ხელს უშლის კონტეინერის გაშვებას, კუბელეტი ვერ შეძლებს პრობლემის გამოსასწორებლად მოქმედებას.

მზადყოფნის ზონდი

ReadinessProbe მუშაობს ისევე, როგორც livenessProbes (GET მოთხოვნები, TCP კომუნიკაციები და ბრძანებების შესრულება), გარდა პრობლემების აღმოფხვრის მოქმედებებისა. კონტეინერი, რომელშიც აღმოჩენილია უკმარისობა, არ განახლდება, მაგრამ იზოლირებულია შემომავალი ტრაფიკისგან. წარმოიდგინეთ, რომ ერთ-ერთი კონტეინერი ახორციელებს ბევრ გამოთვლას ან მძიმე დატვირთვის ქვეშ იმყოფება, რაც იწვევს რეაგირების დროის ზრდას. livenessProbe-ის შემთხვევაში, პასუხის ხელმისაწვდომობის შემოწმება ამოქმედდება (timeoutSeconds შემოწმების პარამეტრის მეშვეობით), რის შემდეგაც kubelet გადატვირთავს კონტეინერს. როდესაც დაიწყება, კონტეინერი იწყებს რესურსზე ინტენსიური ამოცანების შესრულებას და ხელახლა იტვირთება. ეს შეიძლება იყოს კრიტიკული იმ აპლიკაციებისთვის, რომლებსაც რეაგირების სიჩქარე სჭირდებათ. მაგალითად, მანქანა გზაზე ელოდება სერვერის პასუხს, პასუხი იგვიანებს - და მანქანა ავარიაში მოყვება.

მოდით დავწეროთ redinessProbe განმარტება, რომელიც დააყენებს GET მოთხოვნის პასუხის დროს არაუმეტეს ორი წამისა, ხოლო აპლიკაცია უპასუხებს 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

მოდით განვათავსოთ pod kubectl-ით:

kubectl apply -f pod.yaml

მოდით დაველოდოთ რამდენიმე წამს და შემდეგ ვნახოთ, როგორ მუშაობდა ReadinessProbe:

kubectl describe pods nodedelayed

გამოსვლის ბოლოს ხედავთ, რომ ზოგიერთი მოვლენა მსგავსია ეს ერთი.

როგორც ხედავთ, kubectl-მა არ გადატვირთა პოდი, როდესაც შემოწმების დრო 2 წამს გადააჭარბა. ამის ნაცვლად, მან გააუქმა მოთხოვნა. შემომავალი კომუნიკაციები გადამისამართებულია სხვა, სამუშაო პოდებზე.

გაითვალისწინეთ, რომ ახლა, როდესაც pod ჩამოტვირთულია, 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
ღრუბლოვანი აპლიკაციების გამოჩენამდე ჟურნალები იყო აპლიკაციის ჯანმრთელობის მონიტორინგისა და შემოწმების ძირითადი საშუალება. თუმცა, არ არსებობდა რაიმე მაკორექტირებელი მოქმედების გატარების საშუალება. ჟურნალები დღესაც გამოსადეგია; ისინი უნდა შეგროვდეს და გაიგზავნოს ჟურნალების შეგროვების სისტემაში საგანგებო სიტუაციების გასაანალიზებლად და გადაწყვეტილების მისაღებად. [ეს ყველაფერი შეიძლება გაკეთდეს ღრუბლოვანი აპლიკაციების გარეშე, მაგალითად, მონიტის გამოყენებით, მაგრამ k8-ით ეს ბევრად უფრო ადვილი გახდა :) - რედაქტორის შენიშვნა. ]

დღეს შესწორებები თითქმის რეალურ დროში უნდა განხორციელდეს, ამიტომ აპლიკაციები აღარ უნდა იყოს შავი ყუთები. არა, მათ უნდა აჩვენონ საბოლოო წერტილები, რომლებიც საშუალებას აძლევს მონიტორინგის სისტემებს მოითხოვონ და შეაგროვონ ღირებული მონაცემები პროცესების მდგომარეობის შესახებ, რათა საჭიროების შემთხვევაში მყისიერად უპასუხონ. ამას ეწოდება შესრულების ტესტის დიზაინის ნიმუში, რომელიც მიჰყვება მაღალი დაკვირვებადობის პრინციპს (HOP).

Kubernetes სტანდარტულად გთავაზობთ ჯანმრთელობის შემოწმების 2 ტიპს: ReadinessProbe და livenessProbe. ორივე იყენებს იგივე ტიპის შემოწმებებს (HTTP GET მოთხოვნები, TCP კომუნიკაციები და ბრძანებების შესრულება). ისინი განსხვავდებიან იმით, თუ რა გადაწყვეტილებებს იღებენ ღრძილების პრობლემების საპასუხოდ. livenessProbe გადატვირთავს კონტეინერს იმ იმედით, რომ შეცდომა აღარ განმეორდება და ReadinessProbe იზოლირებს პოდს შემომავალი ტრაფიკისგან, სანამ პრობლემის მიზეზი არ მოგვარდება.

განაცხადის სწორი დიზაინი უნდა მოიცავდეს ორივე ტიპის შემოწმებას და უზრუნველყოს, რომ ისინი აგროვებენ საკმარის მონაცემებს, განსაკუთრებით მაშინ, როდესაც ხდება გამონაკლისი. მან ასევე უნდა აჩვენოს აუცილებელი API საბოლოო წერტილები, რომლებიც უზრუნველყოფენ მონიტორინგის სისტემას (პრომეთე) ჯანმრთელობის მნიშვნელოვანი მეტრიკებით.

წყარო: www.habr.com