ວິທີການຍ້າຍໄປຫາຄລາວໃນສອງຊົ່ວໂມງຂໍຂອບໃຈກັບ Kubernetes ແລະອັດຕະໂນມັດ

ບໍລິສັດ URUS ພະຍາຍາມ Kubernetes ໃນຮູບແບບຕ່າງໆ: ການຕິດຕັ້ງເອກະລາດໃນໂລຫະເປົ່າ, ໃນ Google Cloud, ແລະຫຼັງຈາກນັ້ນໄດ້ໂອນແພລະຕະຟອມຂອງຕົນໄປສູ່ເມຄ໌ Mail.ru Cloud Solutions (MCS). Igor Shishkin ບອກວິທີທີ່ພວກເຂົາເລືອກຜູ້ໃຫ້ບໍລິການຟັງໃຫມ່ແລະວິທີການທີ່ເຂົາເຈົ້າຈັດການກັບມັນໃນບັນທຶກສອງຊົ່ວໂມງ (t3ran), ຜູ້ບໍລິຫານລະບົບອາວຸໂສຢູ່ URUS.

URUS ເຮັດຫຍັງ?

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

URUS ເຮັດວຽກແນວໃດຈາກພາຍໃນ

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

ເສັ້ນສະແດງການຕິດຕາມກວດກາຄວາມເຂັ້ມຂຸ້ນຂອງ H2S ສະແດງໃຫ້ເຫັນການປ່ອຍອາຍພິດໃນເວລາກາງຄືນປົກກະຕິຈາກພືດທີ່ຢູ່ໃກ້ຄຽງ

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

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

ໃນຂະຫນານ, ການບໍລິການອື່ນໆຈໍານວນຫຼາຍດໍາເນີນການຢູ່ໃນເວທີຂອງພວກເຮົາ, ແຕ່ພວກເຂົາເຈົ້າສ່ວນໃຫຍ່ແມ່ນມີລັກສະນະການບໍລິການ. ຕົວຢ່າງ, ການບໍລິການແຈ້ງການສົ່ງການແຈ້ງເຕືອນໃຫ້ລູກຄ້າຖ້າຕົວກໍານົດການຕິດຕາມກວດກາໃດໆ (ຕົວຢ່າງ, ເນື້ອໃນ CO2) ເກີນມູນຄ່າທີ່ອະນຸຍາດ.

ພວກເຮົາເກັບຂໍ້ມູນແນວໃດ. ເລື່ອງຂອງ Kubernetes ກ່ຽວກັບໂລຫະເປົ່າ

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

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

ໃນຂະຫນານກັບການຊໍານິຊໍານານ Kubernetes ເອງ, ພວກເຮົາຍັງໄດ້ສຶກສາວິທີການເກັບຮັກສາຂໍ້ມູນ, ໃນຂະນະທີ່ພວກເຮົາເກັບຮັກສາການເກັບຮັກສາທັງຫມົດຂອງພວກເຮົາໃນ Kubernetes ໃນຮາດແວຂອງພວກເຮົາເອງ, ພວກເຮົາໄດ້ຮັບຄວາມຊໍານານທີ່ດີເລີດ. ທຸກສິ່ງທຸກຢ່າງທີ່ພວກເຮົາເຄີຍອາໄສຢູ່ໃນ Kubernetes: ພື້ນທີ່ເກັບຂໍ້ມູນຂອງລັດ, ລະບົບການຕິດຕາມ, CI/CD. Kubernetes ໄດ້ກາຍເປັນແພລະຕະຟອມທັງໝົດໃນອັນດຽວສຳລັບພວກເຮົາ.

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

ການປ່ຽນໄປໃຊ້ Google Cloud Platform ເປັນການແກ້ໄຂຊົ່ວຄາວ

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

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

ພວກເຮົາເຫັນການບໍລິການຄລາວທີ່ເໝາະສົມແນວໃດ

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

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

ໃນເວລານັ້ນ, ມີຜູ້ໃຫ້ບໍລິການ Kubernetes aaS ຈໍານວນຫນ້ອຍໃນລັດເຊຍ, ແລະໃນເວລາທີ່ເລືອກຜູ້ໃຫ້ບໍລິການ, ມັນເປັນສິ່ງສໍາຄັນສໍາລັບພວກເຮົາທີ່ຈະບໍ່ປະນີປະນອມຄວາມສໍາຄັນຂອງພວກເຮົາ. ທີມງານ Mail.ru Cloud Solutions, ເຊິ່ງພວກເຮົາໄດ້ເລີ່ມເຮັດວຽກ ແລະຍັງຮ່ວມມືກັນຢູ່, ໄດ້ສະໜອງການບໍລິການແບບອັດຕະໂນມັດເຕັມຮູບແບບໃຫ້ກັບພວກເຮົາ, ດ້ວຍການຮອງຮັບ API ແລະແຜງຄວບຄຸມທີ່ສະດວກທີ່ປະກອບມີ Horizon - ດ້ວຍມັນພວກເຮົາສາມາດເພີ່ມຈໍານວນໂຫນດທີ່ຕົນເອງມັກໄດ້ຢ່າງວ່ອງໄວ.

