ការអនុវត្តល្អបំផុតសម្រាប់កុងតឺន័រ Kubernetes៖ ការពិនិត្យសុខភាព

TL; កុង

• ដើម្បីសម្រេចបាននូវការអង្កេតខ្ពស់នៃកុងតឺន័រ និងសេវាកម្មមីក្រូ កំណត់ហេតុ និងម៉ែត្របឋមគឺមិនគ្រប់គ្រាន់ទេ។
• សម្រាប់ការងើបឡើងវិញលឿនជាងមុន និងបង្កើនភាពធន់ កម្មវិធីគួរតែអនុវត្តគោលការណ៍សង្កេតខ្ពស់ (HOP)។
• នៅកម្រិតកម្មវិធី NOP ទាមទារ៖ ការកត់ត្រាត្រឹមត្រូវ ការត្រួតពិនិត្យយ៉ាងជិតស្និទ្ធ ការត្រួតពិនិត្យអនាម័យ និងការតាមដានដំណើរការ/ការផ្លាស់ប្តូរ។
• ប្រើមូលប្បទានប័ត្រជាធាតុនៃ NOR ការត្រៀមខ្លួន и ការស៊ើបអង្កេតការរស់នៅ Kubernetes ។

តើគំរូពិនិត្យសុខភាពគឺជាអ្វី?

នៅពេលរចនាកម្មវិធីបេសកកម្មដែលមានសារៈសំខាន់ និងអាចប្រើបានខ្ពស់ វាពិតជាមានសារៈសំខាន់ណាស់ក្នុងការគិតអំពីទិដ្ឋភាពដូចជាការអត់ឱនចំពោះកំហុស។ កម្មវិធី​មួយ​ត្រូវ​បាន​ចាត់​ទុក​ថា​មាន​កំហុស​ដែល​អត់​ឱន​ប្រសិន​បើ​វា​ងើប​ឡើង​វិញ​យ៉ាង​ឆាប់​រហ័ស​ពី​ការ​បរាជ័យ។ កម្មវិធីពពកធម្មតាប្រើស្ថាបត្យកម្មមីក្រូសេវាកម្ម - ដែលសមាសធាតុនីមួយៗត្រូវបានដាក់ក្នុងធុងដាច់ដោយឡែកមួយ។ ហើយដើម្បីធ្វើឱ្យប្រាកដថាកម្មវិធីនៅលើ k8s អាចប្រើបានខ្ពស់នៅពេលអ្នករចនាចង្កោម អ្នកត្រូវធ្វើតាមគំរូជាក់លាក់។ ក្នុងចំនោមពួកគេមានគំរូពិនិត្យសុខភាព។ វាកំណត់ពីរបៀបដែលកម្មវិធីទាក់ទងទៅ k8s ថាវាមានសុខភាពល្អ។ នេះមិនត្រឹមតែជាព័ត៌មានអំពីថាតើផតកំពុងដំណើរការទេ ប៉ុន្តែក៏អំពីរបៀបដែលវាទទួល និងឆ្លើយតបទៅនឹងសំណើផងដែរ។ កាលណា Kubernetes ដឹងអំពីសុខភាពរបស់ pod កាន់តែច្រើន ការសម្រេចចិត្តកាន់តែឆ្លាតវៃដែលវាធ្វើអំពីការកំណត់ផ្លូវចរាចរណ៍ និងតុល្យភាពផ្ទុក។ ដូច្នេះ គោលការណ៍សង្កេតខ្ពស់ អនុញ្ញាតឱ្យកម្មវិធីឆ្លើយតបទៅនឹងសំណើក្នុងលក្ខណៈទាន់ពេលវេលា។

គោលការណ៍សង្កេតខ្ពស់ (HOP)

