Kubernetes: ແຫຼ່ງເປີດທຽບກັບຜູ້ຂາຍສະເພາະ

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

ເພື່ອເລີ່ມຕົ້ນດ້ວຍ, ແມ່ນຫຍັງ Kubernetes. ນີ້​ແມ່ນ​ລະ​ບົບ​ສໍາ​ລັບ​ການ​ຄຸ້ມ​ຄອງ​ພາ​ຊະ​ນະ​ໃນ​ຈໍາ​ນວນ​ຫຼາຍ​ຂອງ​ເຈົ້າ​ພາບ​. ຈາກພາສາກະເຣັກ, ໂດຍວິທີທາງການ, ມັນຖືກແປເປັນ "ນັກບິນ" ຫຼື "ຜູ້ຂັບຂີ່." ພັດທະນາໃນເບື້ອງຕົ້ນໂດຍ Google ແລະຫຼັງຈາກນັ້ນບໍລິຈາກເປັນການປະກອບສ່ວນດ້ານເຕັກໂນໂລຢີໃຫ້ແກ່ມູນນິທິ Cloud Native Computing, ເຊິ່ງເປັນອົງການສາກົນທີ່ບໍ່ຫວັງຜົນກໍາໄລທີ່ນໍາເອົານັກພັດທະນາຊັ້ນນໍາຂອງໂລກ, ຜູ້ໃຊ້ສຸດທ້າຍ ແລະຜູ້ໃຫ້ບໍລິການເທກໂນໂລຍີບັນຈຸ.

ຈັດການບັນຈຸຈໍານວນຫຼວງຫຼາຍ

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

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

ໃນເວລາທີ່ພວກເຮົາຕ້ອງການທີ່ຈະດໍາເນີນການຄໍາຮ້ອງສະຫມັກຈາກຕູ້ຄອນເທນເນີ, ຊັ້ນທີ່ຈໍາເປັນແມ່ນ superimposed ກ່ຽວກັບກັນແລະກັນແລະລະບົບໄຟລ໌ overlay ໄດ້ຖືກສ້າງຕັ້ງຂຶ້ນ. ຊັ້ນບັນທຶກຖືກວາງຢູ່ເທິງ, ເຊິ່ງຖືກເອົາອອກເມື່ອກ່ອງບັນຈຸຢຸດ. ນີ້ຮັບປະກັນວ່າໃນເວລາທີ່ container ແລ່ນ, ແອັບພລິເຄຊັນຈະມີສະພາບແວດລ້ອມດຽວກັນ, ເຊິ່ງບໍ່ສາມາດປ່ຽນແປງໄດ້. ນີ້ຮັບປະກັນການແຜ່ພັນຂອງສະພາບແວດລ້ອມໃນ OS ເຈົ້າພາບທີ່ແຕກຕ່າງກັນ. ບໍ່ວ່າຈະເປັນ Ubuntu ຫຼື CentOS, ສະພາບແວດລ້ອມຈະຄືກັນ. ນອກຈາກນັ້ນ, ຕູ້ຄອນເທນເນີຖືກແຍກອອກຈາກໂຮດໂດຍໃຊ້ກົນໄກທີ່ສ້າງຂຶ້ນໃນ Linux kernel. ຄໍາຮ້ອງສະຫມັກໃນຖັງບໍ່ເຫັນໄຟລ໌, ຂະບວນການຂອງເຈົ້າພາບແລະຕູ້ຄອນເທນເນີໃກ້ຄຽງ. ການໂດດດ່ຽວຂອງແອັບພລິເຄຊັນນີ້ຈາກໂຮດ OS ສະຫນອງຊັ້ນຄວາມປອດໄພເພີ່ມເຕີມ.

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

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

ຮູບທີ 1. ການສະແດງແບບແຜນວິທີເຮັດວຽກ Kubernetes

ອັດຕະໂນມັດເຕັມຮູບແບບ

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

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

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

Pros, pros, pros

