Kubernetes ຜະຈົນໄພ Dailymotion: ການສ້າງໂຄງສ້າງພື້ນຖານໃນເມຄ + ໃນສະຖານທີ່

ຫມາຍ​ເຫດ​. ແປ.: Dailymotion ເປັນໜຶ່ງໃນບໍລິການໂຮດວິດີໂອທີ່ໃຫຍ່ທີ່ສຸດຂອງໂລກ ແລະເພາະສະນັ້ນຈຶ່ງເປັນຜູ້ໃຊ້ Kubernetes ທີ່ໂດດເດັ່ນ. ໃນເອກະສານນີ້, ສະຖາປະນິກລະບົບ David Donchez ແບ່ງປັນຜົນໄດ້ຮັບຂອງການສ້າງແພລະຕະຟອມການຜະລິດຂອງບໍລິສັດໂດຍອີງໃສ່ K8s, ເຊິ່ງໄດ້ເລີ່ມຕົ້ນດ້ວຍການຕິດຕັ້ງເມຄໃນ GKE ແລະສິ້ນສຸດລົງເປັນການແກ້ໄຂແບບປະສົມ, ເຊິ່ງອະນຸຍາດໃຫ້ເວລາຕອບສະຫນອງທີ່ດີກວ່າແລະປະຫຍັດຄ່າໃຊ້ຈ່າຍໃນໂຄງສ້າງພື້ນຖານ.

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

ເປັນຫຍັງມັນຈຶ່ງຄຸ້ມຄ່າໃນການສ້າງເວທີຂອງທ່ານເອງໂດຍອີງໃສ່ Kubernetes?

API ລະດັບການຜະລິດໃນເວລາບໍ່ໃຊ້ Google Cloud

ລະດູຮ້ອນ 2016

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

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

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

ເປັນຫຍັງທ່ານເລືອກ GKE?

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

ກຸ່ມ GKE ໃນ Dailymotion

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

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

ນອກຈາກນັ້ນ, ການບໍລິການເຄືອຂ່າຍແລະການດຸ່ນດ່ຽງການໂຫຼດຈາກ Google Cloud ເຮັດວຽກທີ່ດີເລີດ. ພວກເຂົາພຽງແຕ່ອະນຸຍາດໃຫ້ທ່ານໃຊ້ທີ່ຢູ່ IP ສາທາລະນະທີ່ຕົນເອງມັກຈາກແຕ່ລະພາກພື້ນ, ແລະໂປໂຕຄອນ BGP ທີ່ປະເສີດຈະດູແລສ່ວນທີ່ເຫຼືອ (i. e. ການປ່ຽນເສັ້ນທາງຜູ້ໃຊ້ໄປຫາກຸ່ມທີ່ໃກ້ທີ່ສຸດ). ແນ່ນອນ, ໃນກໍລະນີຂອງຄວາມລົ້ມເຫຼວ, ການຈະລາຈອນຈະໄປເຂດອື່ນໂດຍອັດຕະໂນມັດໂດຍບໍ່ມີການແຊກແຊງຂອງມະນຸດ.

ຕິດຕາມການດຸ່ນດ່ຽງການໂຫຼດຂອງ Google

ເວທີຂອງພວກເຮົາຍັງໃຊ້ GPUs ຢ່າງຮຸນແຮງ. Google Cloud ອະນຸຍາດໃຫ້ທ່ານໃຊ້ພວກມັນຢ່າງມີປະສິດທິພາບໂດຍກົງໃນກຸ່ມ Kubernetes.

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

ດັ່ງນັ້ນ, ພວກເຮົາສາມາດເລີ່ມຕົ້ນໄດ້ຮັບການຈະລາຈອນການຜະລິດໃນໂຄງສ້າງພື້ນຖານຂອງ Google Cloud ພຽງແຕ່ 6 ເດືອນຫຼັງຈາກການເລີ່ມຕົ້ນຂອງການເຮັດວຽກ.

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

ການເປີດຕົວແພລະຕະຟອມ Orchestration ຕູ້ຄອນເທນເນີໃນທ້ອງຖິ່ນ Dailymotion

ລະດູໃບໄມ້ຫຼົ່ນ 2016

ໃນເງື່ອນໄຂໃນເວລາທີ່ stack ທັງຫມົດແມ່ນກຽມພ້ອມສໍາລັບການຜະລິດ, ແລະເຮັດວຽກຢູ່ໃນ API ສືບຕໍ່, ມັນແມ່ນເວລາທີ່ຈະສຸມໃສ່ກຸ່ມພາກພື້ນ.

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

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

ພາກສ່ວນເຄືອຂ່າຍ

