ການປະຕິບັດທີ່ດີທີ່ສຸດສໍາລັບເຄື່ອງບັນຈຸ Kubernetes: ການກວດສຸຂະພາບ

TL; DR

• ເພື່ອບັນລຸການສັງເກດການສູງຂອງຕູ້ຄອນເທນເນີແລະ microservices, ບັນທຶກແລະການວັດແທກຕົ້ນຕໍແມ່ນບໍ່ພຽງພໍ.
• ສໍາລັບການຟື້ນຕົວໄວຂຶ້ນແລະຄວາມຢືດຢຸ່ນເພີ່ມຂຶ້ນ, ແອັບພລິເຄຊັນຄວນໃຊ້ຫຼັກການສັງເກດການສູງ (HOP).
• ໃນລະດັບຄໍາຮ້ອງສະຫມັກ, NOP ຮຽກຮ້ອງໃຫ້: ການຕັດໄມ້ທີ່ເຫມາະສົມ, ການຕິດຕາມຢ່າງໃກ້ຊິດ, ການກວດສອບສຸຂາພິບານ, ແລະການປະຕິບັດ / ການຕິດຕາມການປ່ຽນແປງ.
• ໃຊ້ການກວດສອບເປັນອົງປະກອບຂອງ NOR ກຽມຄວາມພ້ອມ и ການ​ສືບ​ສວນ​ການ​ດໍາ​ລົງ​ຊີ​ວິດ​ Kubernetes.

ແມ່ແບບກວດສຸຂະພາບແມ່ນຫຍັງ?

ໃນເວລາທີ່ການອອກແບບຄໍາຮ້ອງສະຫມັກທີ່ສໍາຄັນແລະສາມາດໃຊ້ໄດ້ສູງ, ມັນເປັນສິ່ງສໍາຄັນທີ່ຈະຄິດກ່ຽວກັບລັກສະນະດັ່ງກ່າວເປັນຄວາມທົນທານຕໍ່ຄວາມຜິດພາດ. ແອັບພລິເຄຊັ່ນຖືກພິຈາລະນາວ່າມີຄວາມຜິດຖ້າມັນຟື້ນຕົວໄວຈາກຄວາມລົ້ມເຫລວ. ແອັບພລິເຄຊັນຄລາວທົ່ວໄປໃຊ້ສະຖາປັດຕະຍະກໍາຈຸລະພາກ - ເຊິ່ງແຕ່ລະອົງປະກອບຖືກວາງໄວ້ໃນຖັງແຍກຕ່າງຫາກ. ແລະເພື່ອໃຫ້ແນ່ໃຈວ່າຄໍາຮ້ອງສະຫມັກໃນ k8s ແມ່ນມີຢູ່ສູງໃນເວລາທີ່ທ່ານອອກແບບກຸ່ມ, ທ່ານຈໍາເປັນຕ້ອງປະຕິບັດຕາມຮູບແບບທີ່ແນ່ນອນ. ໃນບັນດາພວກເຂົາແມ່ນແມ່ແບບກວດສຸຂະພາບ. ມັນກໍານົດວິທີການທີ່ແອັບພລິເຄຊັນສື່ສານກັບ k8s ວ່າມັນມີສຸຂະພາບດີ. ນີ້ແມ່ນບໍ່ພຽງແຕ່ຂໍ້ມູນກ່ຽວກັບວ່າຝັກກໍາລັງແລ່ນ, ແຕ່ຍັງກ່ຽວກັບວິທີການທີ່ມັນໄດ້ຮັບແລະຕອບສະຫນອງຕໍ່ການຮ້ອງຂໍ. ຍິ່ງ Kubernetes ຮູ້ກ່ຽວກັບສຸຂະພາບຂອງຝັກຫຼາຍເທົ່າໃດ, ການຕັດສິນໃຈທີ່ສະຫລາດກວ່າທີ່ມັນເຮັດກ່ຽວກັບເສັ້ນທາງການຈະລາຈອນແລະການດຸ່ນດ່ຽງການໂຫຼດ. ດັ່ງນັ້ນ, ຫຼັກການສັງເກດການສູງເຮັດໃຫ້ແອັບພລິເຄຊັນສາມາດຕອບສະຫນອງຄໍາຮ້ອງຂໍໄດ້ທັນເວລາ.