ພວກເຮົາຈັດການແນວໃດເພື່ອຍ້າຍໄປຫາ MCS ໃນສອງຊົ່ວໂມງ

ໃນການເຄື່ອນໄຫວດັ່ງກ່າວ, ຫຼາຍໆບໍລິສັດປະສົບກັບຄວາມຫຍຸ້ງຍາກແລະຄວາມຫຍຸ້ງຍາກ, ແຕ່ໃນກໍລະນີຂອງພວກເຮົາບໍ່ມີ. ພວກເຮົາໂຊກດີ: ເນື່ອງຈາກພວກເຮົາໄດ້ເຮັດວຽກຢູ່ Kubernetes ກ່ອນການເຄື່ອນຍ້າຍເລີ່ມຕົ້ນ, ພວກເຮົາພຽງແຕ່ແກ້ໄຂສາມໄຟລ໌ ແລະເປີດບໍລິການຂອງພວກເຮົາໃນເວທີຄລາວໃໝ່, MCS. ຂ້າພະເຈົ້າຂໍເຕືອນທ່ານວ່າໃນເວລານັ້ນໃນທີ່ສຸດພວກເຮົາໄດ້ປະຖິ້ມໂລຫະເປົ່າແລະອາໄສຢູ່ໃນ Google Cloud Platform. ດັ່ງນັ້ນ, ການເຄື່ອນຍ້າຍຕົວມັນເອງໃຊ້ເວລາບໍ່ເກີນສອງຊົ່ວໂມງ, ບວກກັບເວລາເພີ່ມເຕີມເລັກນ້ອຍ (ປະມານຫນຶ່ງຊົ່ວໂມງ) ແມ່ນໃຊ້ເວລາໃນການຄັດລອກຂໍ້ມູນຈາກອຸປະກອນຂອງພວກເຮົາ. ກັບຄືນໄປບ່ອນນັ້ນພວກເຮົາໄດ້ໃຊ້ Spinnaker (ບໍລິການ CD ຫຼາຍຄລາວເພື່ອສະຫນອງການຈັດສົ່ງຢ່າງຕໍ່ເນື່ອງ). ພວກເຮົາຍັງໄດ້ເພີ່ມມັນເຂົ້າໄປໃນກຸ່ມໃຫມ່ຢ່າງໄວວາ ແລະສືບຕໍ່ເຮັດວຽກຕາມປົກກະຕິ.

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

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

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

ພວກເຮົາເຫັນວິທີການເຮັດວຽກກັບຄລາວໃນອະນາຄົດ

ໃນປັດຈຸບັນວຽກງານຂອງພວກເຮົາແມ່ນຕິດພັນກັບ Kubernetes ຢ່າງໃກ້ຊິດ, ແລະມັນເຫມາະສົມກັບພວກເຮົາຢ່າງສົມບູນຈາກທັດສະນະຂອງວຽກງານພື້ນຖານໂຄງລ່າງ. ດັ່ງນັ້ນ, ພວກເຮົາບໍ່ໄດ້ວາງແຜນທີ່ຈະຍ້າຍອອກໄປຈາກບ່ອນໃດບ່ອນໜຶ່ງ, ເຖິງແມ່ນວ່າພວກເຮົາກຳລັງຈະແນະນຳການປະຕິບັດ ແລະ ການບໍລິການໃໝ່ໆຢ່າງຕໍ່ເນື່ອງເພື່ອເຮັດໃຫ້ວຽກທີ່ເຮັດປະຈຳໄດ້ງ່າຍຂຶ້ນ ແລະ ອັດຕະໂນມັດໃໝ່, ເພີ່ມຄວາມໝັ້ນຄົງ ແລະ ຄວາມໜ້າເຊື່ອຖືຂອງການບໍລິການ... ຕອນນີ້ພວກເຮົາກຳລັງເປີດບໍລິການ Chaos Monkey (ໂດຍສະເພາະ. , ພວກເຮົາໃຊ້ chaoskube, ແຕ່ນີ້ບໍ່ປ່ຽນແປງແນວຄວາມຄິດ: ), ເຊິ່ງໄດ້ຖືກສ້າງຂື້ນໃນເບື້ອງຕົ້ນໂດຍ Netflix. Chaos Monkey ເຮັດສິ່ງງ່າຍໆອັນດຽວ: ມັນລຶບຝັກ Kubernetes ແບບສຸ່ມໃນເວລາສຸ່ມ. ນີ້ແມ່ນສິ່ງຈໍາເປັນສໍາລັບການບໍລິການຂອງພວກເຮົາທີ່ຈະດໍາລົງຊີວິດຕາມປົກກະຕິກັບຈໍານວນຂອງ instances n-1, ດັ່ງນັ້ນພວກເຮົາຝຶກອົບຮົມຕົວເອງເພື່ອກຽມພ້ອມສໍາລັບບັນຫາຕ່າງໆ.

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

ສິ່ງທີ່ພວກເຮົາໄດ້ຮຽນຮູ້ຈາກການເຮັດວຽກກັບການບໍລິການຄລາວ

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

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