ຖ້າພວກເຮົາເວົ້າກ່ຽວກັບຄວາມໄດ້ປຽບຂອງ Kubernetes ເປັນເວທີ, ມັນມີຄວາມໄດ້ປຽບທີ່ສໍາຄັນຈາກທັດສະນະຂອງການຄຸ້ມຄອງສະຖາປັດຕະຍະກໍາຈຸລະພາກ.

• ການ​ຄຸ້ມ​ຄອງ replicas ຫຼາຍ​. ສິ່ງທີ່ສໍາຄັນທີ່ສຸດແມ່ນການຄຸ້ມຄອງຕູ້ຄອນເທນເນີໃນທົ່ວ host ຫຼາຍ. ສິ່ງທີ່ສໍາຄັນກວ່ານັ້ນ, ຈັດການການຈໍາລອງຄໍາຮ້ອງສະຫມັກຫຼາຍອັນໃນບັນຈຸເປັນຫນ່ວຍງານດຽວ. ຂໍຂອບໃຈກັບສິ່ງດັ່ງກ່າວ, ວິສະວະກອນບໍ່ຈໍາເປັນຕ້ອງກັງວົນກ່ຽວກັບຖັງແຕ່ລະຄົນ. ຖ້າໜຶ່ງໃນກ່ອງບັນຈຸຂັດຂ້ອງ, Kubernetes ຈະເຫັນອັນນີ້ ແລະຣີສະຕາດມັນອີກຄັ້ງ.
• ເຄືອຂ່າຍກຸ່ມ. Kubernetes ຍັງມີອັນທີ່ເອີ້ນວ່າເຄືອຂ່າຍກຸ່ມທີ່ມີພື້ນທີ່ທີ່ຢູ່ຂອງຕົນເອງ. ຂໍຂອບໃຈກັບນີ້, ແຕ່ລະຝັກມີທີ່ຢູ່ຂອງຕົນເອງ. A subpod ແມ່ນເຂົ້າໃຈວ່າເປັນຫນ່ວຍງານໂຄງສ້າງຂັ້ນຕ່ໍາຂອງກຸ່ມທີ່ບັນຈຸຖືກເປີດຕົວໂດຍກົງ. ນອກຈາກນັ້ນ, Kubernetes ມີຫນ້າທີ່ລວມຕົວດຸ່ນດ່ຽງການໂຫຼດແລະການຄົ້ນພົບການບໍລິການ. ນີ້ອະນຸຍາດໃຫ້ທ່ານສາມາດກໍາຈັດການຈັດການທີ່ຢູ່ IP ດ້ວຍຕົນເອງແລະມອບຫມາຍວຽກງານນີ້ໃຫ້ Kubernetes. ແລະການກວດສຸຂະພາບອັດຕະໂນມັດຈະຊ່ວຍໃຫ້ກວດພົບບັນຫາແລະປ່ຽນເສັ້ນທາງໄປສູ່ການຝັກທີ່ເຮັດວຽກ.
• ການຈັດການການຕັ້ງຄ່າ. ເມື່ອຈັດການຄໍາຮ້ອງສະຫມັກຈໍານວນຫລາຍ, ມັນຍາກທີ່ຈະຈັດການການຕັ້ງຄ່າແອັບພລິເຄຊັນ. ສໍາລັບຈຸດປະສົງນີ້, Kubernetes ມີຊັບພະຍາກອນ ConfigMap ພິເສດ. ພວກມັນອະນຸຍາດໃຫ້ທ່ານເກັບຮັກສາການຕັ້ງຄ່າໄວ້ສູນກາງ ແລະເປີດເຜີຍພວກມັນໃຫ້ກັບຝັກໃນເວລາແລ່ນແອັບພລິເຄຊັນ. ກົນໄກນີ້ອະນຸຍາດໃຫ້ພວກເຮົາຮັບປະກັນຄວາມສອດຄ່ອງຂອງການຕັ້ງຄ່າໃນຢ່າງຫນ້ອຍສິບຫຼືຫນຶ່ງຮ້ອຍຄໍາຮ້ອງສະຫມັກ replicas.
• ປະລິມານຄົງທີ່. ຕູ້ຄອນເທນເນີແມ່ນບໍ່ສາມາດປ່ຽນແປງໄດ້ໂດຍທໍາມະຊາດແລະເມື່ອບັນຈຸຖືກຢຸດ, ຂໍ້ມູນທັງຫມົດທີ່ຂຽນໄວ້ໃນລະບົບໄຟລ໌ຈະຖືກທໍາລາຍ. ແຕ່ບາງແອັບພລິເຄຊັນເກັບຂໍ້ມູນໂດຍກົງໃສ່ແຜ່ນ. ເພື່ອແກ້ໄຂບັນຫານີ້, Kubernetes ມີຟັງຊັນການຈັດການບ່ອນເກັບຂໍ້ມູນດິສກ໌ - ປະລິມານຕໍ່ເນື່ອງ. ກົນໄກນີ້ໃຊ້ການເກັບຮັກສາພາຍນອກສໍາລັບຂໍ້ມູນແລະສາມາດໂອນການເກັບຮັກສາຢ່າງຕໍ່ເນື່ອງ, ຕັນຫຼືໄຟລ໌, ເຂົ້າໄປໃນບັນຈຸ. ການແກ້ໄຂນີ້ຊ່ວຍໃຫ້ທ່ານສາມາດເກັບຂໍ້ມູນແຍກຕ່າງຫາກຈາກຄົນງານ, ເຊິ່ງຊ່ວຍປະຢັດໃຫ້ເຂົາເຈົ້າຖ້າຫາກວ່າພະນັກງານດຽວກັນເຫຼົ່ານີ້ທໍາລາຍ.
• Load Balancer. ເຖິງແມ່ນວ່າໃນ Kubernetes ພວກເຮົາຈັດການຫນ່ວຍງານທີ່ບໍ່ມີຕົວຕົນເຊັ່ນ: Deployment, StatefulSet, ແລະອື່ນໆ, ໃນທີ່ສຸດ containers ດໍາເນີນການຢູ່ໃນເຄື່ອງ virtual ປົກກະຕິຫຼືເຄື່ອງແມ່ຂ່າຍຂອງຮາດແວ. ພວກເຂົາບໍ່ສົມບູນແບບແລະສາມາດລົ້ມລົງໄດ້ທຸກເວລາ. Kubernetes ຈະເຫັນອັນນີ້ ແລະປ່ຽນເສັ້ນທາງການຈາລະຈອນພາຍໃນໄປຫາຕົວແບບອື່ນ. ແຕ່ຈະເຮັດແນວໃດກັບການຈະລາຈອນທີ່ມາຈາກພາຍນອກ? ຖ້າທ່ານພຽງແຕ່ຊີ້ນໍາການຈະລາຈອນໄປຫາຄົນງານຄົນຫນຶ່ງ, ຖ້າມັນຂັດຂ້ອງ, ການບໍລິການຈະບໍ່ສາມາດໃຊ້ໄດ້. ເພື່ອແກ້ໄຂບັນຫານີ້, Kubernetes ມີບໍລິການເຊັ່ນ Load Balancer. ພວກມັນຖືກອອກແບບມາເພື່ອປັບຄ່າຕົວດຸ່ນດ່ຽງຄລາວພາຍນອກໂດຍອັດຕະໂນມັດສຳລັບພະນັກງານທັງໝົດໃນກຸ່ມ. ຕົວດຸ່ນດ່ຽງພາຍນອກນີ້ຊີ້ນໍາການຈະລາຈອນພາຍນອກໄປຫາຜູ້ອອກແຮງງານແລະຕິດຕາມສະຖານະພາບຂອງເຂົາເຈົ້າເອງ. ຖ້າຄົນງານໜຶ່ງຄົນ ຫຼືຫຼາຍກວ່ານັ້ນບໍ່ສາມາດໃຊ້ໄດ້, ການຈະລາຈອນຈະຖືກໂອນໄປຫາຜູ້ອື່ນ. ນີ້ອະນຸຍາດໃຫ້ທ່ານສ້າງການບໍລິການທີ່ມີໃຫ້ສູງໂດຍໃຊ້ Kubernetes.

