ປະສົບການຂອງພວກເຮົາໃນການພັດທະນາໄດເວີ CSI ໃນ Kubernetes ສໍາລັບ Yandex.Cloud

ພວກເຮົາມີຄວາມຍິນດີທີ່ຈະປະກາດວ່າ Flan ກໍາລັງຂະຫຍາຍການປະກອບສ່ວນຂອງຕົນໃຫ້ກັບເຄື່ອງມື Open Source ສໍາລັບ Kubernetes ໂດຍການປ່ອຍ ເວີຊັ່ນອັນຟາຂອງໄດເວີ CSI (Container Storage Interface) ສໍາລັບ Yandex.Cloud.

ແຕ່ກ່ອນທີ່ຈະກ້າວໄປສູ່ລາຍລະອຽດການປະຕິບັດ, ໃຫ້ຕອບຄໍາຖາມວ່າເປັນຫຍັງອັນນີ້ຈຶ່ງຈໍາເປັນໃນເວລາທີ່ Yandex ມີບໍລິການແລ້ວ. ການຄຸ້ມຄອງການບໍລິການສໍາລັບ Kubernetes.

ການນໍາສະເຫນີ

ເປັນຫຍັງຄືອັນນີ້?

ພາຍໃນບໍລິສັດຂອງພວກເຮົາ, ຕັ້ງແຕ່ເລີ່ມຕົ້ນຂອງການນໍາໃຊ້ Kubernetes ໃນການຜະລິດ (i. e. ເປັນເວລາຫຼາຍປີໃນປັດຈຸບັນ), ພວກເຮົາໄດ້ພັດທະນາເຄື່ອງມືຂອງພວກເຮົາເອງ (deckhouse), ເຊິ່ງ, ໂດຍວິທີທາງການ, ພວກເຮົາຍັງວາງແຜນທີ່ຈະສາມາດໃຊ້ໄດ້ໃນໄວໆນີ້ເປັນໂຄງການ Open Source. . ດ້ວຍການຊ່ວຍເຫຼືອຂອງມັນ, ພວກເຮົາກຳນົດຄ່າ ແລະ ກຳນົດຄ່າກຸ່ມທັງໝົດຂອງພວກເຮົາຢ່າງເປັນເອກະພາບ, ແລະ ປະຈຸບັນມີຫຼາຍກວ່າ 100 ພວກມັນແລ້ວ, ຢູ່ໃນການກຳນົດຄ່າຮາດແວທີ່ຫຼາກຫຼາຍ ແລະ ໃນການບໍລິການຄລາວທັງໝົດທີ່ມີຢູ່.

ກຸ່ມທີ່ໃຊ້ deckhouse ມີອົງປະກອບທັງຫມົດທີ່ຈໍາເປັນສໍາລັບການປະຕິບັດງານ: ການດຸ່ນດ່ຽງ, ການຕິດຕາມກັບຕາຕະລາງທີ່ສະດວກ, metrics ແລະການແຈ້ງເຕືອນ, ການກວດສອບຜູ້ໃຊ້ຜ່ານຜູ້ໃຫ້ບໍລິການພາຍນອກເພື່ອເຂົ້າເຖິງ dashboards ທັງຫມົດ, ແລະອື່ນໆ. ບໍ່ມີຈຸດໃດໃນການຕິດຕັ້ງກຸ່ມ "pumped" ດັ່ງກ່າວໃນການແກ້ໄຂທີ່ມີການຄຸ້ມຄອງ, ເນື່ອງຈາກວ່ານີ້ມັກຈະເປັນໄປບໍ່ໄດ້ຫຼືຈະນໍາໄປສູ່ຄວາມຕ້ອງການທີ່ຈະປິດການທໍາງານເຄິ່ງຫນຶ່ງຂອງອົງປະກອບ.