ເຄືອຂ່າຍຂອງພວກເຮົາຖືກເຊື່ອມຕໍ່ຢ່າງສົມບູນ. ແຕ່ລະເຄື່ອງແມ່ຂ່າຍໂຄສະນາ IP ຂອງມັນຢູ່ໃນເຄືອຂ່າຍໂດຍໃຊ້ Exabgp. ພວກເຮົາໄດ້ປຽບທຽບ plugins ເຄືອຂ່າຍຈໍານວນຫນຶ່ງແລະອັນດຽວທີ່ພໍໃຈກັບຄວາມຕ້ອງການທັງຫມົດ (ເນື່ອງຈາກວິທີການ L3 ຖືກນໍາໃຊ້) ແມ່ນ Calico. ມັນ ເໝາະ ສົມກັບຮູບແບບໂຄງສ້າງເຄືອຂ່າຍທີ່ມີຢູ່ແລ້ວ.

ເນື່ອງຈາກພວກເຮົາຕ້ອງການໃຊ້ອົງປະກອບພື້ນຖານໂຄງລ່າງທັງຫມົດ, ສິ່ງທໍາອິດທີ່ພວກເຮົາຕ້ອງເຮັດຄືການຄິດໄລ່ຜົນປະໂຫຍດຂອງເຄືອຂ່າຍທີ່ປູກຢູ່ໃນບ້ານຂອງພວກເຮົາ (ໃຊ້ໃນເຄື່ອງແມ່ຂ່າຍທັງຫມົດ): ໃຊ້ມັນເພື່ອໂຄສະນາຂອບເຂດທີ່ຢູ່ IP ໃນເຄືອຂ່າຍກັບ Kubernetes nodes. ພວກເຮົາອະນຸຍາດໃຫ້ Calico ມອບຫມາຍທີ່ຢູ່ IP ໃຫ້ກັບ pods, ແຕ່ບໍ່ໄດ້ແລະຍັງບໍ່ໃຊ້ມັນສໍາລັບກອງປະຊຸມ BGP ໃນອຸປະກອນເຄືອຂ່າຍ. ໃນຄວາມເປັນຈິງ, ເສັ້ນທາງແມ່ນຈັດການໂດຍ Exabgp, ເຊິ່ງໂຄສະນາເຄືອຂ່າຍຍ່ອຍທີ່ໃຊ້ໂດຍ Calico. ນີ້ອະນຸຍາດໃຫ້ພວກເຮົາສາມາດບັນລຸ pod ໃດຈາກເຄືອຂ່າຍພາຍໃນ (ແລະໂດຍສະເພາະຈາກ load balancers).

ພວກເຮົາຈັດການການຈະລາຈອນຂາເຂົ້າແນວໃດ

ເພື່ອປ່ຽນເສັ້ນທາງການຮ້ອງຂໍຂາເຂົ້າໄປຫາບໍລິການທີ່ຕ້ອງການ, ມັນໄດ້ຖືກຕັດສິນໃຈທີ່ຈະໃຊ້ Ingress Controller ເນື່ອງຈາກການເຊື່ອມໂຍງກັບຊັບພະຍາກອນ ingress Kubernetes.

ສາມປີກ່ອນ, nginx-ingress-controller ແມ່ນຕົວຄວບຄຸມທີ່ໃຫຍ່ທີ່ສຸດ: Nginx ໄດ້ປະມານເວລາດົນນານແລະເປັນທີ່ຮູ້ຈັກສໍາລັບຄວາມຫມັ້ນຄົງແລະການປະຕິບັດຂອງມັນ.

ໃນລະບົບຂອງພວກເຮົາ, ພວກເຮົາໄດ້ຕັດສິນໃຈວາງຕົວຄວບຄຸມໃສ່ເຄື່ອງແມ່ຂ່າຍແຜ່ນໃບຄ້າຍຄື 10-Gigabit ທີ່ອຸທິດຕົນ. ແຕ່ລະຕົວຄວບຄຸມໄດ້ຖືກເຊື່ອມຕໍ່ກັບຈຸດສິ້ນສຸດ kube-apiserver ຂອງກຸ່ມທີ່ສອດຄ້ອງກັນ. ເຊີບເວີເຫຼົ່ານີ້ຍັງໃຊ້ Exabgp ເພື່ອໂຄສະນາທີ່ຢູ່ IP ສາທາລະນະ ຫຼືສ່ວນຕົວ. topology ເຄືອຂ່າຍຂອງພວກເຮົາອະນຸຍາດໃຫ້ພວກເຮົາໃຊ້ BGP ຈາກຕົວຄວບຄຸມເຫຼົ່ານີ້ເພື່ອສົ່ງການຈະລາຈອນທັງຫມົດໂດຍກົງໄປຫາ pods ໂດຍບໍ່ຕ້ອງໃຊ້ການບໍລິການເຊັ່ນ NodePort. ວິທີການນີ້ຊ່ວຍຫຼີກເວັ້ນການຈາລະຈອນຕາມລວງນອນລະຫວ່າງ nodes ແລະປັບປຸງປະສິດທິພາບ.