ຫຼັກການສັງເກດການສູງ (HOP)

ຫຼັກການຂອງການສັງເກດການສູງແມ່ນຫນຶ່ງໃນ ຫຼັກການໃນການອອກແບບຄໍາຮ້ອງສະຫມັກບັນຈຸ. ໃນສະຖາປັດຕະຍະກໍາ microservices, ການບໍລິການບໍ່ສົນໃຈວ່າຄໍາຮ້ອງຂໍຂອງພວກເຂົາຖືກດໍາເນີນການແນວໃດ (ແລະຖືກຕ້ອງ), ແຕ່ສິ່ງທີ່ສໍາຄັນແມ່ນພວກເຂົາໄດ້ຮັບການຕອບສະຫນອງຈາກການບໍລິການທີ່ໄດ້ຮັບ. ຕົວຢ່າງ, ເພື່ອກວດສອບຜູ້ໃຊ້, ກ່ອງບັນຈຸຫນຶ່ງສົ່ງຄໍາຮ້ອງຂໍ HTTP ໄປໃຫ້ອີກ, ຄາດວ່າຈະມີການຕອບສະຫນອງໃນຮູບແບບທີ່ແນ່ນອນ - ນັ້ນແມ່ນທັງຫມົດ. PythonJS ຍັງສາມາດປະມວນຜົນການຮ້ອງຂໍໄດ້, ແລະ Python Flask ສາມາດຕອບສະຫນອງ. ຕູ້ຄອນເທນເນີແມ່ນຄ້າຍຄືກ່ອງສີດໍາທີ່ມີເນື້ອຫາທີ່ເຊື່ອງໄວ້ຕໍ່ກັນແລະກັນ. ຢ່າງໃດກໍ່ຕາມ, ຫຼັກການ NOP ຮຽກຮ້ອງໃຫ້ແຕ່ລະບໍລິການເປີດເຜີຍຈຸດສິ້ນສຸດ API ຫຼາຍອັນທີ່ຊີ້ບອກວ່າມັນມີສຸຂະພາບດີ, ເຊັ່ນດຽວກັນກັບສະຖານະຄວາມພ້ອມແລະຄວາມທົນທານຂອງຄວາມຜິດພາດຂອງມັນ. Kubernetes ຮ້ອງຂໍຕົວຊີ້ວັດເຫຼົ່ານີ້ເພື່ອຄິດຜ່ານຂັ້ນຕອນຕໍ່ໄປສໍາລັບການກໍານົດເສັ້ນທາງແລະການດຸ່ນດ່ຽງການໂຫຼດ.

ແອັບພລິເຄຊັນຄລາວທີ່ອອກແບບມາໄດ້ດີບັນທຶກເຫດການຫຼັກຂອງມັນໂດຍໃຊ້ I/O streams ມາດຕະຖານ STDERR ແລະ STDOUT. ຕໍ່ໄປແມ່ນການບໍລິການຊ່ວຍ, ຕົວຢ່າງເຊັ່ນ filebeat, logstash ຫຼື fluentd, ການສົ່ງບັນທຶກໄປຍັງລະບົບການກວດສອບສູນກາງ (ຕົວຢ່າງ Prometheus) ແລະລະບົບການເກັບກໍາຂໍ້ມູນບັນທຶກ (ຊຸດຊອບແວ ELK). ແຜນວາດຂ້າງລຸ່ມນີ້ສະແດງໃຫ້ເຫັນວ່າແອັບພລິເຄຊັນຄລາວເຮັດວຽກແນວໃດຕາມແບບທົດສອບສຸຂະພາບ ແລະຫຼັກການສັງເກດການສູງ.