NB: ນີ້ແມ່ນປະສົບການຂອງພວກເຮົາ, ແລະມັນແມ່ນຂ້ອນຂ້າງສະເພາະ. ພວກເຮົາບໍ່ໄດ້ແນະນຳໃຫ້ທຸກຄົນຄວນນຳໃຊ້ກຸ່ມ Kubernetes ດ້ວຍຕົວເຂົາເຈົ້າເອງ ແທນທີ່ຈະໃຊ້ວິທີແກ້ໄຂທີ່ພ້ອມແລ້ວ. ໂດຍວິທີທາງການ, ພວກເຮົາບໍ່ມີປະສົບການທີ່ແທ້ຈິງໃນການດໍາເນີນງານ Kubernetes ຈາກ Yandex ແລະພວກເຮົາຈະບໍ່ໃຫ້ການປະເມີນການບໍລິການໃດໆໃນບົດຄວາມນີ້.

ມັນແມ່ນຫຍັງແລະສໍາລັບໃຜ?

ດັ່ງນັ້ນ, ພວກເຮົາໄດ້ເວົ້າກ່ຽວກັບວິທີການທີ່ທັນສະໄຫມໃນການເກັບຮັກສາໃນ Kubernetes ແລ້ວ: CSI ເຮັດວຽກແນວໃດ? и ຊຸມຊົນມາແນວໃດ ຕໍ່ກັບວິທີການນີ້.

ໃນປັດຈຸບັນ, ຜູ້ໃຫ້ບໍລິການຄລາວຂະຫນາດໃຫຍ່ຈໍານວນຫຼາຍໄດ້ພັດທະນາໄດເວີສໍາລັບການນໍາໃຊ້ແຜ່ນເມຄຂອງພວກເຂົາເປັນປະລິມານຄົງທີ່ໃນ Kubernetes. ຖ້າຜູ້ສະຫນອງບໍ່ມີໄດເວີດັ່ງກ່າວ, ແຕ່ຫນ້າທີ່ທີ່ຈໍາເປັນທັງຫມົດແມ່ນສະຫນອງໃຫ້ຜ່ານ API, ຫຼັງຈາກນັ້ນບໍ່ມີຫຍັງປ້ອງກັນທ່ານຈາກການປະຕິບັດຕົວຂັບຕົວທ່ານເອງ. ນີ້ແມ່ນສິ່ງທີ່ເກີດຂຶ້ນກັບ Yandex.Cloud.

ພວກເຮົາຖືເປັນພື້ນຖານສໍາລັບການພັດທະນາ ໄດເວີ CSI ສໍາລັບ DigitalOcean cloud ແລະຄູ່ນ່ຶຂອງແນວຄວາມຄິດຈາກ ໄດເວີສໍາລັບ GCP, ນັບຕັ້ງແຕ່ການໂຕ້ຕອບກັບ API ຂອງຟັງເຫຼົ່ານີ້ (Google ແລະ Yandex) ມີຄວາມຄ້າຍຄືກັນຫຼາຍ. ໂດຍສະເພາະ, API ແລະ GCP, ແລະຢູ່ Yandex ສົ່ງຄືນວັດຖຸ Operation ເພື່ອຕິດຕາມສະຖານະຂອງການດໍາເນີນງານທີ່ຍາວນານ (ຕົວຢ່າງເຊັ່ນການສ້າງແຜ່ນໃຫມ່). ເພື່ອໂຕ້ຕອບກັບ Yandex.Cloud API, ໃຫ້ໃຊ້ Yandex.Cloud Go SDK.

ຜົນໄດ້ຮັບຂອງວຽກງານທີ່ເຮັດ ຈັດພີມມາຢູ່ໃນ GitHub ແລະອາດຈະເປັນປະໂຫຍດສໍາລັບຜູ້ທີ່, ດ້ວຍເຫດຜົນບາງຢ່າງ, ໃຊ້ການຕິດຕັ້ງ Kubernetes ຂອງຕົນເອງໃນ Yandex.Cloud virtual machines (ແຕ່ບໍ່ແມ່ນ cluster ທີ່ມີການຈັດການທີ່ກຽມພ້ອມ) ແລະຕ້ອງການໃຊ້ (ສັ່ງ) disks ຜ່ານ CSI.

Реализация

ລັກສະນະທີ່ ສຳ ຄັນ

ໃນປັດຈຸບັນຄົນຂັບສະຫນັບສະຫນູນຫນ້າທີ່ດັ່ງຕໍ່ໄປນີ້:

