10 ຄວາມຜິດພາດທົ່ວໄປໃນເວລາທີ່ໃຊ້ Kubernetes

ຫມາຍ​ເຫດ​. ແປ.: ຜູ້ຂຽນຂອງບົດຄວາມນີ້ແມ່ນວິສະວະກອນຈາກບໍລິສັດພາສາເຊັກໂກຂະຫນາດນ້ອຍ, pipetail. ພວກເຂົາເຈົ້າສາມາດຈັດວາງບັນຊີລາຍຊື່ທີ່ຍອດຢ້ຽມຂອງ [ບາງຄັ້ງ banal, ແຕ່ຍັງ] ບັນຫາທີ່ກົດດັນຫຼາຍແລະຄວາມເຂົ້າໃຈຜິດທີ່ກ່ຽວຂ້ອງກັບການດໍາເນີນງານຂອງກຸ່ມ Kubernetes.

ໃນໄລຍະປີຂອງການນໍາໃຊ້ Kubernetes, ພວກເຮົາໄດ້ເຮັດວຽກກັບກຸ່ມຈໍານວນຫລາຍ (ທັງການຄຸ້ມຄອງແລະບໍ່ມີການຄຸ້ມຄອງ - ໃນ GCP, AWS ແລະ Azure). ເມື່ອເວລາຜ່ານໄປ, ພວກເຮົາເລີ່ມສັງເກດເຫັນວ່າບາງຄວາມຜິດພາດໄດ້ຖືກຊ້ໍາເລື້ອຍໆ. ຢ່າງໃດກໍຕາມ, ບໍ່ມີຄວາມອັບອາຍໃນເລື່ອງນີ້: ພວກເຮົາໄດ້ເຮັດສ່ວນໃຫຍ່ຂອງຕົນເອງ!

ບົດຄວາມມີຂໍ້ຜິດພາດທົ່ວໄປທີ່ສຸດແລະຍັງກ່າວເຖິງວິທີການແກ້ໄຂພວກມັນ.

1. ຊັບພະຍາກອນ: ການຮ້ອງຂໍແລະຂໍ້ຈໍາກັດ

ລາຍການນີ້ແນ່ນອນສົມຄວນໄດ້ຮັບຄວາມສົນໃຈຢ່າງໃກ້ຊິດທີ່ສຸດແລະສະຖານທີ່ທໍາອິດໃນບັນຊີລາຍຊື່.

