ຂໍແນະນໍາ Kubernetes CCM (Cloud Controller Manager) ສໍາລັບ Yandex.Cloud

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

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

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

ແຮງຈູງໃຈທີ່ກະຕຸ້ນໃຫ້ພວກເຮົາພັດທະນາ CCM ສໍາລັບ Yandex.Cloud ຢ່າງສົມບູນກັບສິ່ງທີ່ອະທິບາຍໄວ້ໃນ ປະກາດ ໄດເວີ CSI. ພວກເຮົາຮັກສາຫຼາຍກຸ່ມ Kubernetes ຈາກຜູ້ໃຫ້ບໍລິການຄລາວທີ່ແຕກຕ່າງກັນ, ເຊິ່ງພວກເຮົາໃຊ້ເຄື່ອງມືດຽວ. ມັນປະຕິບັດຄວາມສະດວກສະບາຍຫຼາຍຢ່າງ "ຂ້າມ" ການແກ້ໄຂການຄຸ້ມຄອງຂອງຜູ້ໃຫ້ບໍລິການເຫຼົ່ານີ້. ແມ່ນແລ້ວ, ພວກເຮົາມີກໍລະນີແລະຄວາມຕ້ອງການສະເພາະ, ແຕ່ການພັດທະນາທີ່ສ້າງຂຶ້ນເນື່ອງຈາກວ່າພວກມັນອາດຈະເປັນປະໂຫຍດຕໍ່ຜູ້ໃຊ້ອື່ນໆ.

CCM ແມ່ນຫຍັງ?

ໂດຍປົກກະຕິ, ພວກເຮົາກະກຽມສະພາບແວດລ້ອມອ້ອມຂ້າງພວກເຮົາສໍາລັບກຸ່ມ ຈາກພາຍນອກ - ສໍາລັບການຍົກຕົວຢ່າງ, ການນໍາໃຊ້ Terraform. ແຕ່ບາງຄັ້ງກໍ່ຈໍາເປັນຕ້ອງມີການຄຸ້ມຄອງສະພາບແວດລ້ອມເມຄທີ່ອ້ອມຮອບພວກເຮົາ ຈາກກຸ່ມ. ຄວາມເປັນໄປໄດ້ນີ້ແມ່ນສະຫນອງໃຫ້, ແລະມັນແມ່ນການຈັດຕັ້ງປະຕິບັດ CCM.

ໂດຍສະເພາະ, Cloud Controller Manager ໃຫ້ຫ້າປະເພດຂອງການໂຕ້ຕອບຕົ້ນຕໍ:

1. ຕົວຢ່າງ - ປະ​ຕິ​ບັດ​ຄວາມ​ສໍາ​ພັນ 1:1 ລະ​ຫວ່າງ​ວັດ​ຖຸ node ໃນ Kubernetes (Node) ແລະເຄື່ອງ virtual ໃນຜູ້ໃຫ້ບໍລິການຟັງ. ສໍາລັບນີ້ພວກເຮົາ:
   • ຕື່ມຂໍ້ມູນໃສ່ໃນພາກສະຫນາມ spec.providerID ໃນວັດຖຸ Node. ຕົວຢ່າງ, ສໍາລັບ OpenStack CCM ພາກສະຫນາມນີ້ມີຮູບແບບດັ່ງຕໍ່ໄປນີ້: openstack:///d58a78bf-21b0-4682-9dc6-2132406d2bb0. ທ່ານສາມາດເບິ່ງຊື່ຂອງຜູ້ໃຫ້ບໍລິການຟັງແລະ UUID ທີ່ເປັນເອກະລັກຂອງເຄື່ອງແມ່ຂ່າຍ (ເຄື່ອງ virtual ໃນ OpenStack) ຂອງວັດຖຸ;
   • ເສີມ nodeInfo ໃນວັດຖຸ Node ຂໍ້ມູນກ່ຽວກັບເຄື່ອງ virtual. ຕົວຢ່າງ, ພວກເຮົາລະບຸປະເພດຕົວຢ່າງໃນ AWS;
   • ພວກເຮົາກວດເບິ່ງການປະກົດຕົວຂອງເຄື່ອງ virtual ຢູ່ໃນຄລາວ. ຕົວຢ່າງ, ຖ້າວັດຖຸ Node ໄດ້ເຂົ້າໄປໃນລັດ NotReady, ທ່ານ​ສາ​ມາດ​ກວດ​ສອບ​ວ່າ​ເຄື່ອງ virtual ມີ​ຢູ່​ໃນ​ທັງ​ຫມົດ​ໃນ​ຜູ້​ໃຫ້​ບໍ​ລິ​ຟັງ​ໂດຍ​ providerID. ຖ້າມັນບໍ່ຢູ່ທີ່ນັ້ນ, ລຶບວັດຖຸອອກ Node, ຊຶ່ງຖ້າບໍ່ດັ່ງນັ້ນຈະຍັງຄົງຢູ່ໃນກຸ່ມຕະຫຼອດໄປ;