• ການສັ່ງແຜ່ນໃນທຸກເຂດຂອງກຸ່ມຕາມ topology ຂອງ nodes ໃນ cluster;
• ຖອນແຜ່ນທີ່ສັ່ງກ່ອນຫນ້ານີ້;
• ປັບຂະໜາດອອບລາຍສຳລັບແຜ່ນ (Yandex.Cloud ບໍ່ສະຫນັບສະຫນູນ ເພີ່ມແຜ່ນທີ່ຕິດຢູ່ກັບເຄື່ອງ virtual). ສໍາລັບຂໍ້ມູນກ່ຽວກັບວິທີທີ່ຄົນຂັບຕ້ອງໄດ້ຮັບການດັດແປງເພື່ອເຮັດໃຫ້ການປັບຂະຫນາດບໍ່ເຈັບປວດເທົ່າທີ່ເປັນໄປໄດ້, ເບິ່ງຂ້າງລຸ່ມນີ້.

ໃນອະນາຄົດ, ພວກເຮົາວາງແຜນທີ່ຈະປະຕິບັດການສະຫນັບສະຫນູນສໍາລັບການສ້າງແລະລຶບພາບຖ່າຍແຜ່ນ.

ຄວາມຫຍຸ້ງຍາກຕົ້ນຕໍແລະວິທີການເອົາຊະນະມັນ

ການຂາດຄວາມສາມາດໃນການເພີ່ມແຜ່ນໃນເວລາທີ່ແທ້ຈິງໃນ Yandex.Cloud API ແມ່ນຂໍ້ຈໍາກັດທີ່ເຮັດໃຫ້ເກີດຄວາມສັບສົນຕໍ່ການປະຕິບັດການປັບຂະຫນາດສໍາລັບ PV (Persistent Volume): ໃນກໍລະນີນີ້, ມັນເປັນສິ່ງຈໍາເປັນທີ່ pod ຄໍາຮ້ອງສະຫມັກທີ່ໃຊ້ແຜ່ນຖືກຢຸດ, ແລະນີ້ສາມາດເຮັດໃຫ້ຄໍາຮ້ອງສະຫມັກ downtime.

ອີງຕາມການ ຂໍ້ມູນຈໍາເພາະຂອງ CSI, ຖ້າຕົວຄວບຄຸມ CSI ລາຍງານວ່າມັນສາມາດປັບຂະຫນາດແຜ່ນພຽງແຕ່ "ອອບໄລນ໌" (VolumeExpansion.OFFLINE), ຫຼັງຈາກນັ້ນ, ຂະບວນການເພີ່ມແຜ່ນຄວນຈະເປັນເຊັ່ນນີ້:

ຖ້າ plugin ມີພຽງແຕ່ VolumeExpansion.OFFLINE ຄວາມສາມາດໃນການຂະຫຍາຍແລະປະລິມານໄດ້ຖືກເຜີຍແຜ່ໃນປັດຈຸບັນຫຼືມີຢູ່ໃນ node ຫຼັງຈາກນັ້ນ ControllerExpandVolume ຕ້ອງຖືກເອີ້ນພຽງແຕ່ຫຼັງຈາກທັງສອງ:

• plugin ມີຕົວຄວບຄຸມ PUBLISH_UNPUBLISH_VOLUME ຄວາມ​ສາ​ມາດ​ແລະ​ ControllerUnpublishVolume ໄດ້ຖືກເອີ້ນຢ່າງສໍາເລັດຜົນ.

ຫຼືອື່ນໆ

• ປລັກອິນບໍ່ມີຕົວຄວບຄຸມ PUBLISH_UNPUBLISH_VOLUME ຄວາມສາມາດ, plugin ມີ node STAGE_UNSTAGE_VOLUME ຄວາມສາມາດ, ແລະ NodeUnstageVolume ໄດ້ຮັບການສໍາເລັດສົບຜົນສໍາເລັດ.

ຫຼືອື່ນໆ

• ປລັກອິນບໍ່ມີຕົວຄວບຄຸມ PUBLISH_UNPUBLISH_VOLUME ຄວາມສາມາດ, ຫຼື node STAGE_UNSTAGE_VOLUME ຄວາມສາມາດ, ແລະ NodeUnpublishVolume ໄດ້​ສໍາ​ເລັດ​ຢ່າງ​ສໍາ​ເລັດ​ຜົນ​.