ການເຄື່ອນໄຫວການຈະລາຈອນຈາກອິນເຕີເນັດໄປຫາຝັກ

ໃນປັດຈຸບັນທີ່ພວກເຮົາເຂົ້າໃຈແພລະຕະຟອມປະສົມຂອງພວກເຮົາ, ພວກເຮົາສາມາດເຈາະເລິກເຂົ້າໄປໃນຂະບວນການການເຄື່ອນຍ້າຍການຈະລາຈອນຂອງມັນເອງ.

ການເຄື່ອນຍ້າຍຂອງການຈະລາຈອນຈາກ Google Cloud ໄປສູ່ໂຄງສ້າງພື້ນຖານ Dailymotion

ລະດູໃບໄມ້ຫຼົ່ນ 2018

ຫຼັງຈາກເກືອບສອງປີຂອງການກໍ່ສ້າງ, ການທົດສອບ, ແລະປັບ, ໃນທີ່ສຸດພວກເຮົາມີ stack Kubernetes ເຕັມທີ່ພ້ອມທີ່ຈະຍອມຮັບການຈະລາຈອນບາງຢ່າງ.

ຍຸດທະສາດການສ້າງເສັ້ນທາງໃນປະຈຸບັນແມ່ນຂ້ອນຂ້າງງ່າຍດາຍ, ແຕ່ພຽງພໍເພື່ອຕອບສະຫນອງຄວາມຕ້ອງການ. ນອກເຫນືອຈາກ IPs ສາທາລະນະ (ໃນ Google Cloud ແລະ Dailymotion), AWS Route 53 ຖືກນໍາໃຊ້ເພື່ອກໍານົດນະໂຍບາຍແລະໂອນຜູ້ໃຊ້ໄປຫາກຸ່ມທີ່ເລືອກຂອງພວກເຮົາ.

ຕົວຢ່າງນະໂຍບາຍກໍານົດເສັ້ນທາງໂດຍໃຊ້ເສັ້ນທາງ 53

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

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

ເນື່ອງຈາກວ່າກຸ່ມ GKE ຂອງພວກເຮົາຖືກຕັ້ງຄ່າໃຫ້ຂະຫນາດອັດຕະໂນມັດໂດຍໃຊ້ Custom Metrics, ພວກມັນຂະຫຍາຍຂຶ້ນ / ລົງໂດຍອີງໃສ່ການຈະລາຈອນທີ່ເຂົ້າມາ.

ໃນຮູບແບບປົກກະຕິ, ການຈະລາຈອນໃນພາກພື້ນທັງຫມົດແມ່ນມຸ້ງໄປຫາກຸ່ມທ້ອງຖິ່ນ, ແລະ GKE ເຮັດຫນ້າທີ່ເປັນສະຫງວນໃນກໍລະນີທີ່ມີບັນຫາ (ການກວດສອບສຸຂະພາບແມ່ນດໍາເນີນໂດຍເສັ້ນທາງ 53).

...

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

PS ຈາກນັກແປ

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

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

• «ການປ່ຽນແປງ Tinder ໄປ Kubernetes".
• «Kubernetes ເລື່ອງຄວາມສໍາເລັດໃນການຜະລິດ. ສ່ວນທີ 10: ເຫດ"
• «Kubernetes ເລື່ອງຄວາມສໍາເລັດໃນການຜະລິດ. ສ່ວນທີ 9: ກຸ່ມ CERN ແລະ 210 K8s"
• «Kubernetes ເລື່ອງຄວາມສໍາເລັດໃນການຜະລິດ. ສ່ວນທີ 8: Huawei"
• «Kubernetes ເລື່ອງຄວາມສໍາເລັດໃນການຜະລິດ. ສ່ວນທີ 7: BlackRock"
• «Kubernetes ເລື່ອງຄວາມສໍາເລັດໃນການຜະລິດ. ສ່ວນທີ 6: BlaBlaCar"
• «Kubernetes ເລື່ອງຄວາມສໍາເລັດໃນການຜະລິດ. ສ່ວນທີ 5: ທະນາຄານດິຈິຕອນ Monzo"
• «Kubernetes ເລື່ອງຄວາມສໍາເລັດໃນການຜະລິດ. ສ່ວນທີ 4: SoundCloud (ໂດຍ Prometheus)"
• «Kubernetes ເລື່ອງຄວາມສໍາເລັດໃນການຜະລິດ. ສ່ວນທີ 3: GitHub"
• «Kubernetes ເລື່ອງຄວາມສໍາເລັດໃນການຜະລິດ. ສ່ວນທີ 2: Concur ແລະ SAP"
• «Kubernetes ເລື່ອງຄວາມສໍາເລັດໃນການຜະລິດ. ສ່ວນທີ 1: 4200 hearth ແລະ TessMaster ຈາກ eBay".

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