2. ເຂດ - ກໍານົດໂດເມນທີ່ລົ້ມເຫລວສໍາລັບວັດຖຸ Node, ເພື່ອໃຫ້ຜູ້ຈັດຕາຕະລາງສາມາດເລືອກ node ສໍາລັບ Pod ຕາມພາກພື້ນແລະເຂດໃນຜູ້ໃຫ້ບໍລິການຟັງ;
3. LoadBalancer - ໃນ​ເວ​ລາ​ທີ່​ການ​ສ້າງ​ວັດ​ຖຸ​ Service ກັບ​ປະ​ເພດ​ LoadBalancer ສ້າງປະເພດຂອງການດຸ່ນດ່ຽງທີ່ຈະນໍາການຈະລາຈອນຈາກພາຍນອກໄປຫາ nodes cluster. ຕົວຢ່າງ, ໃນ Yandex.Cloud ທ່ານສາມາດນໍາໃຊ້ NetworkLoadBalancer и TargetGroup ສໍາລັບຈຸດປະສົງເຫຼົ່ານີ້;
4. ເສັ້ນທາງ – ສ້າງເຄືອຂ່າຍລະຫວ່າງ nodes, ເນື່ອງຈາກວ່າ ອີງຕາມຂໍ້ກໍານົດ Kubernetes, ແຕ່ລະຝັກຕ້ອງມີທີ່ຢູ່ IP ຂອງຕົນເອງ ແລະສາມາດເຂົ້າຫາຝັກອື່ນໄດ້. ສໍາລັບຈຸດປະສົງເຫຼົ່ານີ້, ທ່ານສາມາດນໍາໃຊ້ເຄືອຂ່າຍຊ້ອນກັນ (VXLAN, GENEVE) ຫຼືກໍານົດຕາຕະລາງເສັ້ນທາງໂດຍກົງໃນເຄືອຂ່າຍ virtual ຂອງຜູ້ໃຫ້ບໍລິການຟັງ:

   

5. ປະລິມານ - ອະນຸຍາດໃຫ້ສັ່ງ PV ແບບເຄື່ອນໄຫວໂດຍໃຊ້ PVC ແລະ SC. ໃນເບື້ອງຕົ້ນ, ຫນ້າທີ່ນີ້ແມ່ນສ່ວນຫນຶ່ງຂອງ CCM, ແຕ່ເນື່ອງຈາກຄວາມສັບສົນອັນໃຫຍ່ຫຼວງຂອງມັນ, ມັນໄດ້ຖືກຍ້າຍໄປໂຄງການແຍກຕ່າງຫາກ, Container Storage Interface (CSI). ພວກເຮົາໄດ້ເວົ້າກ່ຽວກັບ CSI ຫຼາຍກວ່າຫນຶ່ງຄັ້ງ wrote ແລະ, ດັ່ງທີ່ໄດ້ກ່າວມາແລ້ວ, ເຖິງແມ່ນວ່າ ປ່ອຍອອກມາ ຄົນຂັບ CSI.

ກ່ອນຫນ້ານີ້, ລະຫັດທັງຫມົດທີ່ພົວພັນກັບ cloud ແມ່ນຕັ້ງຢູ່ໃນບ່ອນເກັບມ້ຽນ Git ຕົ້ນຕໍຂອງໂຄງການ Kubernetes ທີ່ k8s.io/kubernetes/pkg/cloudprovider/providers, ແຕ່ພວກເຂົາຕັດສິນໃຈປະຖິ້ມນີ້ຍ້ອນຄວາມບໍ່ສະດວກໃນການເຮັດວຽກກັບພື້ນຖານລະຫັດຂະຫນາດໃຫຍ່. ການປະຕິບັດເກົ່າທັງຫມົດໄດ້ຖືກຍ້າຍໄປ repository ແຍກຕ່າງຫາກ. ເພື່ອຄວາມສະດວກໃນການສະຫນັບສະຫນູນແລະການພັດທະນາຕໍ່ໄປ, ອົງປະກອບທົ່ວໄປທັງຫມົດໄດ້ຖືກຍ້າຍໄປຍັງ repository ແຍກຕ່າງຫາກ.

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

ເພື່ອຂຽນການປະຕິບັດຂອງທ່ານເອງຂອງ CCM, ມັນພຽງພໍທີ່ຈະປະຕິບັດ ຕ້ອງການການໂຕ້ຕອບ Go.