ນີ້ຫມາຍຄວາມວ່າທ່ານຈໍາເປັນຕ້ອງໄດ້ແຍກແຜ່ນອອກຈາກເຄື່ອງ virtual ກ່ອນທີ່ຈະຂະຫຍາຍມັນ.

ຢ່າງໃດກໍຕາມ, ແຕ່ຫນ້າເສຍດາຍ ການຈັດຕັ້ງປະຕິບັດ ຂໍ້ກໍານົດ CSI ຜ່ານ sidecars ບໍ່ຕອບສະຫນອງຄວາມຕ້ອງການເຫຼົ່ານີ້:

• ໃນຕູ້ຄອນເທນເນີລົດຂ້າງ csi-attacher, ທີ່ຄວນຈະຮັບຜິດຊອບສໍາລັບການມີຊ່ອງຫວ່າງທີ່ກໍານົດໄວ້ລະຫວ່າງ mounts, ຫນ້າທີ່ນີ້ແມ່ນບໍ່ໄດ້ປະຕິບັດພຽງແຕ່ໃນການປັບຂະຫນາດອອຟໄລ. ການສົນທະນາກ່ຽວກັບເລື່ອງນີ້ໄດ້ຖືກລິເລີ່ມ ທີ່ນີ້.
• ຕູ້ຄອນເທນເນີ sidecar ແມ່ນຫຍັງແທ້ໃນສະພາບການນີ້? ປັ໊ກອິນ CSI ຕົວຂອງມັນເອງບໍ່ໄດ້ພົວພັນກັບ Kubernetes API, ແຕ່ພຽງແຕ່ຕອບສະຫນອງກັບການໂທ gRPC ທີ່ສົ່ງໄປຫາມັນໂດຍຖັງຂ້າງ. ລ່າສຸດ ກໍາລັງຖືກພັດທະນາ ໂດຍຊຸມຊົນ Kubernetes.

ໃນກໍລະນີຂອງພວກເຮົາ (CSI plugin), ການດໍາເນີນງານຂອງການເພີ່ມແຜ່ນເບິ່ງຄືວ່ານີ້:

1. ພວກເຮົາໄດ້ຮັບການໂທຫາ gRPC ControllerExpandVolume;
2. ພວກເຮົາກໍາລັງພະຍາຍາມເພີ່ມແຜ່ນໃນ API, ແຕ່ພວກເຮົາໄດ້ຮັບຂໍ້ຜິດພາດກ່ຽວກັບຄວາມເປັນໄປບໍ່ໄດ້ຂອງການປະຕິບັດການດໍາເນີນການເພາະວ່າແຜ່ນຖືກຕິດຕັ້ງ;
3. ພວກເຮົາເກັບຮັກສາຕົວລະບຸດິສກ໌ໄວ້ໃນແຜນທີ່, ເຊິ່ງປະກອບດ້ວຍແຜ່ນທີ່ຕ້ອງດໍາເນີນການເພີ່ມຂຶ້ນ. ຂ້າງລຸ່ມນີ້, ສໍາລັບ brevity, ພວກເຮົາຈະໂທຫາແຜນທີ່ນີ້ເປັນ volumeResizeRequired;
4. ເອົາຝັກທີ່ກຳລັງໃຊ້ແຜ່ນອອກດ້ວຍຕົນເອງ. Kubernetes ຈະປິດເປີດມັນຄືນໃໝ່. ເພື່ອ​ໃຫ້​ແຜ່ນ​ບໍ່​ມີ​ເວ​ລາ​ທີ່​ຈະ​ຕິດ​ຕັ້ງ (.ControllerPublishVolume) ກ່ອນທີ່ຈະສໍາເລັດການເພີ່ມຂຶ້ນໃນເວລາທີ່ພະຍາຍາມ mount, ພວກເຮົາກວດເບິ່ງວ່າແຜ່ນທີ່ໃຫ້ແມ່ນຍັງຢູ່ໃນ volumeResizeRequired ແລະສົ່ງຄືນຂໍ້ຜິດພາດ;
5. ໄດເວີ CSI ພະຍາຍາມປະຕິບັດການປັບຂະໜາດຄືນໃໝ່. ຖ້າການດໍາເນີນງານປະສົບຜົນສໍາເລັດ, ຫຼັງຈາກນັ້ນເອົາແຜ່ນອອກຈາກ volumeResizeRequired;
6. ເນື່ອງຈາກວ່າ Disk ID ຫາຍໄປຈາກ volumeResizeRequired, ControllerPublishVolume ຜ່ານຢ່າງສໍາເລັດຜົນ, ແຜ່ນຖືກຕິດຕັ້ງ, ຝັກເລີ່ມຕົ້ນ.