Kubernetes ໃຊ້ໄດ້ດີທີ່ສຸດເມື່ອແລ່ນສະຖາປັດຕະຍະກຳບໍລິການຈຸລະພາກ. ມັນເປັນໄປໄດ້ທີ່ຈະປະຕິບັດລະບົບເຂົ້າໄປໃນສະຖາປັດຕະຍະກໍາຄລາສສິກ, ແຕ່ວ່າມັນບໍ່ມີຈຸດຫມາຍ. ຖ້າແອັບພລິເຄຊັນບໍ່ສາມາດແລ່ນໄດ້ກັບຫຼາຍ replicas, ມັນແຕກຕ່າງກັນແນວໃດ - ໃນ Kubernetes ຫຼືບໍ່?

ແຫຼ່ງເປີດ Kubernetes

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

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

ຮູບທີ 2. ສະຖາປັດຕະຍະກໍາ k8s

Kubernetes ຈາກຜູ້ຂາຍ

ການເຊື່ອມໂຍງກັບຜູ້ໃຫ້ບໍລິການຄລາວໃຫ້ສອງທາງເລືອກ:

• ກ່ອນອື່ນ ໝົດ, ບຸກຄົນພຽງແຕ່ສາມາດຄລິກໃສ່ປຸ່ມ "ສ້າງກຸ່ມ" ແລະໄດ້ຮັບກຸ່ມທີ່ຖືກຕັ້ງຄ່າແລ້ວແລະພ້ອມທີ່ຈະໃຊ້.
• ອັນທີສອງ, ຜູ້ຂາຍເອງຕິດຕັ້ງ cluster ແລະຕັ້ງຄ່າການເຊື່ອມໂຍງກັບຟັງ.