ວິທີການນໍາໃຊ້ຮູບແບບການກວດສຸຂະພາບໃນ Kubernetes?

ອອກຈາກກ່ອງ, k8s ຕິດຕາມສະຖານະຂອງຝັກໂດຍໃຊ້ຫນຶ່ງຂອງຕົວຄວບຄຸມ (ການ ນຳ ໃຊ້, ຊຸດຈຳລອງ, DaemonSets, StatefulSets ແລະອື່ນໆ, ແລະອື່ນໆ). ໂດຍໄດ້ຄົ້ນພົບວ່າຝັກໄດ້ລົ້ມລົງດ້ວຍເຫດຜົນບາງຢ່າງ, ຕົວຄວບຄຸມພະຍາຍາມເລີ່ມມັນໃໝ່ ຫຼືຍ້າຍມັນໄປໃສ່ໂນດອື່ນ. ຢ່າງໃດກໍຕາມ, ຝັກອາດຈະລາຍງານວ່າມັນຂຶ້ນແລະແລ່ນ, ແຕ່ຕົວມັນເອງບໍ່ໄດ້ເຮັດວຽກ. ໃຫ້ຕົວຢ່າງ: ຄໍາຮ້ອງສະຫມັກຂອງທ່ານໃຊ້ Apache ເປັນເຄື່ອງແມ່ຂ່າຍເວັບໄຊຕ໌, ທ່ານໄດ້ຕິດຕັ້ງອົງປະກອບຢູ່ໃນຫຼາຍໆຝັກຂອງກຸ່ມ. ເນື່ອງຈາກຫ້ອງສະຫມຸດໄດ້ຖືກຕັ້ງຄ່າບໍ່ຖືກຕ້ອງ, ທຸກໆຄໍາຮ້ອງຂໍຕໍ່ແອັບພລິເຄຊັນຕອບສະຫນອງດ້ວຍລະຫັດ 500 (ຄວາມຜິດພາດຂອງເຄື່ອງແມ່ຂ່າຍພາຍໃນ). ເມື່ອກວດສອບການຈັດສົ່ງ, ການກວດສອບສະຖານະຂອງຝັກໃຫ້ຜົນໄດ້ຮັບທີ່ປະສົບຜົນສໍາເລັດ, ແຕ່ລູກຄ້າຄິດແຕກຕ່າງກັນ. ພວກ​ເຮົາ​ຈະ​ອະ​ທິ​ບາຍ​ສະ​ຖາ​ນະ​ການ​ທີ່​ບໍ່​ຕ້ອງ​ການ​ນີ້​ດັ່ງ​ຕໍ່​ໄປ​ນີ້​:

ໃນຕົວຢ່າງຂອງພວກເຮົາ, k8s ເຮັດ ການກວດສອບການທໍາງານ. ໃນປະເພດຂອງການຢັ້ງຢືນນີ້, kubelet ຢ່າງຕໍ່ເນື່ອງກວດສອບສະຖານະຂອງຂະບວນການໃນບັນຈຸ. ເມື່ອລາວເຂົ້າໃຈວ່າຂະບວນການດັ່ງກ່າວໄດ້ຢຸດເຊົາ, ລາວຈະເລີ່ມມັນໃຫມ່. ຖ້າຂໍ້ຜິດພາດສາມາດແກ້ໄຂໄດ້ໂດຍການເປີດແອັບພລິເຄຊັນໃຫມ່, ແລະໂປລແກລມຖືກອອກແບບເພື່ອປິດຂໍ້ຜິດພາດໃດໆ, ຫຼັງຈາກນັ້ນການກວດສອບສຸຂະພາບຂອງຂະບວນການແມ່ນທັງຫມົດທີ່ທ່ານຕ້ອງການປະຕິບັດຕາມ NOP ແລະຮູບແບບການທົດສອບສຸຂະພາບ. ຄວາມສົງສານພຽງແຕ່ແມ່ນວ່າບໍ່ແມ່ນຄວາມຜິດພາດທັງຫມົດຖືກລົບລ້າງໂດຍການເລີ່ມຕົ້ນໃຫມ່. ໃນ​ກໍ​ລະ​ນີ​ນີ້, k8s ສະ​ເຫນີ 2 ວິ​ທີ​ທີ່​ເລິກ​ກວ່າ​ເພື່ອ​ກໍາ​ນົດ​ບັນ​ຫາ​ຂອງ​ຝັກ​: ການ​ສືບ​ສວນ​ການ​ດໍາ​ລົງ​ຊີ​ວິດ​ и ກຽມຄວາມພ້ອມ.