ທຸກສິ່ງທຸກຢ່າງເບິ່ງງ່າຍດາຍພຽງພໍ, ແຕ່ວ່າສະເຫມີມີ pitfalls. ຂະຫຍາຍແຜ່ນ ຕົວປັບປ່ຽນພາຍນອກ, ເຊິ່ງໃນກໍລະນີຂອງຄວາມຜິດພາດໃນລະຫວ່າງການປະຕິບັດງານ ໃຊ້ຄິວ ດ້ວຍການເພີ່ມເວລາໝົດເວລາເຖິງ 1000 ວິນາທີ:

func DefaultControllerRateLimiter() RateLimiter {
  return NewMaxOfRateLimiter(
  NewItemExponentialFailureRateLimiter(5*time.Millisecond, 1000*time.Second),
  // 10 qps, 100 bucket size.  This is only for retry speed and its only the overall factor (not per item)
  &BucketRateLimiter{Limiter: rate.NewLimiter(rate.Limit(10), 100)},
  )
}

ອັນນີ້ສາມາດສົ່ງຜົນໃຫ້ການຂະຫຍາຍດິສກ໌ຖືກຂະຫຍາຍເປັນໄລຍະໆເປັນເວລາ 15+ ນາທີ ແລະດັ່ງນັ້ນ, ພອດທີ່ສອດຄ້ອງກັນບໍ່ສາມາດໃຊ້ໄດ້.

ທາງເລືອກດຽວທີ່ຂ້ອນຂ້າງງ່າຍແລະບໍ່ເຈັບປວດໄດ້ອະນຸຍາດໃຫ້ພວກເຮົາຫຼຸດຜ່ອນເວລາທີ່ອາດມີ downtime ແມ່ນການໃຊ້ຕົວປັບປ່ຽນພາຍນອກຂອງພວກເຮົາທີ່ມີກໍານົດເວລາສູງສຸດ. ໃນ 5 ວິນາທີ:

workqueue.NewItemExponentialFailureRateLimiter(5*time.Millisecond, 5*time.Second)

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

ຈະເລີ່ມໃຊ້ແນວໃດ?

ໄດເວີແມ່ນຮອງຮັບໃນ Kubernetes ເວີຊັ່ນ 1.15 ແລະສູງກວ່າ. ສໍາລັບຄົນຂັບລົດທີ່ຈະເຮັດວຽກ, ຕ້ອງປະຕິບັດຕາມຄວາມຕ້ອງການດັ່ງຕໍ່ໄປນີ້:

• Flag --allow-privileged ຕັ້ງເປັນຄ່າ true ສໍາລັບເຄື່ອງແມ່ຂ່າຍ API ແລະ kubelet;
• ລວມ --feature-gates=VolumeSnapshotDataSource=true,KubeletPluginsWatcher=true,CSINodeInfo=true,CSIDriverRegistry=true ສໍາລັບເຄື່ອງແມ່ຂ່າຍ API ແລະ kubelet;
• ການຂະຫຍາຍພັນຂອງພູ (ການຂະຫຍາຍພັນຂອງພູ) ຕ້ອງຖືກເປີດໃຊ້ໃນກຸ່ມ. ເມື່ອໃຊ້ Docker, daemon ຕ້ອງໄດ້ຮັບການ configured ເພື່ອອະນຸຍາດໃຫ້ແບ່ງປັນ mounts.

ຂັ້ນຕອນທີ່ຈໍາເປັນທັງຫມົດສໍາລັບການຕິດຕັ້ງຕົວມັນເອງ ອະທິບາຍໄວ້ໃນ README. ການຕິດຕັ້ງກ່ຽວຂ້ອງກັບການສ້າງວັດຖຸໃນ Kubernetes ຈາກ manifests.

ສໍາລັບຄົນຂັບເຮັດວຽກ, ທ່ານຈະຕ້ອງການດັ່ງຕໍ່ໄປນີ້:

• ລະບຸຕົວລະບຸໄດເລກະທໍລີໃນ manifest (folder-id) Yandex.Cloud (ເບິ່ງເອກະສານ);
• ເພື່ອພົວພັນກັບ Yandex.Cloud API, ໄດເວີ CSI ໃຊ້ບັນຊີບໍລິການ. ໃນ manifest, ຄວາມລັບຕ້ອງໄດ້ຮັບການຜ່ານ ກະແຈທີ່ໄດ້ຮັບອະນຸຍາດ ຈາກບັນຊີການບໍລິການ. ໃນເອກະສານ ອະທິບາຍ, ວິທີການສ້າງບັນຊີການບໍລິການແລະຮັບລະຫັດ.

ທັງ​ຫມົດ​ທັງ​ຫມົດ - ພະຍາຍາມ, ແລະພວກເຮົາຈະດີໃຈທີ່ຈະໄດ້ຮັບຄໍາຄຶດຄໍາເຫັນແລະ ບັນຫາໃຫມ່ຖ້າ​ຫາກ​ທ່ານ​ພົບ​ບັນ​ຫາ​ໃດ​ຫນຶ່ງ​!

ສະຫນັບສະຫນູນເພີ່ມເຕີມ

ດັ່ງນັ້ນ, ພວກເຮົາຕ້ອງການທີ່ຈະສັງເກດວ່າພວກເຮົາປະຕິບັດຕົວຂັບ CSI ນີ້ບໍ່ໄດ້ອອກຈາກຄວາມປາຖະຫນາທີ່ຍິ່ງໃຫຍ່ທີ່ຈະມີຄວາມມ່ວນໃນການຂຽນຄໍາຮ້ອງສະຫມັກໃນ Go, ແຕ່ຍ້ອນຄວາມຕ້ອງການອັນຮີບດ່ວນພາຍໃນບໍລິສັດ. ມັນເບິ່ງຄືວ່າບໍ່ມີປະໂຫຍດຕໍ່ພວກເຮົາທີ່ຈະຮັກສາການປະຕິບັດຂອງພວກເຮົາເອງ, ດັ່ງນັ້ນຖ້າ Yandex ສະແດງຄວາມສົນໃຈແລະຕັດສິນໃຈສືບຕໍ່ສະຫນັບສະຫນູນຜູ້ຂັບຂີ່, ພວກເຮົາຈະຍິນດີທີ່ຈະໂອນບ່ອນເກັບມ້ຽນໃຫ້ພວກເຂົາ.

ນອກຈາກນັ້ນ, Yandex ອາດຈະມີການປະຕິບັດຂອງຕົນເອງຂອງໄດເວີ CSI ໃນກຸ່ມ Kubernetes ທີ່ຖືກຄຸ້ມຄອງ, ເຊິ່ງສາມາດຖືກປ່ອຍອອກມາໃນ Open Source. ພວກເຮົາຍັງເຫັນວ່າທາງເລືອກໃນການພັດທະນານີ້ແມ່ນເອື້ອອໍານວຍ - ຊຸມຊົນຈະສາມາດນໍາໃຊ້ໄດເວີທີ່ພິສູດແລ້ວຈາກຜູ້ໃຫ້ບໍລິການ, ແລະບໍ່ແມ່ນຈາກບໍລິສັດພາກສ່ວນທີສາມ.

PS

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

• «ປັ໊ກອິນປະລິມານສໍາລັບການເກັບຮັກສາ Kubernetes: ຈາກ Flexvolume ເຖິງ CSI"
• «ພວກເຮົາເຂົ້າໃຈການໂຕ້ຕອບການເກັບຮັກສາຕູ້ຄອນເທນເນີ (ໃນ Kubernetes ແລະບໍ່ພຽງແຕ່)"
• «ມັນງ່າຍ ແລະສະດວກໃນການກະກຽມກຸ່ມ Kubernetes ບໍ? ປະກາດ addon-operator"
• «ການ​ຂະ​ຫຍາຍ​ແລະ​ເສີມ Kubernetes (ການ​ທົບ​ທວນ​ຄືນ​ແລະ​ລາຍ​ງານ​ວິ​ດີ​ໂອ​)".

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