ປົກກະຕິແລ້ວການຮ້ອງຂໍ CPU ທັງບໍ່ໄດ້ລະບຸໄວ້ທັງໝົດ ຫຼືມີມູນຄ່າຕໍ່າຫຼາຍ (ເພື່ອວາງຝັກໃຫ້ຫຼາຍເທົ່າທີ່ເປັນໄປໄດ້ໃນແຕ່ລະຂໍ້). ດັ່ງນັ້ນ, nodes ກາຍເປັນ overloaded. ໃນຊ່ວງເວລາຂອງການໂຫຼດສູງ, ພະລັງງານການປະມວນຜົນຂອງ node ຖືກນໍາໃຊ້ຢ່າງເຕັມສ່ວນແລະວຽກງານສະເພາະໃດຫນຶ່ງໄດ້ຮັບພຽງແຕ່ສິ່ງທີ່ມັນ "ຮ້ອງຂໍ" ໂດຍ. ການຄວບຄຸມ CPU. ອັນນີ້ເຮັດໃຫ້ການຊັກຊ້າຂອງແອັບພລິເຄຊັນເພີ່ມຂຶ້ນ, ໝົດເວລາ, ແລະຜົນສະທ້ອນທີ່ບໍ່ດີອື່ນໆ. (ອ່ານເພີ່ມເຕີມກ່ຽວກັບເລື່ອງນີ້ໃນການແປຫຼ້າສຸດອື່ນໆຂອງພວກເຮົາ: “ຂີດຈຳກັດ CPU ແລະການຂັດຂວາງທີ່ຮຸກຮານໃນ Kubernetes" - ປະ​ມານ​. ແປ.)

ຄວາມພະຍາຍາມທີ່ດີທີ່ສຸດ (ຢ່າງ​ຍິ່ງ ບໍ່ ແນະ​ນໍາ​:

resources: {}

ການຮ້ອງຂໍ CPU ຕໍ່າຫຼາຍ (ທີ່ສຸດ ບໍ່ ແນະ​ນໍາ​:

   resources:
      Requests:
        cpu: "1m"

ໃນທາງກົງກັນຂ້າມ, ການມີຂອບເຂດຈໍາກັດຂອງ CPU ສາມາດນໍາໄປສູ່ການຂ້າມໂມງທີ່ບໍ່ສົມເຫດສົມຜົນໂດຍ pods, ເຖິງແມ່ນວ່າໂປເຊດເຊີ node ບໍ່ໄດ້ໂຫລດຢ່າງເຕັມທີ່. ອີກເທື່ອຫນຶ່ງ, ນີ້ສາມາດນໍາໄປສູ່ການຊັກຊ້າເພີ່ມຂຶ້ນ. ການໂຕ້ຖຽງກັນຍັງສືບຕໍ່ປະມານພາລາມິເຕີ ໂຄຕ້າ CPU CFS ໃນ Linux kernel ແລະ CPU throttling ຂຶ້ນກັບຂໍ້ຈໍາກັດທີ່ກໍານົດໄວ້, ເຊັ່ນດຽວກັນກັບການປິດການໃຊ້ໂຄຕ້າ CFS ... ອະນິຈາ, ຂອບເຂດຈໍາກັດຂອງ CPU ສາມາດເຮັດໃຫ້ເກີດບັນຫາຫຼາຍກ່ວາທີ່ພວກເຂົາສາມາດແກ້ໄຂໄດ້. ຂໍ້ມູນເພີ່ມເຕີມກ່ຽວກັບເລື່ອງນີ້ສາມາດພົບໄດ້ທີ່ລິ້ງຂ້າງລຸ່ມນີ້.

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

ທ່ານຕ້ອງການຫຼຸດຜ່ອນຄວາມເປັນໄປໄດ້ຂອງເຫດການນີ້ບໍ? ຢ່າຈັດສັນຫນ່ວຍຄວາມຈໍາຫຼາຍເກີນໄປແລະນໍາໃຊ້ການຮັບປະກັນ QoS (ຄຸນນະພາບຂອງການບໍລິການ) ໂດຍກໍານົດການຮ້ອງຂໍຫນ່ວຍຄວາມຈໍາທີ່ຈໍາກັດ (ໃນຕົວຢ່າງຂ້າງລຸ່ມນີ້). ອ່ານເພີ່ມເຕີມກ່ຽວກັບເລື່ອງນີ້ໃນ ການນຳສະເໜີຂອງ Henning Jacobs (ຫົວຫນ້າວິສະວະກອນຢູ່ Zalando).

ລະເບີດໄດ້ (ໂອກາດສູງທີ່ຈະໄດ້ຮັບການຂ້າ OOM):

   resources:
      requests:
        memory: "128Mi"
        cpu: "500m"
      limits:
        memory: "256Mi"
        cpu: 2

ຮັບປະກັນ:

   resources:
      requests:
        memory: "128Mi"
        cpu: 2
      limits:
        memory: "128Mi"
        cpu: 2

ສິ່ງທີ່ອາດຈະຊ່ວຍໄດ້ໃນເວລາທີ່ການສ້າງຕັ້ງຊັບພະຍາກອນ?

ດ້ວຍຄວາມຊ່ວຍເຫຼືອຂອງ metrics-ເຊີບເວີ ທ່ານ​ສາ​ມາດ​ເບິ່ງ​ການ​ບໍ​ລິ​ໂພກ​ຊັບ​ພະ​ຍາ​ກອນ CPU ແລະ​ການ​ນໍາ​ໃຊ້​ຫນ່ວຍ​ຄວາມ​ຈໍາ​ໃນ​ປັດ​ຈຸ​ບັນ​ໂດຍ pods (ແລະ​ການ​ບັນ​ຈຸ​ຢູ່​ໃນ​ພວກ​ເຂົາ​)​. ສ່ວນຫຼາຍອາດຈະ, ທ່ານກໍາລັງໃຊ້ມັນແລ້ວ. ພຽງແຕ່ດໍາເນີນການຄໍາສັ່ງຕໍ່ໄປນີ້:

kubectl top pods
kubectl top pods --containers
kubectl top nodes

ຢ່າງໃດກໍຕາມ, ພວກເຂົາເຈົ້າພຽງແຕ່ສະແດງໃຫ້ເຫັນການນໍາໃຊ້ໃນປະຈຸບັນ. ມັນສາມາດໃຫ້ທ່ານມີຄວາມຄິດທີ່ຫຍາບຄາຍຂອງຄໍາສັ່ງຂອງຂະຫນາດ, ແຕ່ໃນທີ່ສຸດທ່ານຈະຕ້ອງການ ປະຫວັດການປ່ຽນແປງຂອງ metrics ໃນໄລຍະເວລາ (ເພື່ອຕອບຄໍາຖາມເຊັ່ນ: "ການໂຫຼດ CPU ສູງສຸດແມ່ນຫຍັງ?", "ການໂຫຼດໃນຕອນເຊົ້າມື້ວານນີ້ແມ່ນຫຍັງ?", ແລະອື່ນໆ). ສໍາລັບນີ້, ທ່ານສາມາດນໍາໃຊ້ Prometheus, DataDog ແລະເຄື່ອງມືອື່ນໆ. ພວກເຂົາເຈົ້າພຽງແຕ່ໄດ້ຮັບ metrics ຈາກ metrics-server ແລະເກັບຮັກສາໃຫ້ເຂົາເຈົ້າ, ແລະຜູ້ໃຊ້ສາມາດສອບຖາມແລະວາງແຜນໃຫ້ເຂົາເຈົ້າຕາມຄວາມເຫມາະສົມ.

VerticalPodAutoscaler ອະນຸຍາດ ອັດຕະໂນມັດ ຂະບວນການນີ້. ມັນຕິດຕາມປະຫວັດການໃຊ້ CPU ແລະຫນ່ວຍຄວາມຈໍາແລະຕັ້ງຄ່າການຮ້ອງຂໍແລະຂໍ້ຈໍາກັດໃຫມ່ໂດຍອີງໃສ່ຂໍ້ມູນນີ້.

ການໃຊ້ພະລັງງານຄອມພິວເຕີຢ່າງມີປະສິດທິພາບບໍ່ແມ່ນວຽກທີ່ງ່າຍ. ມັນຄ້າຍຄືກັບການຫຼີ້ນ Tetris ຕະຫຼອດເວລາ. ຖ້າທ່ານກໍາລັງຈ່າຍເງິນຫຼາຍເກີນໄປສໍາລັບພະລັງງານຄອມພິວເຕີ້ທີ່ມີການບໍລິໂພກສະເລ່ຍຕ່ໍາ (ເວົ້າວ່າ ~ 10%), ພວກເຮົາແນະນໍາໃຫ້ເບິ່ງຜະລິດຕະພັນໂດຍອີງໃສ່ AWS Fargate ຫຼື Virtual Kubelet. ພວກມັນຖືກສ້າງຢູ່ໃນຮູບແບບການເອີ້ນເກັບເງິນແບບ serverless/pay-per-usage, ເຊິ່ງອາດຈະເຮັດໃຫ້ລາຄາຖືກກວ່າໃນເງື່ອນໄຂດັ່ງກ່າວ.

2. ມີຊີວິດແລະຄວາມພ້ອມ probes

ໂດຍຄ່າເລີ່ມຕົ້ນ, ການກວດສອບຊີວິດ ແລະ ຄວາມພ້ອມຈະບໍ່ຖືກເປີດໃຊ້ໃນ Kubernetes. ແລະບາງຄັ້ງພວກເຂົາລືມເປີດພວກມັນ ...

ແຕ່ແນວໃດອີກແດ່ທີ່ທ່ານສາມາດລິເລີ່ມການບໍລິການໃຫມ່ໃນກໍລະນີທີ່ເກີດຄວາມຜິດພາດຮ້າຍແຮງ? ແລະຜູ້ດຸ່ນດ່ຽງການໂຫຼດຮູ້ໄດ້ແນວໃດວ່າຝັກແມ່ນພ້ອມທີ່ຈະຍອມຮັບການຈະລາຈອນ? ຫຼືວ່າມັນສາມາດຈັດການກັບການຈະລາຈອນຫຼາຍ?

ການທົດສອບເຫຼົ່ານີ້ມັກຈະສັບສົນກັບກັນແລະກັນ:

• ຊີວິດການເປັນຢູ່ — ການກວດສອບ “ຄວາມຢູ່ລອດ”, ເຊິ່ງຈະເລີ່ມຝັກຄືນໃໝ່ ຖ້າມັນລົ້ມເຫລວ;
• ຄວາມພ້ອມ — ການ​ກວດ​ສອບ​ຄວາມ​ພ້ອມ​, ຖ້າ​ຫາກ​ວ່າ​ມັນ​ບໍ່​ສໍາ​ເລັດ​, ມັນ​ຕັດ​ການ​ເຊື່ອມ​ຕໍ່ pod ຈາກ​ການ​ບໍ​ລິ​ການ Kubernetes (ອັນ​ນີ້​ສາ​ມາດ​ກວດ​ສອບ​ໄດ້​ໂດຍ​ນໍາ​ໃຊ້ kubectl get endpoints) ແລະການຈະລາຈອນບໍ່ໄດ້ມາຮອດມັນຈົນກ່ວາການກວດສອບຕໍ່ໄປຈະສໍາເລັດຢ່າງສໍາເລັດຜົນ.

ທັງສອງການກວດສອບເຫຼົ່ານີ້ ປະຕິບັດໃນລະຫວ່າງວົງຈອນຊີວິດທັງຫມົດຂອງ POD. ມັນເປັນສິ່ງສໍາຄັນຫຼາຍ.

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

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

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

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

3. LoadBalancer ສໍາລັບແຕ່ລະບໍລິການ HTTP

ສ່ວນຫຼາຍອາດຈະ, ທ່ານມີບໍລິການ HTTP ຢູ່ໃນກຸ່ມຂອງທ່ານທີ່ທ່ານຕ້ອງການສົ່ງຕໍ່ໄປສູ່ໂລກພາຍນອກ.

ຖ້າທ່ານເປີດບໍລິການເປັນ type: LoadBalancer, ຕົວຄວບຄຸມຂອງມັນ (ຂຶ້ນກັບຜູ້ໃຫ້ບໍລິການ) ຈະສະຫນອງແລະເຈລະຈາກັບ LoadBalancer ພາຍນອກ (ບໍ່ຈໍາເປັນແລ່ນຢູ່ໃນ L7, ແຕ່ແທນທີ່ຈະຢູ່ໃນ L4), ແລະນີ້ອາດຈະສົ່ງຜົນກະທົບຕໍ່ຄ່າໃຊ້ຈ່າຍ (ທີ່ຢູ່ IPv4 ຄົງທີ່ພາຍນອກ, ພະລັງງານຄອມພິວເຕີ້, ການເອີ້ນເກັບເງິນຕໍ່ວິນາທີ. ) ເນື່ອງຈາກຄວາມຕ້ອງການທີ່ຈະສ້າງຈໍານວນຂະຫນາດໃຫຍ່ຂອງຊັບພະຍາກອນດັ່ງກ່າວ.

ໃນ​ກໍ​ລະ​ນີ​ນີ້​, ມັນ​ເປັນ​ຫຼາຍ​ມີ​ເຫດ​ຜົນ​ທີ່​ຈະ​ນໍາ​ໃຊ້​ການ​ດຸ່ນ​ດ່ຽງ​ການ​ໂຫຼດ​ພາຍ​ນອກ​ຫນຶ່ງ​, ການ​ເປີດ​ການ​ບໍ​ລິ​ການ​ເປັນ​ type: NodePort. ຫຼືດີກວ່າ, ຂະຫຍາຍບາງສິ່ງບາງຢ່າງເຊັ່ນ: nginx-ingress-controller (ຫຼື traefik), ຜູ້ທີ່ຈະເປັນຜູ້ດຽວ NodePort ຈຸດສິ້ນສຸດທີ່ກ່ຽວຂ້ອງກັບຕົວດຸ່ນດ່ຽງການໂຫຼດພາຍນອກ ແລະຈະສົ່ງເສັ້ນທາງໃນກຸ່ມໂດຍໃຊ້ ເຄື່ອງດື່ມ- ຊັບ​ພະ​ຍາ​ກອນ Kubernetes​.

ການບໍລິການພາຍໃນກຸ່ມ (ຈຸລະພາກ) ອື່ນໆທີ່ພົວພັນກັບກັນແລະກັນສາມາດ "ສື່ສານ" ໂດຍໃຊ້ການບໍລິການເຊັ່ນ: ClusterIP ແລະກົນໄກການຄົ້ນພົບການບໍລິການທີ່ສ້າງຂຶ້ນຜ່ານ DNS. ພຽງແຕ່ຢ່າໃຊ້ DNS/IP ສາທາລະນະຂອງພວກເຂົາ, ຍ້ອນວ່າມັນສາມາດສົ່ງຜົນກະທົບຕໍ່ການ latency ແລະເພີ່ມຄ່າໃຊ້ຈ່າຍຂອງການບໍລິການຄລາວ.

4. Autoscaling a cluster ໂດຍບໍ່ມີການຄໍານຶງເຖິງຄຸນນະສົມບັດຂອງຕົນ

ເມື່ອເພີ່ມ nodes ແລະເອົາພວກມັນອອກຈາກກຸ່ມ, ທ່ານບໍ່ຄວນອີງໃສ່ບາງຕົວຊີ້ວັດພື້ນຖານເຊັ່ນການໃຊ້ CPU ໃນ nodes ເຫຼົ່ານັ້ນ. ການວາງແຜນ Pod ຕ້ອງຄໍານຶງເຖິງຈໍານວນຫຼາຍ ຂໍ້ຈຳກັດ, ເຊັ່ນ: ຄວາມໃກ້ຊິດຂອງຝອດ/ໂນດ, ຄວາມບໍ່ພໍໃຈ ແລະ ຄວາມທົນທານ, ການຮ້ອງຂໍຊັບພະຍາກອນ, QoS, ແລະອື່ນໆ. ການນໍາໃຊ້ autoscaler ພາຍນອກທີ່ບໍ່ເອົາ nuances ເຫຼົ່ານີ້ເຂົ້າໄປໃນບັນຊີສາມາດນໍາໄປສູ່ບັນຫາ.

ຈິນຕະນາການວ່າຝັກທີ່ແນ່ນອນຄວນຈະຖືກກໍານົດ, ແຕ່ພະລັງງານ CPU ທີ່ມີຢູ່ທັງຫມົດແມ່ນຮ້ອງຂໍ / disassembled ແລະ pod. ໄດ້​ຮັບ stuck ໃນ​ລັດ​ Pending. autoscaler ພາຍນອກເຫັນການໂຫຼດ CPU ໃນປັດຈຸບັນໂດຍສະເລ່ຍ (ບໍ່ແມ່ນອັນທີ່ຮ້ອງຂໍ) ແລະບໍ່ໄດ້ເລີ່ມຕົ້ນການຂະຫຍາຍຕົວ (ອອກຂະໜາດ) - ບໍ່ເພີ່ມ node ອື່ນ. ດັ່ງນັ້ນ, ຝັກນີ້ຈະບໍ່ຖືກກໍານົດ.

ໃນ​ກໍ​ລະ​ນີ​ນີ້​, reverse scale​ (ຂະຫນາດໃນ) — ການຖອນ node ອອກຈາກກຸ່ມແມ່ນຍາກກວ່າທີ່ຈະປະຕິບັດສະເໝີ. ຈິນຕະນາການວ່າທ່ານມີຝັກທີ່ມີສະຖານະ (ມີບ່ອນເກັບຂໍ້ມູນຢ່າງຕໍ່ເນື່ອງເຊື່ອມຕໍ່). ປະລິມານຢ່າງຕໍ່ເນື່ອງ ປົກກະຕິແລ້ວເປັນຂອງ ເຂດການມີໃຫ້ສະເພາະ ແລະບໍ່ໄດ້ຈໍາລອງຢູ່ໃນພາກພື້ນ. ດັ່ງນັ້ນ, ຖ້າຕົວຂະຫຍາຍອັດຕະໂນມັດພາຍນອກລຶບໂຫນດທີ່ມີພອດນີ້, ຕົວກໍານົດເວລາຈະບໍ່ສາມາດຈັດຕາຕະລາງ pod ນີ້ຢູ່ໃນ node ອື່ນໄດ້, ເພາະວ່ານີ້ສາມາດເຮັດໄດ້ພຽງແຕ່ໃນເຂດການມີຢູ່ບ່ອນທີ່ບ່ອນເກັບມ້ຽນຄົງຢູ່. Pod ຈະຕິດຢູ່ໃນສະຖານະ Pending.

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

5. ການລະເລີຍຄວາມສາມາດ IAM/RBAC

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

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

ລືມກ່ຽວກັບ kube2iam ແລະໄປກົງກັບບົດບາດ IAM ສໍາລັບບັນຊີການບໍລິການ (ຕາມທີ່ອະທິບາຍໄວ້ໃນ ຫມາຍເຫດຂອງຊື່ດຽວກັນ Štěpán Vraný):

apiVersion: v1
kind: ServiceAccount
metadata:
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/my-app-role
  name: my-serviceaccount
  namespace: default

ຫນຶ່ງຄໍາບັນຍາຍ. ບໍ່ຍາກ, ແມ່ນບໍ?

ນອກຈາກນັ້ນ, ບໍ່ໃຫ້ບັນຊີການບໍລິການ ແລະສິດທິໂປຣໄຟລ໌ຕົວຢ່າງ admin и cluster-adminຖ້າພວກເຂົາບໍ່ຕ້ອງການ. ນີ້ແມ່ນຄວາມຫຍຸ້ງຍາກເລັກນ້ອຍໃນການປະຕິບັດ, ໂດຍສະເພາະໃນ RBAC K8s, ແຕ່ແນ່ນອນກໍ່ຄຸ້ມຄ່າ.

6. ຢ່າອີງໃສ່ອັດຕະໂນມັດຕ້ານການເປັນພີ່ນ້ອງກັນສໍາລັບຝັກ

ຈິນຕະນາການວ່າທ່ານມີສາມ replicas ຂອງການປະຕິບັດບາງຢູ່ໃນ node. node ຕົກ, ແລະພ້ອມກັບມັນ replicas ທັງຫມົດ. ສະຖານະການທີ່ບໍ່ພໍໃຈ, ແມ່ນບໍ? ແຕ່ເປັນຫຍັງການຈໍາລອງທັງຫມົດຢູ່ໃນ node ດຽວກັນ? Kubernetes ຄວນຈະໃຫ້ຄວາມພ້ອມ (HA) ສູງບໍ?!

ແຕ່ຫນ້າເສຍດາຍ, ຕົວກໍານົດເວລາ Kubernetes, ດ້ວຍການລິເລີ່ມຂອງຕົນເອງ, ບໍ່ປະຕິບັດຕາມກົດລະບຽບຂອງການມີຢູ່ແຍກຕ່າງຫາກ. (ຕ້ານຄວາມສຳພັນ) ສໍາລັບຝັກ. ພວກ​ເຂົາ​ເຈົ້າ​ຕ້ອງ​ໄດ້​ຮັບ​ການ​ລະ​ບຸ​ຢ່າງ​ຊັດ​ເຈນ​:

// опущено для краткости
      labels:
        app: zk
// опущено для краткости
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            - labelSelector:
                matchExpressions:
                  - key: "app"
                    operator: In
                    values:
                    - zk
              topologyKey: "kubernetes.io/hostname"

ຫມົດ​ເທົ່າ​ນີ້. ຕອນນີ້ຝັກຈະຖືກກໍານົດໃຫ້ nodes ທີ່ແຕກຕ່າງກັນ (ເງື່ອນໄຂນີ້ຖືກກວດສອບພຽງແຕ່ໃນລະຫວ່າງການກໍານົດເວລາ, ແຕ່ບໍ່ແມ່ນການດໍາເນີນງານຂອງພວກເຂົາ - ເພາະສະນັ້ນ. requiredDuringSchedulingIgnoredDuringExecution).

ນີ້ພວກເຮົາກໍາລັງເວົ້າກ່ຽວກັບ podAntiAffinity ໃນ nodes ທີ່ແຕກຕ່າງກັນ: topologyKey: "kubernetes.io/hostname", - ແລະບໍ່ກ່ຽວກັບເຂດຄວາມພ້ອມທີ່ແຕກຕ່າງກັນ. ເພື່ອປະຕິບັດ HA ຢ່າງເຕັມທີ່, ທ່ານຈະຕ້ອງຂຸດເລິກເຂົ້າໄປໃນຫົວຂໍ້ນີ້.

7. ການລະເລີຍ PodDisruptionBudgets

ຈິນຕະນາການວ່າທ່ານມີປະລິມານການຜະລິດຢູ່ໃນກຸ່ມ Kubernetes. ແຕ່ລະໄລຍະ, nodes ແລະ cluster ຕົວຂອງມັນເອງຕ້ອງໄດ້ຮັບການປັບປຸງ (ຫຼື decommissioned). PodDisruptionBudget (PDB) ແມ່ນບາງສິ່ງບາງຢ່າງເຊັ່ນ: ຂໍ້ຕົກລົງການຮັບປະກັນການບໍລິການລະຫວ່າງຜູ້ບໍລິຫານກຸ່ມ ແລະຜູ້ໃຊ້.

PDB ອະນຸຍາດໃຫ້ທ່ານເພື່ອຫຼີກເວັ້ນການຂັດຂວາງການບໍລິການທີ່ເກີດຈາກການຂາດແຄນ:

apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
  name: zk-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: zookeeper

ໃນຕົວຢ່າງນີ້, ທ່ານ, ໃນຖານະຜູ້ໃຊ້ຂອງກຸ່ມ, ກ່າວຕໍ່ຜູ້ເບິ່ງແຍງ: "Hey, ຂ້ອຍມີບໍລິການຮັກສາສວນສັດ, ແລະບໍ່ວ່າເຈົ້າຈະເຮັດຫຍັງ, ຂ້ອຍຕ້ອງການຢ່າງຫນ້ອຍ 2 ແບບຈໍາລອງຂອງບໍລິການນີ້ຢູ່ຕະຫຼອດເວລາ. .”

ທ່ານສາມາດອ່ານເພີ່ມເຕີມກ່ຽວກັບເລື່ອງນີ້ ທີ່ນີ້.

8. ຜູ້ໃຊ້ຫຼາຍ ຫຼືສະພາບແວດລ້ອມໃນກຸ່ມທົ່ວໄປ

ພື້ນທີ່ຊື່ Kubernetes (namespaces) ບໍ່ໃຫ້ insulation ທີ່ເຂັ້ມແຂງ.

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

ຜູ້ທີ່ຕ້ອງການລວມເອົາທັງສອງປະເພດຂອງວຽກຢູ່ໃນກຸ່ມດຽວກັນຈະຕ້ອງຈັດການກັບຄວາມສັບສົນ. ຖ້າບໍ່ມີຄວາມຕ້ອງການດັ່ງກ່າວ, ແລະທ່ານສາມາດທີ່ຈະມີຫນຶ່ງ ອີກໜຶ່ງກຸ່ມ (ເວົ້າ, ໃນຟັງສາທາລະນະ), ຫຼັງຈາກນັ້ນມັນດີກວ່າທີ່ຈະເຮັດແນວນັ້ນ. ນີ້ຈະບັນລຸລະດັບສູງຫຼາຍຂອງ insulation.

9. ນະໂຍບາຍການຈະລາຈອນພາຍນອກ: ກຸ່ມ

ເລື້ອຍໆພວກເຮົາເຫັນວ່າການຈະລາຈອນທັງຫມົດພາຍໃນກຸ່ມແມ່ນມາຈາກການບໍລິການເຊັ່ນ NodePort, ເຊິ່ງນະໂຍບາຍເລີ່ມຕົ້ນແມ່ນຖືກກໍານົດ. externalTrafficPolicy: Cluster... ມັນ ໝາຍ ຄວາມວ່າ NodePort ເປີດຢູ່ໃນທຸກ node ໃນ cluster, ແລະທ່ານສາມາດນໍາໃຊ້ໃດໆຂອງພວກເຂົາເພື່ອພົວພັນກັບການບໍລິການທີ່ຕ້ອງການ (ຊຸດຂອງຝັກ).

ໃນເວລາດຽວກັນ, ຝັກທີ່ແທ້ຈິງທີ່ກ່ຽວຂ້ອງກັບການບໍລິການ NodePort ທີ່ກ່າວມາຂ້າງເທິງແມ່ນປົກກະຕິແລ້ວມີຢູ່ໃນສະເພາະໃດຫນຶ່ງ. subset ຂອງ nodes ເຫຼົ່ານີ້. ໃນຄໍາສັບຕ່າງໆອື່ນໆ, ຖ້າຂ້ອຍເຊື່ອມຕໍ່ກັບ node ທີ່ບໍ່ມີ pod ທີ່ຕ້ອງການ, ມັນຈະສົ່ງການຈະລາຈອນໄປຫາ node ອື່ນ, ເພີ່ມ hop ໄດ້ ແລະການລ່າສັດທີ່ເພີ່ມຂຶ້ນ (ຖ້າ nodes ຢູ່ໃນເຂດຄວາມພ້ອມ / ສູນຂໍ້ມູນທີ່ແຕກຕ່າງກັນ, ເວລາ latency ສາມາດຂ້ອນຂ້າງສູງ; ນອກຈາກນັ້ນ, ຄ່າໃຊ້ຈ່າຍຂອງການຈະລາຈອນ egress ຈະເພີ່ມຂຶ້ນ).

ໃນທາງກົງກັນຂ້າມ, ຖ້າບໍລິການ Kubernetes ທີ່ແນ່ນອນມີນະໂຍບາຍທີ່ກໍານົດໄວ້ externalTrafficPolicy: Local, ຫຼັງຈາກນັ້ນ NodePort ເປີດພຽງແຕ່ຢູ່ໃນ nodes ທີ່ pods ທີ່ຕ້ອງການແມ່ນຕົວຈິງແລ້ວແລ່ນ. ເມື່ອໃຊ້ຕົວດຸ່ນດ່ຽງການໂຫຼດພາຍນອກທີ່ກວດສອບສະຖານະ (ກວດ​ສຸ​ຂະ​ພາບ​) ຈຸດສິ້ນສຸດ (ມັນເຮັດແນວໃດ AWS ELB), ລາວ ຈະສົ່ງການຈະລາຈອນພຽງແຕ່ໄປຫາຂໍ້ທີ່ຈໍາເປັນ, ເຊິ່ງຈະມີຜົນກະທົບທີ່ເປັນປະໂຫຍດຕໍ່ການຊັກຊ້າ, ຄວາມຕ້ອງການຄອມພິວເຕີ, ໃບບິນຄ່າ egress (ແລະຄວາມຮູ້ສຶກທົ່ວໄປ dictates ດຽວກັນ).

ມີໂອກາດສູງທີ່ທ່ານກໍາລັງໃຊ້ບາງສິ່ງບາງຢ່າງເຊັ່ນ: traefik ຫຼື nginx-ingress-controller ເປັນຈຸດສິ້ນສຸດຂອງ NodePort (ຫຼື LoadBalancer, ເຊິ່ງຍັງໃຊ້ NodePort) ເພື່ອສົ່ງເສັ້ນທາງ HTTP ingress, ແລະການຕັ້ງຄ່າທາງເລືອກນີ້ສາມາດຫຼຸດຜ່ອນຄວາມລ່າຊ້າສໍາລັບການຮ້ອງຂໍດັ່ງກ່າວຢ່າງຫຼວງຫຼາຍ.

В ສິ່ງພິມນີ້ ທ່ານສາມາດຮຽນຮູ້ເພີ່ມເຕີມກ່ຽວກັບ ນະໂຍບາຍການຄ້າພາຍນອກ, ຂໍ້ດີ ແລະ ຂໍ້ເສຍຂອງມັນ.

10. ບໍ່​ໄດ້​ຮັບ​ການ​ຜູກ​ມັດ​ກັບ​ກຸ່ມ​ແລະ​ບໍ່​ໄດ້​ລ່ວງ​ລະ​ເມີດ​ຍົນ​ຄວບ​ຄຸມ​

ກ່ອນຫນ້ານີ້, ມັນເປັນປະເພນີທີ່ຈະໂທຫາເຄື່ອງແມ່ຂ່າຍໂດຍຊື່ທີ່ເຫມາະສົມ: Anton, HAL9000 ແລະ Colossus ... ມື້ນີ້ພວກມັນໄດ້ຖືກປ່ຽນແທນດ້ວຍຕົວລະບຸທີ່ສ້າງຂຶ້ນແບບສຸ່ມ. ຢ່າງໃດກໍຕາມ, ນິໄສຍັງຄົງຢູ່, ແລະໃນປັດຈຸບັນຊື່ທີ່ເຫມາະສົມໄປເປັນກຸ່ມ.

ເລື່ອງທົ່ວໄປ (ອີງໃສ່ເຫດການທີ່ແທ້ຈິງ): ມັນທັງຫມົດເລີ່ມຕົ້ນດ້ວຍຫຼັກຖານສະແດງແນວຄວາມຄິດ, ດັ່ງນັ້ນກຸ່ມຈຶ່ງມີຊື່ທີ່ພູມໃຈ. ການ​ທົດ​ສອບ… ຫລາຍປີຜ່ານໄປ ແລະມັນຍັງຖືກໃຊ້ໃນການຜະລິດ, ແລະທຸກຄົນຢ້ານທີ່ຈະແຕະຕ້ອງມັນ.

ບໍ່ມີຫຍັງມ່ວນກ່ຽວກັບກຸ່ມທີ່ປ່ຽນເປັນສັດລ້ຽງ, ສະນັ້ນພວກເຮົາຂໍແນະນຳໃຫ້ເອົາພວກມັນອອກເປັນໄລຍະໆໃນຂະນະທີ່ຝຶກຊ້ອມ. ການ​ຟື້ນ​ຟູ​ໄພ​ພິ​ບັດ (ອັນນີ້ຈະຊ່ວຍໄດ້ ວິສະວະກໍາ chaos — ປະ​ມານ​. ແປ.). ນອກຈາກນັ້ນ, ມັນຈະບໍ່ເຈັບປວດທີ່ຈະເຮັດວຽກໃນຊັ້ນຄວບຄຸມ (ຍົນ​ຄວບ​ຄຸມ​). ການຢ້ານທີ່ຈະແຕະຕ້ອງລາວບໍ່ແມ່ນສັນຍານທີ່ດີ. ເປັນຕົ້ນ. ຕາຍ? Guys, ເຈົ້າຢູ່ໃນບັນຫາແທ້ໆ!

ໃນອີກດ້ານຫນຶ່ງ, ທ່ານບໍ່ຄວນຈະໄດ້ຮັບການດໍາເນີນການກັບ manipulating ມັນ. ດ້ວຍເວລາ ຊັ້ນຄວບຄຸມອາດຈະຊ້າ. ສ່ວນຫຼາຍອາດຈະ, ນີ້ແມ່ນຍ້ອນວັດຖຸຈໍານວນຫລາຍທີ່ຖືກສ້າງຂື້ນໂດຍບໍ່ມີການຫມຸນຂອງມັນ (ສະຖານະການທົ່ວໄປໃນເວລາທີ່ໃຊ້ Helm ກັບການຕັ້ງຄ່າເລີ່ມຕົ້ນ, ຊຶ່ງເປັນເຫດຜົນທີ່ວ່າສະຖານະຂອງມັນຢູ່ໃນ configmaps / ຄວາມລັບບໍ່ໄດ້ຖືກປັບປຸງ - ດັ່ງນັ້ນ, ວັດຖຸພັນໆສະສົມຢູ່ໃນ. ຊັ້ນຄວບຄຸມ) ຫຼືດ້ວຍການແກ້ໄຂວັດຖຸ kube-api ຄົງທີ່ (ສໍາລັບການປັບຂະຫນາດອັດຕະໂນມັດ, ສໍາລັບ CI/CD, ສໍາລັບການຕິດຕາມ, ບັນທຶກເຫດການ, ການຄວບຄຸມ, ແລະອື່ນໆ).

ນອກຈາກນັ້ນ, ພວກເຮົາແນະນຳໃຫ້ກວດເບິ່ງຂໍ້ຕົກລົງ SLA/SLO ກັບຜູ້ໃຫ້ບໍລິການ Kubernetes ທີ່ມີການຄຸ້ມຄອງ ແລະໃຫ້ຄວາມສົນໃຈຕໍ່ການຮັບປະກັນ. ຜູ້ຂາຍສາມາດຮັບປະກັນ ຄວບຄຸມຄວາມພ້ອມຂອງຊັ້ນຂໍ້ມູນ (ຫຼືອົງປະກອບຍ່ອຍຂອງມັນ), ແຕ່ບໍ່ແມ່ນການຊັກຊ້າ p99 ຂອງການຮ້ອງຂໍທີ່ທ່ານສົ່ງໄປຫາມັນ. ໃນຄໍາສັບຕ່າງໆອື່ນໆ, ທ່ານສາມາດເຂົ້າໄປໃນ kubectl get nodes, ແລະໄດ້ຮັບຄໍາຕອບພຽງແຕ່ຫຼັງຈາກ 10 ນາທີ, ແລະນີ້ຈະບໍ່ເປັນການລະເມີດຂໍ້ກໍານົດຂອງສັນຍາການບໍລິການ.

11. ໂບນັດ: ການນໍາໃຊ້ແທັກຫຼ້າສຸດ

ແຕ່ນີ້ແມ່ນແລ້ວຄລາສສິກ. ບໍ່ດົນມານີ້ພວກເຮົາໄດ້ພົບເຕັກນິກນີ້ຫນ້ອຍລົງເລື້ອຍໆ, ນັບຕັ້ງແຕ່ຫຼາຍໆຄົນ, ໄດ້ຮຽນຮູ້ຈາກປະສົບການທີ່ຂົມຂື່ນ, ໄດ້ຢຸດເຊົາການໃຊ້ແທັກ :latest ແລະເລີ່ມການປັກໝຸດສະບັບ. ໂຫ້ຍ!

ECR ຮັກສາ immutability ຂອງ tags ຮູບພາບ; ພວກເຮົາແນະນໍາໃຫ້ທ່ານຄຸ້ນເຄີຍກັບຄຸນສົມບັດທີ່ໂດດເດັ່ນນີ້.

Summary

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

ທ່ານສາມາດຮູ້ຈັກກັບປະສົບການທີ່ບໍ່ປະສົບຜົນສໍາເລັດຂອງທີມງານຕ່າງໆໃນ ການ​ເກັບ​ກໍາ​ເລື່ອງ​ນີ້​ ໂດຍ Henning Jacobs.

ຜູ້​ທີ່​ຕ້ອງ​ການ​ທີ່​ຈະ​ເພີ່ມ​ບັນ​ຊີ​ລາຍ​ການ​ຂອງ​ຄວາມ​ຜິດ​ພາດ​ທີ່​ໄດ້​ຮັບ​ໃນ​ບົດ​ຄວາມ​ນີ້​ສາ​ມາດ​ຕິດ​ຕໍ່​ຫາ​ພວກ​ເຮົາ​ກ່ຽວ​ກັບ Twitter (@MarekBartik, @MstrsObserver).

PS ຈາກນັກແປ

ອ່ານຍັງຢູ່ໃນ blog ຂອງພວກເຮົາ:

• «ການອອກແບບກຸ່ມ Kubernetes: ຄວນມີຈໍານວນເທົ່າໃດ?"
• «ABC ຂອງຄວາມປອດໄພໃນ Kubernetes: ການກວດສອບຄວາມຖືກຕ້ອງ, ການອະນຸຍາດ, ການກວດສອບ"
• «ການປັບຂະໜາດອັດຕະໂນມັດ ແລະການຈັດການຊັບພະຍາກອນໃນ Kubernetes"(ການທົບທວນແລະບົດລາຍງານວິດີໂອ);
• «ConfigMaps ໃນ Kubernetes: nuances ຕົກເປັນມູນຄ່າຮູ້ກ່ຽວກັບ".

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