LivenessProbe

ໃນລະຫວ່າງ ການ​ສືບ​ສວນ​ການ​ດໍາ​ລົງ​ຊີ​ວິດ​ kubelet ປະຕິບັດການກວດສອບ 3 ປະເພດ: ບໍ່ພຽງແຕ່ກໍານົດວ່າ pod ກໍາລັງແລ່ນ, ແຕ່ຍັງວ່າມັນພ້ອມທີ່ຈະຮັບແລະຕອບສະຫນອງຢ່າງພຽງພໍຕໍ່ການຮ້ອງຂໍ:

• ຕັ້ງຄ່າການຮ້ອງຂໍ HTTP ກັບ pod ໄດ້. ການຕອບສະຫນອງຕ້ອງມີລະຫັດຕອບສະຫນອງ HTTP ໃນລະດັບຈາກ 200 ຫາ 399. ດັ່ງນັ້ນ, ລະຫັດ 5xx ແລະ 4xx ສັນຍານວ່າຝັກກໍາລັງມີບັນຫາ, ເຖິງແມ່ນວ່າຂະບວນການກໍາລັງດໍາເນີນການ.
• ເພື່ອທົດສອບ pods ກັບການບໍລິການທີ່ບໍ່ແມ່ນ HTTP (ຕົວຢ່າງ, ເຄື່ອງແມ່ຂ່າຍເມລ Postfix), ທ່ານຈໍາເປັນຕ້ອງສ້າງການເຊື່ອມຕໍ່ TCP.
• ປະຕິບັດຄໍາສັ່ງທີ່ຕົນເອງມັກສໍາລັບ pod (ພາຍໃນ). ການກວດສອບແມ່ນຖືວ່າປະສົບຜົນສໍາເລັດຖ້າລະຫັດສໍາເລັດຄໍາສັ່ງແມ່ນ 0.

ຕົວຢ່າງຂອງວິທີການເຮັດວຽກນີ້. ຄໍານິຍາມຂອງ pod ຕໍ່ໄປປະກອບດ້ວຍຄໍາຮ້ອງສະຫມັກ NodeJS ທີ່ຖິ້ມຄວາມຜິດພາດ 500 ໃນຄໍາຮ້ອງຂໍ HTTP. ເພື່ອໃຫ້ແນ່ໃຈວ່າ container ໄດ້ຖືກ restart ເມື່ອໄດ້ຮັບຂໍ້ຜິດພາດດັ່ງກ່າວ, ພວກເຮົາໃຊ້ຕົວກໍານົດການ 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 ຈະປິດເປີດກ່ອງບັນຈຸໃຫມ່ເທົ່ານັ້ນຖ້າມັນລົ້ມເຫລວ. ຖ້າການປິດເປີດໃຫມ່ບໍ່ໄດ້ແກ້ໄຂຂໍ້ຜິດພາດທີ່ປ້ອງກັນບໍ່ໃຫ້ກ່ອງບັນຈຸເຮັດວຽກ, kubelet ຈະບໍ່ສາມາດດໍາເນີນການແກ້ໄຂໄດ້.

ກຽມຄວາມພ້ອມ