И ນີ້ແມ່ນສິ່ງທີ່ພວກເຮົາໄດ້ຮັບ.

Реализация

ເຈົ້າມານີ້ໄດ້ແນວໃດ

ພວກເຮົາເລີ່ມຕົ້ນການພັດທະນາ (ຫຼືແທນທີ່ຈະ, ເຖິງແມ່ນວ່າການນໍາໃຊ້) ກັບ ພ້ອມ(!) CCM ສໍາລັບ Yandex.Cloud ຫນຶ່ງປີກ່ອນຫນ້ານີ້.

ຢ່າງໃດກໍຕາມ, ໃນການປະຕິບັດນີ້ພວກເຮົາຂາດ:

• ການກວດສອບຄວາມຖືກຕ້ອງຜ່ານ JWT IAM token;
• ສະຫນັບສະຫນູນການຄວບຄຸມການບໍລິການ.

ຕົກລົງກັບຜູ້ຂຽນ (dlisin) ໃນ Telegram, ພວກເຮົາໄດ້ forked yandex-cloud-controller-manager ແລະເພີ່ມຫນ້າທີ່ຂາດຫາຍໄປ.

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

ໃນປັດຈຸບັນ, CCM ສະຫນັບສະຫນູນການໂຕ້ຕອບດັ່ງຕໍ່ໄປນີ້:

• ຕົວຢ່າງ;
• ເຂດ;
• LoadBalancer.

ໃນອະນາຄົດ, ເມື່ອ Yandex.Cloud ເລີ່ມເຮັດວຽກກັບຄວາມສາມາດຂອງ VPC ຂັ້ນສູງ, ພວກເຮົາຈະເພີ່ມການໂຕ້ຕອບ ເສັ້ນທາງ.

LoadBalancer ເປັນສິ່ງທ້າທາຍຕົ້ນຕໍ

ໃນເບື້ອງຕົ້ນ, ພວກເຮົາໄດ້ພະຍາຍາມ, ເຊັ່ນດຽວກັນກັບການປະຕິບັດ CCM ອື່ນໆ, ເພື່ອສ້າງຄູ່ຂອງ LoadBalancer и TargetGroup ສໍາ​ລັບ​ທຸກ​ຄົນ​ Service ກັບ​ປະ​ເພດ​ LoadBalancer. ຢ່າງໃດກໍຕາມ, Yandex.Cloud ຄົ້ນພົບຂໍ້ຈໍາກັດທີ່ຫນ້າສົນໃຈຫນຶ່ງ: ທ່ານບໍ່ສາມາດໃຊ້ TargetGroups ມີຕັດກັນ Targets (ຄູ່ SubnetID - IpAddress).

ດັ່ງນັ້ນ, ພາຍໃນ CCM ທີ່ສ້າງຂຶ້ນ, ຕົວຄວບຄຸມຖືກເປີດຕົວ, ເຊິ່ງ, ເມື່ອວັດຖຸປ່ຽນແປງ Node ເກັບກໍາຂໍ້ມູນກ່ຽວກັບການໂຕ້ຕອບທັງຫມົດໃນແຕ່ລະເຄື່ອງ virtual, ຈັດກຸ່ມໃຫ້ເຂົາເຈົ້າອີງຕາມການຂອງເຂົາເຈົ້າທີ່ແນ່ນອນ NetworkID, ສ້າງໂດຍ TargetGroup ສຸດ NetworkID, ແລະຍັງຕິດຕາມຄວາມກ່ຽວຂ້ອງ. ຕໍ່ມາ, ເມື່ອສ້າງວັດຖຸ Service ກັບ​ປະ​ເພດ​ LoadBalanacer ພວກເຮົາພຽງແຕ່ຄັດຕິດ pre-ສ້າງ TargetGroup ໃຫມ່ NetworkLoadBalanacer'ຂ້ອຍ.

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

CCM ຮອງຮັບ Kubernetes ເວີຊັນ 1.15 ແລະສູງກວ່າ. ໃນກຸ່ມ, ເພື່ອໃຫ້ມັນເຮັດວຽກ, ມັນຮຽກຮ້ອງໃຫ້ມີທຸງ --cloud-provider=external ຖືກຕັ້ງເປັນ true ສໍາລັບ kube-apiserver, kube-controller-manager, kube-scheduler ແລະ kubelets ທັງໝົດ.

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

ເພື່ອໃຊ້ CCM ເຈົ້າຍັງຕ້ອງການ:

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

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

ຜົນໄດ້ຮັບ

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

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

PS

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

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

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