គោលការណ៍នៃការសង្កេតខ្ពស់គឺជាផ្នែកមួយនៃ គោលការណ៍សម្រាប់ការរចនាកម្មវិធីកុងតឺន័រ. នៅក្នុងស្ថាបត្យកម្ម microservices សេវាកម្មមិនខ្វល់ពីរបៀបដែលសំណើរបស់ពួកគេត្រូវបានដំណើរការ (ហើយត្រឹមត្រូវដូច្នេះ) ប៉ុន្តែអ្វីដែលសំខាន់គឺរបៀបដែលពួកគេទទួលបានការឆ្លើយតបពីសេវាកម្មទទួល។ ឧទាហរណ៍ ដើម្បីផ្ទៀងផ្ទាត់អ្នកប្រើប្រាស់ កុងតឺន័រមួយផ្ញើសំណើ HTTP ទៅមួយទៀត ដោយរំពឹងថានឹងមានការឆ្លើយតបក្នុងទម្រង់ជាក់លាក់មួយ - នោះហើយជាទាំងអស់។ PythonJS ក៏អាចដំណើរការសំណើបានដែរ ហើយ Python Flask អាចឆ្លើយតបបាន។ កុងតឺន័រគឺដូចជាប្រអប់ខ្មៅដែលមានមាតិកាលាក់គ្នាទៅវិញទៅមក ទោះជាយ៉ាងណាក៏ដោយ គោលការណ៍ NOP តម្រូវឱ្យសេវាកម្មនីមួយៗបង្ហាញចំណុចបញ្ចប់ API ជាច្រើនដែលបង្ហាញពីរបៀបដែលវាមានសុខភាពល្អ ក៏ដូចជាការត្រៀមខ្លួន និងស្ថានភាពនៃការអត់ឱនកំហុសរបស់វា។ Kubernetes ស្នើសុំសូចនាករទាំងនេះ ដើម្បីគិតដល់ជំហានបន្ទាប់សម្រាប់ការកំណត់ផ្លូវ និងការផ្ទុកតុល្យភាព។

កម្មវិធីពពកដែលបានរចនាយ៉ាងល្អកត់ត្រាព្រឹត្តិការណ៍សំខាន់ៗរបស់វាដោយប្រើស្ទ្រីម I/O ស្តង់ដារ STDERR និង STDOUT ។ បន្ទាប់មកមានសេវាកម្មជំនួយ ឧទាហរណ៍ filebeat, logstash ឬ fluentd បញ្ជូនកំណត់ហេតុទៅប្រព័ន្ធត្រួតពិនិត្យកណ្តាល (ឧទាហរណ៍ Prometheus) និងប្រព័ន្ធប្រមូលកំណត់ហេតុ (ឈុតកម្មវិធី ELK)។ ដ្យាក្រាមខាងក្រោមបង្ហាញពីរបៀបដែលកម្មវិធីពពកដំណើរការដោយយោងតាមគំរូតេស្តសុខភាព និងគោលការណ៍សង្កេតខ្ពស់។

តើធ្វើដូចម្តេចដើម្បីអនុវត្តគំរូពិនិត្យសុខភាពនៅក្នុង Kubernetes?

ចេញពីប្រអប់ k8s ត្រួតពិនិត្យស្ថានភាពរបស់ pods ដោយប្រើឧបករណ៍បញ្ជាមួយ (ការដាក់ពង្រាយ។, ឈុតចម្លង, DaemonSets, សំណុំរដ្ឋ ជាដើម) ។ ដោយបានរកឃើញថាផតបានធ្លាក់ចុះដោយសារហេតុផលមួយចំនួន ឧបករណ៍បញ្ជាព្យាយាមចាប់ផ្តើមវាឡើងវិញ ឬផ្លាស់ទីវាទៅថ្នាំងផ្សេងទៀត។ ទោះយ៉ាងណាក៏ដោយ ផតអាចរាយការណ៍ថាវាដំណើរការហើយ ប៉ុន្តែវាមិនដំណើរការទេ។ សូមផ្តល់ឧទាហរណ៍មួយ៖ កម្មវិធីរបស់អ្នកប្រើ Apache ជា web server អ្នកបានដំឡើងសមាសភាគនៅលើ cluster pods ជាច្រើន។ ដោយសារបណ្ណាល័យត្រូវបានកំណត់រចនាសម្ព័ន្ធមិនត្រឹមត្រូវ សំណើទាំងអស់ចំពោះកម្មវិធីឆ្លើយតបជាមួយលេខកូដ 500 (កំហុសម៉ាស៊ីនមេខាងក្នុង)។ នៅពេលពិនិត្យការដឹកជញ្ជូន ការពិនិត្យមើលស្ថានភាពរបស់ផតផត ផ្តល់លទ្ធផលជោគជ័យ ប៉ុន្តែអតិថិជនគិតខុសគ្នា។ យើងនឹងរៀបរាប់ពីស្ថានភាពដែលមិនចង់បាននេះដូចខាងក្រោម៖

