K8S Multicluster Journey

Hey Habr!

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

ເພື່ອເລີ່ມຕົ້ນດ້ວຍ, ພວກເຮົາສະເຫນີໃຫ້ທ່ານມີຕົວເລກບາງຢ່າງສໍາລັບຄວາມເຂົ້າໃຈດີຂຶ້ນກ່ຽວກັບສິ່ງທີ່ຈະໄດ້ຮັບການປຶກສາຫາລື:

• ພະແນກພັດທະນາຂອງພວກເຮົາປະກອບດ້ວຍ 100+ ຄົນ, ລວມທັງຫຼາຍກວ່າ 10 ທີມງານທີ່ແຕກຕ່າງກັນທີ່ມີຂະບວນການ QA, DevOps ແລະ Scrum ທີ່ພຽງພໍດ້ວຍຕົນເອງ. ການພັດທະນາ stack - Python, PHP, C++, Java ແລະ Golang. 
• ຂະຫນາດຂອງການທົດສອບແລະສະພາບແວດລ້ອມການຜະລິດແມ່ນປະມານ 2000 ບັນຈຸໃນແຕ່ລະ. ພວກເຂົາກໍາລັງແລ່ນ Rancher v1.6 ຢູ່ໃນ virtualization ຂອງຕົນເອງແລະພາຍໃຕ້ VMware. 

ແຮງກະຕຸ້ນ

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

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

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

ຂັ້ນຕອນທໍາອິດ

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

ຕໍ່ໄປແມ່ນຄໍາຖາມຂອງການເລືອກເຄື່ອງມືສໍາລັບການສ້າງກຸ່ມ. ພວກເຮົາປຽບທຽບວິທີແກ້ໄຂທີ່ນິຍົມຫຼາຍທີ່ສຸດ: kops, kubespray, kubeadm.

ເພື່ອເລີ່ມຕົ້ນ, kubeadm ເບິ່ງຄືວ່າພວກເຮົາເປັນເສັ້ນທາງທີ່ສັບສົນເກີນໄປ, ຄືກັບນັກປະດິດຂອງ "ລົດຖີບ", ແລະ kops ບໍ່ມີຄວາມຍືດຫຍຸ່ນພຽງພໍ.

ແລະຜູ້ຊະນະແມ່ນ:

ພວກເຮົາໄດ້ເລີ່ມທົດລອງກັບ virtualization ຂອງພວກເຮົາເອງແລະ AWS, ພະຍາຍາມສ້າງບາງສິ່ງບາງຢ່າງທີ່ຄ້າຍຄືກັນກັບຮູບແບບການຄຸ້ມຄອງຊັບພະຍາກອນທີ່ຜ່ານມາຂອງພວກເຮົາ, ບ່ອນທີ່ທຸກຄົນແບ່ງປັນ "ກຸ່ມ." ແລະໃນປັດຈຸບັນພວກເຮົາມີກຸ່ມທໍາອິດຂອງພວກເຮົາຂອງ 10 ເຄື່ອງ virtual ຂະຫນາດນ້ອຍ, ສອງສາມເຄື່ອງທີ່ຕັ້ງຢູ່ໃນ AWS. ພວກເຮົາເລີ່ມພະຍາຍາມຍ້າຍທີມຢູ່ທີ່ນັ້ນ, ທຸກຢ່າງເບິ່ງຄືວ່າ "ດີ", ແລະເລື່ອງສາມາດສໍາເລັດ, ແຕ່ ...

ບັນຫາທໍາອິດ

Ansible ແມ່ນສິ່ງທີ່ kubespray ຖືກສ້າງຂຶ້ນ, ມັນບໍ່ແມ່ນເຄື່ອງມືທີ່ອະນຸຍາດໃຫ້ທ່ານປະຕິບັດຕາມ IaC: ເມື່ອການມອບຫມາຍ / decommissioning nodes, ບາງສິ່ງບາງຢ່າງຜິດພາດຢ່າງຕໍ່ເນື່ອງແລະບາງປະເພດຂອງການແຊກແຊງແມ່ນຕ້ອງການ, ແລະໃນເວລາທີ່ໃຊ້ OSes ທີ່ແຕກຕ່າງກັນ, playbook ປະຕິບັດແຕກຕ່າງກັນ. . ເມື່ອຈໍານວນຂອງທີມງານແລະ nodes ໃນ cluster ເພີ່ມຂຶ້ນ, ພວກເຮົາເລີ່ມສັງເກດເຫັນວ່າ playbook ໃຊ້ເວລາດົນກວ່າແລະຍາວກວ່າທີ່ຈະສໍາເລັດ, ແລະຜົນໄດ້ຮັບ, ບັນທຶກຂອງພວກເຮົາແມ່ນ 3,5 ຊົ່ວໂມງ, ຈະເປັນແນວໃດກ່ຽວກັບຂອງທ່ານ? 🙂