readinessProbe ເຮັດວຽກຄ້າຍຄືກັນກັບ livenessProbes (ການຮ້ອງຂໍ GET, ການສື່ສານ TCP ແລະການປະຕິບັດຄໍາສັ່ງ), ຍົກເວັ້ນການດໍາເນີນການແກ້ໄຂບັນຫາ. ກ່ອງບັນຈຸທີ່ກວດພົບຄວາມລົ້ມເຫຼວແມ່ນບໍ່ໄດ້ເປີດຄືນໃໝ່, ແຕ່ຖືກແຍກອອກຈາກການຈະລາຈອນຂາເຂົ້າ. ຈິນຕະນາການວ່າຫນຶ່ງໃນບັນຈຸກໍາລັງປະຕິບັດການຄິດໄລ່ຫຼາຍຫຼືຢູ່ພາຍໃຕ້ການໂຫຼດຫນັກ, ເຮັດໃຫ້ເວລາຕອບສະຫນອງເພີ່ມຂຶ້ນ. ໃນ​ກໍ​ລະ​ນີ​ຂອງ livenessProbe​, ການ​ກວດ​ສອບ​ຄວາມ​ພ້ອມ​ຂອງ​ການ​ຕອບ​ສະ​ຫນອງ​ໄດ້​ຖືກ​ກະ​ຕຸ້ນ​ໃຫ້​ເກີດ (ຜ່ານ​ພາ​ລາ​ມິ​ເຕີ​ການ​ກວດ​ສອບ timeoutSeconds​)​, ຫຼັງ​ຈາກ​ນັ້ນ kubelet restart ຖັງ​. ເມື່ອເລີ່ມຕົ້ນ, ກ່ອງບັນຈຸເລີ່ມປະຕິບັດວຽກງານທີ່ໃຊ້ຊັບພະຍາກອນຫຼາຍ ແລະຖືກເປີດຄືນໃໝ່ອີກຄັ້ງ. ນີ້ສາມາດເປັນສິ່ງສໍາຄັນສໍາລັບຄໍາຮ້ອງສະຫມັກທີ່ຕ້ອງການຄວາມໄວຕອບສະຫນອງ. ຕົວຢ່າງ, ລົດໃນຂະນະທີ່ຢູ່ໃນຖະຫນົນກໍາລັງລໍຖ້າການຕອບສະຫນອງຈາກເຄື່ອງແມ່ຂ່າຍ, ການຕອບສະຫນອງແມ່ນຊັກຊ້າ - ແລະລົດໄດ້ຮັບອຸປະຕິເຫດ.

ໃຫ້ຂຽນຄໍານິຍາມ 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

ໃຫ້ລໍຖ້າສອງສາມວິນາທີແລະຫຼັງຈາກນັ້ນເບິ່ງວ່າຄວາມພ້ອມຂອງ Probe ເຮັດວຽກແນວໃດ:

kubectl describe pods nodedelayed

ໃນຕອນທ້າຍຂອງຜົນຜະລິດທ່ານສາມາດເບິ່ງວ່າບາງເຫດການແມ່ນຄ້າຍຄືກັນ ອັນນີ້.