ក្នុងឧទាហរណ៍របស់យើង k8s ធ្វើ ពិនិត្យមុខងារ. នៅក្នុងប្រភេទនៃការផ្ទៀងផ្ទាត់នេះ kubelet បន្តត្រួតពិនិត្យស្ថានភាពនៃដំណើរការនៅក្នុងកុងតឺន័រ។ នៅពេលដែលគាត់យល់ថាដំណើរការបានឈប់ គាត់នឹងចាប់ផ្តើមវាឡើងវិញ។ ប្រសិនបើកំហុសអាចត្រូវបានដោះស្រាយដោយគ្រាន់តែចាប់ផ្តើមកម្មវិធីឡើងវិញ ហើយកម្មវិធីត្រូវបានរចនាឡើងដើម្បីបិទកំហុសណាមួយនោះ ការត្រួតពិនិត្យសុខភាពដំណើរការគឺជាអ្វីដែលអ្នកត្រូវការដើម្បីអនុវត្តតាម NOP និងគំរូតេស្តសុខភាព។ ការអាណិតតែមួយគត់គឺថាមិនមែនកំហុសទាំងអស់ត្រូវបានលុបចោលដោយការចាប់ផ្ដើមឡើងវិញទេ។ ក្នុងករណីនេះ k8s ផ្តល់នូវវិធីកាន់តែស៊ីជម្រៅចំនួន 2 ដើម្បីកំណត់បញ្ហាជាមួយផតៈ ការស៊ើបអង្កេតការរស់នៅ и ការត្រៀមខ្លួន.

LivenessProbe

ក្នុងអំឡុងពេលនេះ ការស៊ើបអង្កេតការរស់នៅ kubelet អនុវត្តការត្រួតពិនិត្យ 3 ប្រភេទ៖ មិនត្រឹមតែកំណត់ថាតើផតកំពុងដំណើរការទេ ប៉ុន្តែថែមទាំងថាតើវារួចរាល់ក្នុងការទទួល និងឆ្លើយតបគ្រប់គ្រាន់ចំពោះសំណើដែរឬទេ៖

• រៀបចំសំណើ HTTP ទៅកាន់ផត។ ការឆ្លើយតបត្រូវតែមានលេខកូដឆ្លើយតប HTTP ក្នុងចន្លោះពី 200 ដល់ 399។ ដូច្នេះ លេខកូដ 5xx និង 4xx បង្ហាញថាផតកំពុងមានបញ្ហា ទោះបីជាដំណើរការកំពុងដំណើរការក៏ដោយ។
• ដើម្បីសាកល្បងផតផតជាមួយនឹងសេវាកម្មមិនមែន HTTP (ឧទាហរណ៍ ម៉ាស៊ីនមេ Postfix mail) អ្នកត្រូវបង្កើតការតភ្ជាប់ TCP ។
• ប្រតិបត្តិពាក្យបញ្ជាតាមអំពើចិត្តសម្រាប់ផត (ខាងក្នុង)។ ការត្រួតពិនិត្យត្រូវបានចាត់ទុកថាជោគជ័យប្រសិនបើលេខកូដបំពេញពាក្យបញ្ជាគឺ 0 ។

ឧទាហរណ៍នៃរបៀបដែលវាដំណើរការ។ និយមន័យផតបន្ទាប់មានកម្មវិធី 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) ការរស់នៅមួយផ្សេងទៀតProbe ទទួលយកប៉ារ៉ាម៉ែត្រ 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 នឹងចាប់ផ្តើមកុងតឺន័រឡើងវិញតែប៉ុណ្ណោះប្រសិនបើវាបរាជ័យ។ ប្រសិនបើការចាប់ផ្តើមឡើងវិញមិនកែកំហុសដែលរារាំងកុងតឺន័រមិនឱ្យដំណើរការនោះ kubelet នឹងមិនអាចចាត់វិធានការដើម្បីកែបញ្ហាបានទេ។

ការត្រៀមខ្លួន

readinessProbe ធ្វើការស្រដៀងគ្នាទៅនឹង livenessProbes (GET requests, TCP communications and command execution) លើកលែងតែសម្រាប់សកម្មភាពដោះស្រាយបញ្ហា។ កុងតឺន័រដែលបរាជ័យត្រូវបានរកឃើញមិនត្រូវបានចាប់ផ្តើមឡើងវិញទេ ប៉ុន្តែត្រូវបានដាច់ឆ្ងាយពីចរាចរណ៍ចូល។ ស្រមៃថាធុងមួយក្នុងចំណោមកុងតឺន័រកំពុងដំណើរការការគណនាច្រើនឬស្ថិតនៅក្រោមបន្ទុកធ្ងន់ដែលបណ្តាលឱ្យពេលវេលាឆ្លើយតបកើនឡើង។ ក្នុងករណី 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

តោះ​រង់ចាំ​ពីរ​បី​វិនាទី​សិន​ចាំ​មើល​ថា​តើ​ការ​ត្រៀម​ខ្លួន​បាន​ដំណើរការ​យ៉ាង​ណា៖

kubectl describe pods nodedelayed

នៅចុងបញ្ចប់នៃលទ្ធផលអ្នកអាចមើលឃើញថាព្រឹត្តិការណ៍មួយចំនួនគឺស្រដៀងគ្នា មួយ​នេះ.