ແລະມັນເບິ່ງຄືວ່າ kubespray ແມ່ນພຽງແຕ່ Ansible, ແລະທຸກສິ່ງທຸກຢ່າງຈະແຈ້ງຢູ່ glance ທໍາອິດ, ແຕ່:

ໃນຕອນເລີ່ມຕົ້ນຂອງການເດີນທາງ, ວຽກງານແມ່ນເພື່ອເປີດຕົວຄວາມສາມາດພຽງແຕ່ໃນ AWS ແລະໃນ virtualization, ແຕ່ຫຼັງຈາກນັ້ນ, ເລື້ອຍໆ, ຄວາມຕ້ອງການໄດ້ປ່ຽນແປງ.
 


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

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

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

ວິທີການເປັນ?

ໂດຍຄໍານຶງເຖິງຂ້າງເທິງແລະຄວາມປາດຖະຫນາຂອງທີມງານທີ່ຈະເປັນເອກະລາດຫຼາຍ, ພວກເຮົາໄດ້ສະຫຼຸບງ່າຍໆ: ຫນຶ່ງທີມ - ຫນຶ່ງກຸ່ມ. 

ດັ່ງນັ້ນພວກເຮົາໄດ້ຮັບອັນທີສອງ:

ແລະຫຼັງຈາກນັ້ນກຸ່ມທີສາມ: 

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

Kubernetes ເຕັມຈະມາ! ນີ້ແມ່ນບາງປະເພດຂອງ MultiKubernetes, ມັນ turns ອອກ. 

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

ບາງເວລາໄດ້ຜ່ານໄປນັບຕັ້ງແຕ່ການເລີ່ມຕົ້ນຂອງການເດີນທາງຂອງພວກເຮົາໃນໂລກ Kubernetes, ແລະພວກເຮົາໄດ້ຕັດສິນໃຈທົບທວນຄືນວິທີແກ້ໄຂທີ່ມີຢູ່. ມັນໄດ້ຫັນອອກວ່າມັນມີຢູ່ແລ້ວໃນຕະຫຼາດ - Rancher 2.2.

ໃນຂັ້ນຕອນທໍາອິດຂອງການຄົ້ນຄວ້າຂອງພວກເຮົາ, Rancher Labs ໄດ້ເຮັດການເປີດຕົວຄັ້ງທໍາອິດຂອງຮຸ່ນ 2, ແຕ່ເຖິງແມ່ນວ່າມັນສາມາດຖືກຍົກຂຶ້ນມາຢ່າງໄວວາໂດຍການເປີດຕົວຕູ້ຄອນເທນເນີໂດຍບໍ່ມີຕົວກໍານົດການຈາກພາຍນອກທີ່ມີສອງສາມຕົວກໍານົດການຫຼືໃຊ້ HELM Chart ຢ່າງເປັນທາງການ, ມັນເບິ່ງຄືວ່າເປັນເລື່ອງທີ່ລ້າສະໄຫມ. ກັບພວກເຮົາ, ແລະພວກເຮົາບໍ່ຮູ້ວ່າພວກເຮົາສາມາດອີງໃສ່ການຕັດສິນໃຈນີ້ວ່າມັນຈະຖືກພັດທະນາຫຼືຖືກປະຖິ້ມຢ່າງໄວວາ. ກຸ່ມ = ການຄລິກ paradigm ໃນ UI ຕົວຂອງມັນເອງຍັງບໍ່ເຫມາະສົມກັບພວກເຮົາ, ແລະພວກເຮົາບໍ່ຕ້ອງການທີ່ຈະຜູກມັດກັບ RKE, ເນື່ອງຈາກວ່າມັນເປັນເຄື່ອງມືທີ່ສຸມໃສ່ແຄບ. 

ຮຸ່ນ Rancher 2.2 ແລ້ວມີຮູບລັກສະນະທີ່ເຮັດວຽກໄດ້ຫຼາຍກວ່າເກົ່າແລະ, ພ້ອມກັບຕົວທີ່ຜ່ານມາ, ມີຄຸນລັກສະນະທີ່ຫນ້າສົນໃຈຫຼາຍອອກຈາກກ່ອງ, ເຊັ່ນ: ການເຊື່ອມໂຍງກັບຜູ້ໃຫ້ບໍລິການພາຍນອກຈໍານວນຫຼາຍ, ຈຸດດຽວຂອງການແຈກຢາຍສິດແລະໄຟລ໌ kubeconfig, ເປີດຕົວ kubectl. ຮູບພາບທີ່ມີສິດທິຂອງທ່ານໃນ UI, nested namespaces aka ໂຄງການ. 

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

ເກີດ​ຫຍັງ​ຂຶ້ນ

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

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

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

ບົດຄວາມໄດ້ຖືກຂຽນໂດຍ A. Antipov, A. Ganush, ວິສະວະກອນເວທີ. 

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