ມັນເກີດຂຶ້ນແນວໃດຢູ່ທີ່ນີ້. ວິສະວະກອນທີ່ເລີ່ມຕົ້ນ cluster ກໍານົດຈໍານວນຄົນງານທີ່ລາວຕ້ອງການແລະມີພາລາມິເຕີໃດ (ຕົວຢ່າງ, ພະນັກງານ 5 ຄົນ, ແຕ່ລະຄົນມີ 10 CPU, 16 GB ຂອງ RAM ແລະ, ເວົ້າວ່າ, 100 GB ຂອງແຜ່ນ). ຫຼັງຈາກນັ້ນ, ມັນສາມາດເຂົ້າເຖິງກຸ່ມທີ່ຖືກສ້າງຕັ້ງຂຶ້ນແລ້ວ. ໃນກໍລະນີນີ້, ຜູ້ອອກແຮງງານທີ່ໂຫລດໄດ້ຖືກໂອນໃຫ້ລູກຄ້າຢ່າງສົມບູນ, ແຕ່ຍົນທີ່ຄຸ້ມຄອງທັງຫມົດຍັງຄົງຢູ່ພາຍໃຕ້ຄວາມຮັບຜິດຊອບຂອງຜູ້ຂາຍ (ຖ້າໃຫ້ບໍລິການຕາມຮູບແບບການບໍລິການທີ່ຄຸ້ມຄອງ).

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

ຮູບ 3. ຕົວຢ່າງຂອງກຸ່ມ Kubernetes ຈາກຜູ້ໃຫ້ບໍລິການຄລາວ

ສິ່ງທີ່ຈະເລືອກເອົາ: ແຫຼ່ງເປີດຫຼືຜູ້ຂາຍ

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

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

ບົດຄວາມໄດ້ຖືກກະກຽມໂດຍ Dmitry Krasnov, ສະຖາປະນິກຊັ້ນນໍາຂອງການບໍລິການ Containerum ຂອງຜູ້ໃຫ້ບໍລິການ #CloudMTS

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