ດັ່ງທີ່ເຈົ້າສາມາດເຫັນໄດ້, kubectl ບໍ່ໄດ້ປິດເປີດຝັກຄືນໃໝ່ເມື່ອເວລາກວດສອບເກີນ 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; DR
ກ່ອນທີ່ຈະມາເຖິງຂອງຄໍາຮ້ອງສະຫມັກຟັງ, ບັນທຶກເປັນວິທີການຕົ້ນຕໍໃນການຕິດຕາມແລະກວດເບິ່ງສຸຂະພາບຂອງແອັບພລິເຄຊັນ. ຢ່າງໃດກໍ່ຕາມ, ບໍ່ມີວິທີທີ່ຈະດໍາເນີນການແກ້ໄຂໃດໆ. ບັນທຶກຍັງເປັນປະໂຫຍດໃນມື້ນີ້; ພວກເຂົາຕ້ອງໄດ້ຮັບການລວບລວມແລະສົ່ງໄປຫາລະບົບການເກັບບັນທຶກສໍາລັບການວິເຄາະສະຖານະການສຸກເສີນແລະການຕັດສິນໃຈ. [ທັງຫມົດນີ້ສາມາດເຮັດໄດ້ໂດຍບໍ່ມີຄໍາຮ້ອງສະຫມັກຟັງໂດຍໃຊ້ monit, ສໍາລັບຕົວຢ່າງ, ແຕ່ກັບ k8s ມັນງ່າຍຂຶ້ນຫຼາຍ :) - ບັນທຶກຂອງບັນນາທິການ. ]

ໃນມື້ນີ້, ການແກ້ໄຂຕ້ອງເຮັດເກືອບໃນເວລາທີ່ແທ້ຈິງ, ດັ່ງນັ້ນຄໍາຮ້ອງສະຫມັກບໍ່ຈໍາເປັນຕ້ອງເປັນກ່ອງສີດໍາ. ບໍ່, ພວກເຂົາຄວນສະແດງຈຸດສິ້ນສຸດທີ່ອະນຸຍາດໃຫ້ລະບົບການຕິດຕາມສາມາດສອບຖາມແລະເກັບກໍາຂໍ້ມູນທີ່ມີຄຸນຄ່າກ່ຽວກັບສະຖານະຂອງຂະບວນການເພື່ອໃຫ້ພວກເຂົາສາມາດຕອບສະຫນອງທັນທີຖ້າຈໍາເປັນ. ອັນນີ້ເອີ້ນວ່າການອອກແບບການທົດສອບປະສິດທິພາບ, ເຊິ່ງປະຕິບັດຕາມຫຼັກການສັງເກດການສູງ (HOP).

Kubernetes ໃຫ້ 2 ປະເພດການກວດສຸຂະພາບຕາມຄ່າເລີ່ມຕົ້ນ: readinessProbe ແລະ livenessProbe. ທັງສອງໃຊ້ການກວດສອບປະເພດດຽວກັນ (ການຮ້ອງຂໍ HTTP GET, ການສື່ສານ TCP ແລະການປະຕິບັດຄໍາສັ່ງ). ພວກເຂົາແຕກຕ່າງກັນໃນການຕັດສິນໃຈທີ່ພວກເຂົາເຮັດໃນການຕອບສະຫນອງຕໍ່ບັນຫາໃນຝັກ. livenessProbe ຣີສະຕາດຕູ້ຄອນເທນເນີໂດຍຫວັງວ່າຄວາມຜິດພາດຈະບໍ່ເກີດຂຶ້ນອີກ, ແລະຄວາມພ້ອມ Probe ແຍກຝັກຈາກການຈະລາຈອນຂາເຂົ້າຈົນກ່ວາສາເຫດຂອງບັນຫາຈະຖືກແກ້ໄຂ.

ການອອກແບບຄໍາຮ້ອງສະຫມັກທີ່ເຫມາະສົມຄວນປະກອບມີທັງສອງປະເພດຂອງການກວດສອບແລະໃຫ້ແນ່ໃຈວ່າພວກເຂົາເກັບກໍາຂໍ້ມູນພຽງພໍ, ໂດຍສະເພາະໃນເວລາທີ່ການຍົກເວັ້ນຖືກຖິ້ມ. ມັນຍັງຄວນສະແດງໃຫ້ເຫັນຈຸດສິ້ນສຸດ API ທີ່ຈໍາເປັນທີ່ສະຫນອງລະບົບການຕິດຕາມ (Prometheus) ທີ່ມີຕົວຊີ້ວັດສຸຂະພາບທີ່ສໍາຄັນ.

ແຫຼ່ງຂໍ້ມູນ: www.habr.com