ដូចដែលអ្នកអាចឃើញ kubectl មិនបានចាប់ផ្ដើម pod ឡើងវិញទេ នៅពេលដែលម៉ោងពិនិត្យលើសពី 2 វិនាទី។ ផ្ទុយ​ទៅ​វិញ គាត់​បាន​លុប​ចោល​សំណើ​នេះ។ ការទំនាក់ទំនងចូលត្រូវបានបញ្ជូនបន្តទៅកាន់ផតផតដែលធ្វើការផ្សេងទៀត។

ចំណាំថាឥឡូវនេះ ផតត្រូវបានបិទ ផ្លូវ 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; កុង
មុនពេលការមកដល់នៃកម្មវិធីពពក កំណត់ហេតុគឺជាមធ្យោបាយចម្បងក្នុងការត្រួតពិនិត្យ និងត្រួតពិនិត្យសុខភាពកម្មវិធី។ ទោះ​យ៉ាង​ណា​ក៏​គ្មាន​មធ្យោបាយ​ដើម្បី​ចាត់​វិធានការ​កែ​តម្រូវ​អ្វី​ដែរ។ កំណត់ហេតុនៅតែមានប្រយោជន៍នាពេលបច្ចុប្បន្ននេះ ពួកគេត្រូវប្រមូល និងផ្ញើទៅកាន់ប្រព័ន្ធប្រមូលកំណត់ហេតុសម្រាប់ការវិភាគស្ថានភាពអាសន្ន និងធ្វើការសម្រេចចិត្ត។ [ទាំងអស់នេះអាចធ្វើបានដោយគ្មានកម្មវិធី cloud ដោយប្រើ monit ជាឧទាហរណ៍ ប៉ុន្តែជាមួយ k8s វាកាន់តែងាយស្រួល :) - កំណត់ចំណាំរបស់អ្នកកែសម្រួល។ ]

សព្វ​ថ្ងៃ​នេះ ការ​កែ​តម្រូវ​ត្រូវ​ធ្វើ​ឡើង​ស្ទើរ​តែ​ក្នុង​ពេល​វេលា​ពិត​ប្រាកដ ដូច្នេះ​កម្មវិធី​លែង​ត្រូវ​តែ​ជា​ប្រអប់​ខ្មៅ​ទៀត​ហើយ។ ទេ ពួកគេគួរតែបង្ហាញចំណុចបញ្ចប់ដែលអនុញ្ញាតឱ្យប្រព័ន្ធត្រួតពិនិត្យសួរ និងប្រមូលទិន្នន័យដ៏មានតម្លៃអំពីស្ថានភាពនៃដំណើរការ ដូច្នេះពួកគេអាចឆ្លើយតបភ្លាមៗប្រសិនបើចាំបាច់។ នេះត្រូវបានគេហៅថា គំរូការរចនាសាកល្បងការអនុវត្ត ដែលអនុវត្តតាមគោលការណ៍សង្កេតខ្ពស់ (HOP)។

Kubernetes ផ្តល់ការពិនិត្យសុខភាព 2 ប្រភេទតាមលំនាំដើម៖ readinessProbe និង livenessProbe។ ទាំងពីរប្រើប្រភេទនៃការត្រួតពិនិត្យដូចគ្នា (សំណើ HTTP GET, ការទំនាក់ទំនង TCP និងការប្រតិបត្តិពាក្យបញ្ជា) ។ ពួកគេមានភាពខុសប្លែកគ្នានៅក្នុងការសម្រេចចិត្តដែលពួកគេធ្វើក្នុងការឆ្លើយតបទៅនឹងបញ្ហានៅក្នុងផត។ livenessProbe ចាប់ផ្តើមកុងតឺន័រឡើងវិញដោយសង្ឃឹមថាកំហុសនឹងមិនកើតឡើងម្តងទៀត ហើយការត្រៀមខ្លួន Probe ញែក pod ពីចរាចរចូលរហូតដល់មូលហេតុនៃបញ្ហាត្រូវបានដោះស្រាយ។

ការរចនាកម្មវិធីត្រឹមត្រូវគួរតែរួមបញ្ចូលទាំងប្រភេទនៃការត្រួតពិនិត្យ និងធានាថាពួកគេប្រមូលទិន្នន័យបានគ្រប់គ្រាន់ ជាពិសេសនៅពេលដែលករណីលើកលែងមួយត្រូវបានបោះចោល។ វាក៏គួរបង្ហាញចំណុចបញ្ចប់ API ចាំបាច់ដែលផ្តល់ប្រព័ន្ធត្រួតពិនិត្យ (Prometheus) ជាមួយនឹងរង្វាស់សុខភាពសំខាន់ៗ។

ប្រភព: www.habr.com