Kubernetes ຈະຄອບຄອງທົ່ວໂລກ. ເມື່ອໃດ ແລະແນວໃດ?

ໃນ​ການ​ຄາດ​ຄະ​ເນ​ DevOpsConf Vitaly Khabarov ສໍາພາດ Dmitry Stolyarov (disstol), ຜູ້ອໍານວຍການດ້ານວິຊາການແລະຜູ້ຮ່ວມກໍ່ຕັ້ງຂອງບໍລິສັດ Flant. Vitaly ຖາມ Dmitry ກ່ຽວກັບສິ່ງທີ່ Flant ເຮັດ, ກ່ຽວກັບ Kubernetes, ການພັດທະນາລະບົບນິເວດ, ການສະຫນັບສະຫນູນ. ພວກເຮົາໄດ້ປຶກສາຫາລືວ່າເປັນຫຍັງ Kubernetes ຈຶ່ງຕ້ອງການ ແລະວ່າມັນຈໍາເປັນຫຼືບໍ່. ແລະຍັງກ່ຽວກັບການບໍລິການຈຸລະພາກ, Amazon AWS, ວິທີການ "ຂ້ອຍຈະໂຊກດີ" ກັບ DevOps, ອະນາຄົດຂອງ Kubernetes ຕົວຂອງມັນເອງ, ເປັນຫຍັງ, ເວລາໃດແລະວິທີການທີ່ມັນຈະຄອບຄອງທົ່ວໂລກ, ຄວາມສົດໃສດ້ານຂອງ DevOps ແລະສິ່ງທີ່ວິສະວະກອນຄວນກະກຽມໃນ. ອະນາຄົດທີ່ສົດໃສ ແລະໃກ້ກັບຄວາມງ່າຍດາຍ ແລະເຄືອຂ່າຍ neural.

ການສໍາພາດຕົ້ນສະບັບ ຟັງເປັນພອດແຄສໃນ DevOps Deflop - ເປັນພອດແຄສເປັນພາສາລັດເຊຍກ່ຽວກັບ DevOps, ແລະຂ້າງລຸ່ມນີ້ແມ່ນສະບັບຂໍ້ຄວາມ.

ທີ່ນີ້ແລະຂ້າງລຸ່ມນີ້ລາວຖາມຄໍາຖາມ Vitaly Khabarov ວິສະວະກອນຈາກ Express42.

ກ່ຽວກັບ "Flant"

- ສະບາຍດີ Dima. ທ່ານເປັນຜູ້ອໍານວຍການດ້ານວິຊາການ "ແປນ"ແລະຜູ້ກໍ່ຕັ້ງຂອງມັນ. ກະລຸນາບອກພວກເຮົາວ່າບໍລິສັດເຮັດຫຍັງແລະເຈົ້າຢູ່ໃນນັ້ນແມ່ນຫຍັງ?

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




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

ກ່ຽວກັບ Kubernetes

— ຫວ່າງ​ມໍ່ໆ​ມາ​ນີ້​ຂ້າ​ພະ​ເຈົ້າ​ໄດ້​ເຫັນ​ຫຼາຍ​ບົດ​ລາຍ​ງານ​ຈາກ Flant ແລະ ບົດຄວາມ ກ່ຽວກັບ Kubernetes. ເຈົ້າມາມັນໄດ້ແນວໃດ?

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

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

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

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

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

ກ່ຽວກັບ Kubernetes

— ທ່ານມີສ່ວນຮ່ວມໂດຍກົງໃນການພັດທະນາ Kubernetes ຕົວຂອງມັນເອງບໍ?

Dmitry: ປານກາງ. ແທນທີ່ຈະ, ພວກເຮົາມີສ່ວນຮ່ວມໃນການພັດທະນາລະບົບນິເວດ. ພວກເຮົາສົ່ງຄໍາຮ້ອງຂໍດຶງຈໍານວນທີ່ແນ່ນອນ: ກັບ Prometheus, ກັບຜູ້ປະກອບການຕ່າງໆ, ກັບ Helm - ກັບລະບົບນິເວດ. ແຕ່ຫນ້າເສຍດາຍ, ຂ້ອຍບໍ່ສາມາດຕິດຕາມທຸກສິ່ງທີ່ພວກເຮົາເຮັດແລະຂ້ອຍອາດຈະຜິດ, ແຕ່ບໍ່ມີສະນຸກເກີດຽວຈາກພວກເຮົາເຂົ້າໄປໃນຫຼັກ.

— ໃນ​ເວ​ລາ​ດຽວ​ກັນ​, ທ່ານ​ພັດ​ທະ​ນາ​ເຄື່ອງ​ມື​ຫຼາຍ​ຂອງ​ທ່ານ​ກ່ຽວ​ກັບ Kubernetes​?

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

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

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

ເສັ້ນທາງແມ່ນເປັນແບບນີ້ສະເໝີ: ພວກເຮົາຄົ້ນຫາຢ່າງລະມັດລະວັງ ແລະ ຖ້າພວກເຮົາບໍ່ພົບທາງອອກໃດໆກ່ຽວກັບວິທີເຮັດລົດເຂັນອອກຈາກເຂົ້າຈີ່, ພວກເຮົາກໍ່ເຮັດ loaf ຂອງພວກເຮົາແລະ trolleybus ຂອງພວກເຮົາເອງ.

ເຄື່ອງ​ມື Flanta​

— ຂ້າ​ພະ​ເຈົ້າ​ຮູ້​ວ່າ​ໃນ​ປັດ​ຈຸ​ບັນ Flant ມີ addon operators, shell operators, ແລະ dapp/werf tools. ດັ່ງທີ່ຂ້າພະເຈົ້າເຂົ້າໃຈມັນ, ນີ້ແມ່ນເຄື່ອງມືດຽວກັນໃນ incarnations ທີ່ແຕກຕ່າງກັນ. ຂ້າພະເຈົ້າຍັງເຂົ້າໃຈວ່າມີເຄື່ອງມືທີ່ແຕກຕ່າງກັນຫຼາຍພາຍໃນ Flaunt. ນີ້​ແມ່ນ​ຄວາມ​ຈິງ?

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

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

ການພັດທະນາລະບົບນິເວດ

"ມັນເບິ່ງຄືວ່າຂ້ອຍໄດ້ປະກອບສ່ວນອັນໃຫຍ່ຫຼວງຕໍ່ການພັດທະນາເຄື່ອງມືນີ້ແລະວິທີການນໍາໃຊ້ຂອງມັນ." ທ່ານສາມາດຄາດຄະເນໄດ້ປະມານວ່າໃຜຈະປະກອບສ່ວນດຽວກັນກັບການພັດທະນາລະບົບນິເວດ?

Dmitry: ໃນລັດເຊຍ, ຂອງບໍລິສັດທີ່ດໍາເນີນການໃນຕະຫຼາດຂອງພວກເຮົາ, ບໍ່ມີໃຜໃກ້ຊິດ. ແນ່ນອນ, ນີ້ແມ່ນຄໍາຖະແຫຼງທີ່ດັງ, ເພາະວ່າມີຜູ້ຫຼິ້ນທີ່ສໍາຄັນເຊັ່ນ Mail ແລະ Yandex - ພວກເຂົາຍັງເຮັດບາງສິ່ງບາງຢ່າງກັບ Kubernetes, ແຕ່ເຖິງແມ່ນວ່າພວກເຂົາບໍ່ໄດ້ເຂົ້າມາໃກ້ກັບການປະກອບສ່ວນຂອງບໍລິສັດທົ່ວໂລກທີ່ເຮັດຫຼາຍກ່ວາພວກເຮົາ. ມັນເປັນການຍາກທີ່ຈະປຽບທຽບ Flant, ເຊິ່ງມີພະນັກງານ 80 ຄົນ, ແລະ Red Hat, ເຊິ່ງມີວິສະວະກອນ 300 ຄົນຕໍ່ Kubernetes ຄົນດຽວ, ຖ້າຂ້ອຍບໍ່ຜິດ. ມັນຍາກທີ່ຈະປຽບທຽບ. ພວກເຮົາມີ 6 ຄົນຢູ່ໃນພະແນກ RnD, ລວມທັງຂ້ອຍ, ຜູ້ທີ່ຕັດເຄື່ອງມືຂອງພວກເຮົາທັງຫມົດ. 6 ຄົນທຽບກັບວິສະວະກອນ Red Hat 300 ຄົນ - ມັນຍາກທີ່ຈະປຽບທຽບ.

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

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

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

ນີ້ແມ່ນສ່ວນຫນຶ່ງຂອງຍຸດທະສາດໃຫຍ່ຂອງພວກເຮົາກັບ dapp / werf. ຂ້ອຍບໍ່ຈື່ເວລາທີ່ພວກເຮົາເລີ່ມເຮັດມັນ, ມັນເບິ່ງຄືວ່າ 3 ປີກ່ອນ. ໃນເບື້ອງຕົ້ນ, ໂດຍທົ່ວໄປມັນຢູ່ເທິງເປືອກ. ມັນ​ເປັນ​ຫຼັກ​ຖານ​ພິ​ສູດ super ຂອງ​ແນວ​ຄວາມ​ຄິດ​, ພວກ​ເຮົາ​ແກ້​ໄຂ​ບາງ​ບັນ​ຫາ​ໂດຍ​ສະ​ເພາະ​ຂອງ​ພວກ​ເຮົາ - ມັນ​ໄດ້​ຜົນ​! ແຕ່ມີບັນຫາກັບແກະ, ມັນເປັນໄປບໍ່ໄດ້ທີ່ຈະຂະຫຍາຍມັນຕື່ມອີກ, ການຂຽນໂປລແກລມໃນແກະແມ່ນວຽກງານອື່ນ. ພວກເຮົາມີນິໄສຂອງການຂຽນໃນ Ruby, ຕາມຄວາມເຫມາະສົມ, ພວກເຮົາສ້າງບາງສິ່ງບາງຢ່າງໃນ Ruby, ພັດທະນາ, ພັດທະນາ, ພັດທະນາ, ແລະແລ່ນເຂົ້າໄປໃນຄວາມຈິງທີ່ວ່າຊຸມຊົນ, ຝູງຊົນທີ່ບໍ່ເວົ້າວ່າ "ພວກເຮົາຕ້ອງການຫຼືພວກເຮົາບໍ່ຕ້ອງການ, ” ຫັນດັງຂອງມັນໃສ່ Ruby, ມັນເປັນເລື່ອງຕະຫລົກແນວໃດ? ພວກເຮົາຮັບຮູ້ວ່າພວກເຮົາຄວນຂຽນສິ່ງທັງຫມົດນີ້ໃນ Go ເພື່ອຕອບສະຫນອງຈຸດທໍາອິດໃນລາຍການກວດກາ: ເຄື່ອງມື DevOps ຄວນເປັນ binary static. ຈະເປັນ Go ຫຼືບໍ່ແມ່ນມີຄວາມສໍາຄັນຫຼາຍ, ແຕ່ binary static ຂຽນໃນ Go ແມ່ນດີກວ່າ.

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

ເປັນຫຍັງ dapp ຖືກສ້າງຂື້ນ?

— ເຈົ້າສາມາດບອກພວກເຮົາສັ້ນໆວ່າເປັນຫຍັງ dapp ຖືກສ້າງຂຶ້ນ, ມັນແກ້ໄຂບັນຫາຫຍັງແດ່?

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

ເຫດຜົນທີສອງແມ່ນການປະຕິບັດ. ແມ່ນແລ້ວ, ມີ Helm, ແຕ່ມັນແກ້ໄຂບາງບັນຫາເທົ່ານັ້ນ. ເປັນເລື່ອງຕະຫລົກພຽງພໍ, ມັນໄດ້ຖືກຂຽນວ່າ "Helm ແມ່ນຜູ້ຈັດການຊຸດສໍາລັບ Kubernetes." ແນ່ນອນວ່າ "ໄດ້". ຍັງມີຄໍາວ່າ "Package Manager" - ຄວາມຄາດຫວັງປົກກະຕິຈາກຜູ້ຈັດການຊຸດແມ່ນຫຍັງ? ພວກເຮົາເວົ້າວ່າ: "Package Manager - ຕິດຕັ້ງຊຸດ!" ແລະພວກເຮົາຄາດຫວັງວ່າລາວຈະບອກພວກເຮົາວ່າ: "ຊຸດໄດ້ຖືກຈັດສົ່ງແລ້ວ."

ມັນຫນ້າສົນໃຈທີ່ພວກເຮົາເວົ້າວ່າ: "Helm, ຕິດຕັ້ງຊຸດ," ແລະເມື່ອລາວຕອບວ່າລາວຕິດຕັ້ງມັນ, ປະກົດວ່າລາວພຽງແຕ່ເລີ່ມຕົ້ນການຕິດຕັ້ງ - ລາວຊີ້ໃຫ້ເຫັນ Kubernetes: "ເປີດຕົວສິ່ງນີ້!", ແລະບໍ່ວ່າຈະເລີ່ມຕົ້ນຫຼືບໍ່. , ບໍ່ວ່າຈະເຮັດວຽກຫຼືບໍ່, Helm ບໍ່ໄດ້ແກ້ໄຂບັນຫານີ້ເລີຍ.

ມັນປະກົດວ່າ Helm ແມ່ນພຽງແຕ່ຕົວປະມວນຜົນຂໍ້ຄວາມທີ່ໂຫລດຂໍ້ມູນເຂົ້າໄປໃນ Kubernetes.

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

ແຜນການ

ປີນີ້ພວກເຮົາຈະເລີ່ມພັດທະນາທ້ອງຖິ່ນ. ພວກເຮົາຕ້ອງການບັນລຸສິ່ງທີ່ຢູ່ໃນ Vagrant ໃນເມື່ອກ່ອນ - ພວກເຮົາພິມ "vagrant up" ແລະພວກເຮົານໍາໃຊ້ເຄື່ອງຈັກ virtual. ພວກເຮົາຕ້ອງການໄປເຖິງຈຸດທີ່ມີໂຄງການໃນ Git, ພວກເຮົາຂຽນ "werf up" ຢູ່ທີ່ນັ້ນ, ແລະມັນເອົາສໍາເນົາທ້ອງຖິ່ນຂອງໂຄງການນີ້, ນໍາໃຊ້ໃນ mini-Kub ທ້ອງຖິ່ນ, ມີທຸກໄດເລກະທໍລີທີ່ສະດວກສໍາລັບການພັດທະນາເຊື່ອມຕໍ່. . ອີງຕາມພາສາການພັດທະນາ, ນີ້ແມ່ນເຮັດແຕກຕ່າງກັນ, ແຕ່ຢ່າງໃດກໍ່ຕາມ, ເພື່ອໃຫ້ການພັດທະນາທ້ອງຖິ່ນສາມາດປະຕິບັດໄດ້ສະດວກສະບາຍພາຍໃຕ້ໄຟລ໌ທີ່ຕິດຕັ້ງ.

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

ແຕ່ເສັ້ນທາງໄປສູ່ dapp/werf ສະເຫມີຄືກັນກັບ Kubernetes ໃນຕອນເລີ່ມຕົ້ນ. ພວກເຮົາພົບບັນຫາ, ແກ້ໄຂໃຫ້ເຂົາເຈົ້າມີການແກ້ໄຂ - ພວກເຮົາມາເຖິງການແກ້ໄຂບາງຢ່າງສໍາລັບຕົວເຮົາເອງກ່ຽວກັບແກະ, ກ່ຽວກັບສິ່ງໃດ. ຫຼັງຈາກນັ້ນ, ພວກເຂົາເຈົ້າໄດ້ພະຍາຍາມ somehow straighten the workarounds ເຫຼົ່ານີ້, ໂດຍທົ່ວໄປແລະລວມໃຫ້ເຂົາເຈົ້າເຂົ້າໄປໃນ binaries ໃນກໍລະນີນີ້, ທີ່ພວກເຮົາພຽງແຕ່ແບ່ງປັນ.

ມີວິທີອື່ນທີ່ຈະເບິ່ງເລື່ອງທັງຫມົດນີ້, ດ້ວຍການປຽບທຽບ.

Kubernetes ແມ່ນກອບລົດທີ່ມີເຄື່ອງຈັກ. ບໍ່ມີປະຕູ, ແກ້ວ, ວິທະຍຸ, ຕົ້ນໄມ້ວັນຄຣິດສະມາດ - ບໍ່ມີຫຍັງເລີຍ. ພຽງແຕ່ກອບແລະເຄື່ອງຈັກ. ແລະມີ Helm - ນີ້ແມ່ນການຊີ້ນໍາ. ເຢັນ - ມີພວງມາໄລ, ແຕ່ທ່ານຍັງຕ້ອງການ pin ພວງມາໄລ, rack ພວງມາໄລ, ກ່ອງເກຍແລະລໍ້, ແລະທ່ານບໍ່ສາມາດເຮັດໄດ້ໂດຍບໍ່ມີພວກມັນ.

ໃນກໍລະນີຂອງ werf, ນີ້ແມ່ນສ່ວນປະກອບອື່ນຂອງ Kubernetes. ພຽງແຕ່ໃນປັດຈຸບັນຢູ່ໃນສະບັບ alpha ຂອງ werf, ສໍາລັບການຍົກຕົວຢ່າງ, Helm ໄດ້ຖືກລວບລວມພາຍໃນ werf, ເນື່ອງຈາກວ່າພວກເຮົາເມື່ອຍຂອງເຮັດມັນເອງ. ມີຫຼາຍເຫດຜົນທີ່ຈະເຮັດແນວນີ້, ຂ້າພະເຈົ້າຈະບອກທ່ານຢ່າງລະອຽດກ່ຽວກັບວ່າເປັນຫຍັງພວກເຮົາລວບລວມຫມວກກັນກະທົບທັງຫມົດຮ່ວມກັນກັບ tiller ພາຍໃນ werf. ໃນບົດລາຍງານທີ່ RIT++.

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

Kubernetes ຍາກທີ່ຈະຮັກສາ?

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

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

— ຕາມ​ທີ່​ຂ້າ​ພະ​ເຈົ້າ​ຮູ້ ແລະ​ດັ່ງ​ທີ່​ຂ້າ​ພະ​ເຈົ້າ​ເຫັນ, ໃນ​ປັດ​ຈຸ​ບັນ​ຫຼາຍ​ທີມ​ຕ້ອງ​ການ​ທີ່​ຈະ​ທົດ​ລອງ Kubernetes. ທຸກຄົນ harnesses ຕົນເອງກັບມັນ, puts ສຸດຫົວເຂົ່າຂອງເຂົາເຈົ້າ. ຂ້າພະເຈົ້າມີຄວາມຮູ້ສຶກວ່າປະຊາຊົນບໍ່ສະເຫມີເຂົ້າໃຈຄວາມສັບສົນຂອງລະບົບນີ້.

Dmitry: ມັນຄືແນວນັ້ນ.

— ມັນຍາກຫຼາຍປານໃດທີ່ຈະເອົາ ແລະຕິດຕັ້ງ Kubernetes ຕັ້ງແຕ່ຕົ້ນເພື່ອໃຫ້ມັນກຽມພ້ອມ?

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

ການຕິດຕັ້ງ Kubernetes ແລະເຮັດໃຫ້ມັນເຮັດວຽກແມ່ນງ່າຍ: chick! - ຕິດ​ຕັ້ງ​, ມີ​ຫຼາຍ​ວິ​ທີ​ການ​ຕິດ​ຕັ້ງ​. ແຕ່ຈະເກີດຫຍັງຂຶ້ນເມື່ອມີບັນຫາ?

ຄຳຖາມເກີດຂຶ້ນສະເໝີ - ພວກເຮົາບໍ່ໄດ້ຄຳນຶງເຖິງອັນໃດເທື່ອ? ພວກເຮົາຍັງບໍ່ໄດ້ເຮັດຫຍັງເທື່ອ? ພາລາມິເຕີ Linux kernel ໃດຖືກລະບຸບໍ່ຖືກຕ້ອງ? ພຣະຜູ້ເປັນເຈົ້າ, ພວກເຮົາຍັງໄດ້ກ່າວເຖິງພວກເຂົາບໍ?! ອົງປະກອບ Kubernetes ໃດທີ່ພວກເຮົາໄດ້ສົ່ງແລະພວກເຮົາຍັງບໍ່ໄດ້ສົ່ງ? ຫລາຍພັນຄໍາຖາມເກີດຂື້ນ, ແລະເພື່ອຕອບພວກເຂົາ, ທ່ານຈໍາເປັນຕ້ອງໃຊ້ເວລາ 15-20 ປີໃນອຸດສາຫະກໍານີ້.

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

ໃຫ້ຂ້ອຍອະທິບາຍວ່າ Cilium ແມ່ນຫຍັງ. Kubernetes ມີການປະຕິບັດທີ່ແຕກຕ່າງກັນຫຼາຍຂອງລະບົບຍ່ອຍເຄືອຂ່າຍ, ແລະຫນຶ່ງໃນນັ້ນແມ່ນເຢັນຫຼາຍ - Cilium. ຄວາມຫມາຍຂອງມັນແມ່ນຫຍັງ? ໃນ kernel, ບາງເວລາກ່ອນຫນ້ານີ້ມັນເປັນໄປໄດ້ທີ່ຈະຂຽນ hooks ສໍາລັບ kernel, ເຊິ່ງໃນວິທີການຫນຶ່ງຫຼືອື່ນ invaded ລະບົບຍ່ອຍເຄືອຂ່າຍແລະລະບົບຍ່ອຍອື່ນໆ, ແລະອະນຸຍາດໃຫ້ທ່ານສາມາດ bypass chunks ຂະຫນາດໃຫຍ່ໃນ kernel ໄດ້.

Linux kernel ໃນປະຫວັດສາດມີເສັ້ນທາງ ip, overfilter, ຂົວແລະອົງປະກອບເກົ່າທີ່ແຕກຕ່າງກັນຫຼາຍທີ່ມີອາຍຸ 15, 20, 30 ປີ. ໂດຍທົ່ວໄປ, ພວກເຂົາເຈົ້າເຮັດວຽກ, ທຸກສິ່ງທຸກຢ່າງແມ່ນຍິ່ງໃຫຍ່, ແຕ່ໃນປັດຈຸບັນພວກເຂົາເຈົ້າໄດ້ piled ຕູ້ຄອນເທນເນີ, ແລະມັນຄ້າຍຄື tower ຂອງ 15 bricks ເທິງຂອງກັນແລະກັນ, ແລະທ່ານຢືນມັນຢູ່ໃນຂາຫນຶ່ງ - ຄວາມຮູ້ສຶກທີ່ແປກປະຫລາດ. ລະບົບນີ້ໄດ້ຖືກພັດທະນາໃນປະຫວັດສາດທີ່ມີ nuances ຫຼາຍຢ່າງເຊັ່ນ: ເອກະສານຊ້ອນທ້າຍຢູ່ໃນຮ່າງກາຍ. ໃນບາງສະຖານະການມີບັນຫາການປະຕິບັດ, ສໍາລັບການຍົກຕົວຢ່າງ.

ມີ BPF ທີ່ປະເສີດແລະຄວາມສາມາດໃນການຂຽນ hooks ສໍາລັບແກ່ນ - guys ຂຽນ hooks ຂອງຕົນເອງສໍາລັບແກ່ນ. ຊຸດດັ່ງກ່າວເຂົ້າໄປໃນ Linux kernel, ພວກເຂົາເອົາມັນອອກທັນທີທີ່ວັດສະດຸປ້ອນ, ປຸງແຕ່ງມັນເອງຕາມທີ່ມັນຄວນຈະບໍ່ມີຂົວ, ໂດຍບໍ່ມີ TCP, ໂດຍບໍ່ມີ IP stack - ໃນສັ້ນ, ຂ້າມທຸກສິ່ງທຸກຢ່າງທີ່ຂຽນໄວ້ໃນ Linux kernel, ແລະຫຼັງຈາກນັ້ນ spit. ມັນອອກເຂົ້າໄປໃນຖັງ.

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

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

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

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

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

ກ່ຽວກັບວິທີ "ຂ້ອຍຈະໂຊກດີ".

— ມີ ບໍ ລິ ສັດ ທີ່ nuances ເຫຼົ່າ ນີ້ ໄດ້ ຮັບ ປະ ກັນ ເກືອບ ຈະ ປາ ກົດ? ສົມມຸດວ່າ Yandex ທັນທີທັນໃດໂອນການບໍລິການທັງຫມົດໄປຫາ Kubernetes, ມັນຈະມີຈໍານວນຫຼວງຫຼາຍຢູ່ທີ່ນັ້ນ.

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

ຂ້ອຍມີ Ubuntu 16.04. ທ່ານສາມາດເວົ້າວ່ານີ້ແມ່ນສະບັບເກົ່າ, ແຕ່ພວກເຮົາຍັງຢູ່ໃນມັນເພາະວ່າມັນເປັນ LTS. ມີ systemd, nuance ຂອງຊຶ່ງໃນນັ້ນແມ່ນວ່າມັນບໍ່ສະອາດເຖິງກຸ່ມ C. Kubernetes ເປີດຕົວ pods, ສ້າງກຸ່ມ C, ຫຼັງຈາກນັ້ນລຶບ pods, ແລະຢ່າງໃດກໍ່ຕາມມັນກໍ່ປາກົດ - ຂ້ອຍບໍ່ຈື່ລາຍລະອຽດ, ຂໍອະໄພ - ຊິ້ນທີ່ມີລະບົບຍັງຄົງຢູ່. ນີ້ນໍາໄປສູ່ຄວາມຈິງທີ່ວ່າໃນໄລຍະເວລາ, ລົດໃດກໍ່ເລີ່ມຊ້າລົງຢ່າງແຂງແຮງ. ນີ້ບໍ່ແມ່ນຄໍາຖາມກ່ຽວກັບການໂຫຼດສູງ. ຖ້າ pods ຖາວອນຖືກເປີດຕົວ, ຕົວຢ່າງ, ຖ້າມີ Cron Job ທີ່ຜະລິດຝັກຢ່າງຕໍ່ເນື່ອງ, ຫຼັງຈາກນັ້ນເຄື່ອງທີ່ມີ Ubuntu 16.04 ຈະເລີ່ມຊ້າລົງຫຼັງຈາກຫນຶ່ງອາທິດ. ຈະມີຄ່າສະເລ່ຍການໂຫຼດສູງຢ່າງຕໍ່ເນື່ອງເນື່ອງຈາກຄວາມຈິງທີ່ວ່າກຸ່ມ C-groups ໄດ້ຖືກສ້າງຂື້ນ. ນີ້ແມ່ນບັນຫາທີ່ຜູ້ທີ່ພຽງແຕ່ຕິດຕັ້ງ Ubuntu 16 ແລະ Kubernetes ຢູ່ເທິງສຸດຈະປະເຊີນ.

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

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

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

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

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

- ຈາກການປະເມີນໃນແງ່ດີຂອງຂ້ອຍ, ມັນເບິ່ງຄືວ່າ: ເມື່ອຄວາມສ່ຽງສູງ, ແລະແອັບພລິເຄຊັນຕ້ອງເຮັດວຽກ, ຕ້ອງການການສະຫນັບສະຫນູນຈາກ Flaunt, ບາງທີອາດມາຈາກ Red Hat, ຫຼືທ່ານຕ້ອງການທີມງານພາຍໃນຂອງເຈົ້າເອງທີ່ອຸທິດຕົນໂດຍສະເພາະ Kubernetes, ເຊິ່ງພ້ອມແລ້ວ. ເພື່ອດຶງມັນອອກ.

Dmitry: ຈຸດປະສົງ, ນີ້ແມ່ນດັ່ງນັ້ນ. ການເຂົ້າໄປໃນເລື່ອງ Kubernetes ສໍາລັບທີມງານຂະຫນາດນ້ອຍຂອງທ່ານເອງກ່ຽວຂ້ອງກັບຄວາມສ່ຽງຈໍານວນຫນຶ່ງ.

ພວກເຮົາຕ້ອງການບັນຈຸ?

— ເຈົ້າສາມາດບອກພວກເຮົາວ່າ Kubernetes ແຜ່ຂະຫຍາຍຢູ່ໃນລັດເຊຍໄດ້ແນວໃດ?

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

ຫຼັງຈາກນັ້ນ, ຄໍາຖາມອື່ນ - ພວກເຮົາຕ້ອງການບັນຈຸ? ຄວາມຮູ້ສຶກສ່ວນຕົວຂອງຂ້ອຍແລະຕໍາແຫນ່ງໂດຍລວມຂອງບໍລິສັດ Flant ແມ່ນວ່າ Kubernetes ແມ່ນມາດຕະຖານ de facto.

ບໍ່ມີຫຍັງນອກຈາກ Kubernetes.

ນີ້​ແມ່ນ​ການ​ປ່ຽນ​ແປງ​ເກມ​ຢ່າງ​ແທ້​ຈິງ​ໃນ​ພາກ​ສະ​ຫນາມ​ຂອງ​ການ​ຄຸ້ມ​ຄອງ​ພື້ນ​ຖານ​ໂຄງ​ລ່າງ​. ພຽງແຕ່ຢ່າງແທ້ຈິງ - ນັ້ນແມ່ນ, ບໍ່ມີ Ansible, Chef, ເຄື່ອງ virtual, Terraform. ຂ້າພະເຈົ້າບໍ່ໄດ້ເວົ້າກ່ຽວກັບວິທີການກະສິກໍາລວມເກົ່າ. Kubernetes ແມ່ນຕົວປ່ຽນແປງຢ່າງແທ້ຈິງ, ແລະດຽວນີ້ມັນຈະເປັນແບບນີ້ເທົ່ານັ້ນ.

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

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

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

ທຸກຢ່າງທີ່ກ່ຽວຂ້ອງກັບ CI/CD - ບ່ອນໃດກໍໄດ້ທີ່ຕ້ອງການສົ່ງຕໍ່ຢ່າງຕໍ່ເນື່ອງ, ບ່ອນທີ່ທ່ານຕ້ອງການອັບເດດເວີຊັ່ນ, ປ່ຽນແປງຢ່າງຫ້າວຫັນ, ຢູ່ບ່ອນໃດກໍໄດ້ທີ່ເຈົ້າຕ້ອງການສ້າງຄວາມທົນທານຕໍ່ຄວາມຜິດພາດ - ມີພຽງແຕ່ Kubernetes ເທົ່ານັ້ນ.

ກ່ຽວກັບການບໍລິການຈຸລະພາກ

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

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

ຕົວຢ່າງ, ມີ monolith ທີ່ຂຽນໂດຍ 300 ຄົນ, ແລະທຸກຄົນທີ່ເຂົ້າຮ່ວມໃນການພັດທະນາເຂົ້າໃຈວ່າມີບັນຫາຢູ່ທີ່ນັ້ນ, ແລະມັນຄວນຈະຖືກແຍກອອກເປັນຈຸນລະພາກ - ປະມານ 10 ຊິ້ນ, ແຕ່ລະຄົນຂຽນໂດຍ 30 ຄົນ. ໃນ​ສະ​ບັບ​ຕໍາ​່​ສຸດ​ທີ່​. ນີ້ແມ່ນສໍາຄັນ, ມີຄວາມຈໍາເປັນແລະເຢັນ. ແຕ່ໃນເວລາທີ່ການເລີ່ມຕົ້ນມາຫາພວກເຮົາ, ບ່ອນທີ່ 3 guys ເຢັນຫຼາຍແລະມີພອນສະຫວັນຂຽນ 60 microservices ສຸດຫົວເຂົ່າຂອງເຂົາເຈົ້າ, ທຸກໆຄັ້ງທີ່ຂ້າພະເຈົ້າຊອກຫາ Corvalol.

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

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

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

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

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

ຂ້າພະເຈົ້າຂໍແນະນໍາໃຫ້ outsourcing ກັບ startups ແລະທຸລະກິດສ້າງຕັ້ງຂຶ້ນເຖິງຂະຫນາດທີ່ທ່ານສາມາດອຸທິດທີມງານຂອງ 10 ຄົນໃນການດໍາເນີນງານ, ເພາະວ່າຖ້າບໍ່ດັ່ງນັ້ນບໍ່ມີຈຸດ. ມັນແນ່ນອນເຮັດໃຫ້ຄວາມຮູ້ສຶກທີ່ຈະ outsource ນີ້.

ກ່ຽວກັບ Amazon ແລະ Google

— ເຈົ້າ ພາບ ຈາກ ການ ແກ້ ໄຂ ຈາກ Amazon ຫຼື Google ສາ ມາດ ຖືກ ພິ ຈາ ລະ ນາ ເປັນ outsource ບໍ?

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

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

ອາດຈະເປັນຄໍາຕອບ - ແນ່ນອນ, ເລື່ອງທີ່ເປັນເຈົ້າພາບເຮັດໃຫ້ບາງສ່ວນງ່າຍຂຶ້ນ. ຄໍາຖາມແມ່ນວ່າທ່ານພ້ອມທີ່ຈະໄວ້ວາງໃຈກັບເຈົ້າພາບເຫຼົ່ານີ້ແລະວ່າພວກເຂົາຈະແກ້ໄຂບັນຫາຂອງທ່ານບໍ? Amazon ແລະ Google ເຮັດໄດ້ດີ. ສໍາລັບກໍລະນີຂອງພວກເຮົາທັງຫມົດ - ແທ້. ພວກເຮົາບໍ່ມີປະສົບການໃນທາງບວກອີກຕໍ່ໄປ. ຟັງອື່ນໆທັງຫມົດທີ່ພວກເຮົາໄດ້ພະຍາຍາມເຮັດວຽກຮ່ວມກັນສ້າງບັນຫາຫຼາຍ - Ager, ແລະທຸກສິ່ງທຸກຢ່າງທີ່ຢູ່ໃນລັດເຊຍ, ແລະທຸກປະເພດຂອງ OpenStack ໃນການປະຕິບັດທີ່ແຕກຕ່າງກັນ: Headster, Overage - ສິ່ງທີ່ທ່ານຕ້ອງການ. ພວກເຂົາທັງຫມົດສ້າງບັນຫາທີ່ເຈົ້າບໍ່ຕ້ອງການແກ້ໄຂ.

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

ໃຜຕ້ອງການ Kubernetes?

— ແລະຍັງ, ໃຜຕ້ອງການ Kubernetes? ໃຜຄວນຈະປ່ຽນໄປໃຊ້ Kubernetes ແລ້ວ, ໃຜເປັນລູກຄ້າ Flaunt ທົ່ວໄປທີ່ເຂົ້າມາສະເພາະສໍາລັບ Kubernetes?

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

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

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

ຕອບຄໍາຖາມຂອງຜູ້ທີ່ຕ້ອງການ Kubernetes - ບໍ່ມີໃຜຕ້ອງການ Kubernetes.

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

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

ຄໍາສັບທີ່ພວກເຮົາຫຼືຜູ້ອື່ນຕ້ອງການ Kubernetes ແມ່ນບໍ່ຖືກຕ້ອງ.

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

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

ຄໍາຕອບສຸດທ້າຍແມ່ນ: ທ່ານບໍ່ຕ້ອງການ Kubernetes. ທ່ານຈໍາເປັນຕ້ອງແກ້ໄຂບັນຫາຂອງທ່ານ.

ສິ່ງ​ທີ່​ທ່ານ​ສາ​ມາດ​ບັນ​ລຸ​ໄດ້​ແມ່ນ​:

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

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

ກ່ຽວກັບ serverless

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

Dmitry: ນີ້ພວກເຮົາຈໍາເປັນຕ້ອງໄດ້ໃຫ້ຂໍ້ສັງເກດອີກເທື່ອຫນຶ່ງວ່າຂ້າພະເຈົ້າບໍ່ແມ່ນຜູ້ພະຍາກອນທີ່ເບິ່ງລ່ວງຫນ້າແລະເວົ້າວ່າ - ມັນຈະເປັນແບບນີ້! ເຖິງແມ່ນວ່າຂ້າພະເຈົ້າພຽງແຕ່ເຮັດສິ່ງດຽວກັນ. ຂ້ອຍເບິ່ງຕີນຂອງຂ້ອຍແລະເບິ່ງບັນຫາຕ່າງໆຢູ່ທີ່ນັ້ນ, ຕົວຢ່າງ, ການເຮັດວຽກຂອງ transistors ໃນຄອມພິວເຕີ. ມັນເປັນເລື່ອງຕະຫລົກ, ບໍ່ແມ່ນບໍ? ພວກເຮົາກໍາລັງພົບບາງແມງໄມ້ໃນ CPU.

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

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

ກັບ serverless ຫນຶ່ງຕໍ່ຫນຶ່ງ: ສິ່ງທີ່ແມ່ນເຢັນ, ແຕ່ວ່າມັນແມ່ນຢູ່ໄກຈາກບັນຫາຂອງ 2019. ໃກ້ຮອດປີ 2030 - ມາເບິ່ງນຳກັນເລີຍ. ຂ້ອຍບໍ່ມີຄວາມສົງໃສວ່າພວກເຮົາຈະມີຊີວິດຢູ່, ພວກເຮົາຈະມີຊີວິດຢູ່ຢ່າງແນ່ນອນ (ເຮັດຊ້ໍາກ່ອນນອນ), ແຕ່ຕອນນີ້ພວກເຮົາຈໍາເປັນຕ້ອງແກ້ໄຂບັນຫາອື່ນໆ. ມັນຄ້າຍຄືການເຊື່ອໃນ fairy tale pony Rainbow. ແມ່ນແລ້ວ, ສອງສາມເປີເຊັນຂອງກໍລະນີຖືກແກ້ໄຂ, ແລະພວກມັນຖືກແກ້ໄຂຢ່າງສົມບູນ, ແຕ່ໃນຫົວຂໍ້, serverless ແມ່ນ rainbow ... ສໍາລັບຂ້ອຍ, ຫົວຂໍ້ນີ້ແມ່ນຫ່າງໄກເກີນໄປແລະບໍ່ສາມາດເຂົ້າໃຈໄດ້. ຂ້ອຍບໍ່ພ້ອມທີ່ຈະສົນທະນາ. ໃນປີ 2019, ທ່ານບໍ່ສາມາດຂຽນແອັບພລິເຄຊັນດຽວກັບ serverless ໄດ້.

Kubernetes ຈະພັດທະນາແນວໃດ

— ເມື່ອພວກເຮົາກ້າວໄປສູ່ອະນາຄົດອັນໄກອັນປະເສີດນີ້, ທ່ານຄິດວ່າ Kubernetes ແລະລະບົບນິເວດອ້ອມຂ້າງຈະພັດທະນາແນວໃດ?

Dmitry: ຂ້ອຍໄດ້ຄິດກ່ຽວກັບເລື່ອງນີ້ຫຼາຍແລະຂ້ອຍມີຄໍາຕອບທີ່ຊັດເຈນ. ທໍາອິດແມ່ນ stateful - ຫຼັງຈາກທີ່ທັງຫມົດ, stateless ແມ່ນເຮັດງ່າຍຂຶ້ນ. Kubernetes ໃນເບື້ອງຕົ້ນໄດ້ລົງທຶນຫຼາຍກວ່ານີ້, ມັນທັງຫມົດໄດ້ເລີ່ມຕົ້ນດ້ວຍມັນ. Stateless ເຮັດວຽກເກືອບຢ່າງສົມບູນໃນ Kubernetes, ບໍ່ມີຫຍັງທີ່ຈະຈົ່ມກ່ຽວກັບ. ຍັງມີຫຼາຍບັນຫາ, ຫຼືແທນທີ່ຈະ, nuances. ທຸກສິ່ງທຸກຢ່າງຢູ່ທີ່ນັ້ນເຮັດວຽກດີສໍາລັບພວກເຮົາ, ແຕ່ນັ້ນແມ່ນພວກເຮົາ. ມັນຈະໃຊ້ເວລາຢ່າງໜ້ອຍສອງສາມປີເພື່ອໃຫ້ສິ່ງນີ້ໃຊ້ໄດ້ກັບທຸກຄົນ. ນີ້ບໍ່ແມ່ນຕົວຊີ້ວັດທີ່ຄິດໄລ່, ແຕ່ຄວາມຮູ້ສຶກຂອງຂ້ອຍຈາກຫົວຂອງຂ້ອຍ.

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

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

ເລື່ອງການພັດທະນາຜູ້ປະກອບການໃນຮູບແບບຫນຶ່ງຫຼືອື່ນຈະມີຄວາມສໍາຄັນໃນສອງສາມປີຂ້າງຫນ້າ.

ຂ້າພະເຈົ້າຄິດວ່າຄວາມງ່າຍຂອງການນໍາໃຊ້ຄວນຈະເພີ່ມຂຶ້ນຢ່າງຫຼວງຫຼາຍ - ກ່ອງຈະກາຍເປັນສີດໍາຫຼາຍ, ຫຼາຍແລະເຊື່ອຖືໄດ້, ມີ knobs ງ່າຍດາຍຫຼາຍແລະຫຼາຍ.

ຂ້ອຍເຄີຍຟັງການສໍາພາດເກົ່າກັບ Isaac Asimov ຈາກ 80s ໃນ YouTube ໃນລາຍການ Saturday Night Live - ລາຍການເຊັ່ນ Urgant, ພຽງແຕ່ຫນ້າສົນໃຈ. ພວກເຂົາຖາມລາວກ່ຽວກັບອະນາຄົດຂອງຄອມພິວເຕີ. ທ່ານ​ກ່າວ​ວ່າ, ອາ​ນາ​ຄົດ​ຢູ່​ໃນ​ຄວາມ​ລຽບ​ງ່າຍ, ຄື​ກັນ​ກັບ​ວິ​ທະ​ຍຸ. ໃນເບື້ອງຕົ້ນ, ເຄື່ອງຮັບວິທະຍຸແມ່ນເປັນສິ່ງຊັບຊ້ອນ. ເພື່ອຈັບຄື້ນ, ທ່ານຕ້ອງໄດ້ຫັນລູກບິດສໍາລັບ 15 ນາທີ, ຫັນ skewers ແລະໂດຍທົ່ວໄປຮູ້ວ່າທຸກສິ່ງທຸກຢ່າງເຮັດວຽກ, ເຂົ້າໃຈຟີຊິກຂອງການສົ່ງຄື້ນວິທະຍຸ. ດັ່ງນັ້ນ, ມີພຽງແຕ່ຫນຶ່ງ knob ເຫຼືອຢູ່ໃນວິທະຍຸ.

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

ຫຼັງຈາກນັ້ນ Azimov ເວົ້າວ່າມັນຈະຄືກັນກັບຄອມພິວເຕີ - ຄວາມງ່າຍຂອງການນໍາໃຊ້ຈະເພີ່ມຂຶ້ນ. ໃນຂະນະທີ່ໃນປີ 1980 ທ່ານຕ້ອງໄດ້ຮັບການຝຶກອົບຮົມເພື່ອກົດປຸ່ມຕ່າງໆໃນຄອມພິວເຕີ, ມັນຈະບໍ່ເປັນກໍລະນີໃນອະນາຄົດ.

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

ຈະເຮັດແນວໃດກັບວິສະວະກອນ?

— ແລ້ວຈະເກີດຫຍັງຂຶ້ນກັບວິສະວະກອນ ແລະຜູ້ບໍລິຫານລະບົບທີ່ສະໜັບສະໜູນ Kubernetes?

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

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

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

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

DevOps ຫຼືວິສະວະກໍາລະບົບຈະບໍ່ຫາຍໄປ - ການເຮັດວຽກໃນລະດັບສູງແລະປະສິດທິພາບຈະເພີ່ມຂຶ້ນ.

— ຂ້າ​ພະ​ເຈົ້າ​ຍັງ​ໄດ້​ຍິນ​ຄວາມ​ຄິດ​ທີ່​ຫນ້າ​ສົນ​ໃຈ​ວ່າ​ການ​ເຮັດ​ວຽກ​ທີ່​ແທ້​ຈິງ​ຈະ​ເພີ່ມ​ຂຶ້ນ​.

Dmitry: ແນ່ນອນ, ຫນຶ່ງຮ້ອຍສ່ວນຮ້ອຍ! ເນື່ອງຈາກວ່າຈໍານວນຂອງຊອບແວທີ່ພວກເຮົາຂຽນແມ່ນການຂະຫຍາຍຕົວຢ່າງຕໍ່ເນື່ອງ. ຈໍານວນຂອງບັນຫາທີ່ພວກເຮົາແກ້ໄຂດ້ວຍຊອບແວແມ່ນການຂະຫຍາຍຕົວຢ່າງຕໍ່ເນື່ອງ. ຈໍານວນຂອງການເຮັດວຽກແມ່ນການຂະຫຍາຍຕົວ. ໃນປັດຈຸບັນຕະຫຼາດ DevOps ແມ່ນຮ້ອນເກີນໄປ. ນີ້ສາມາດເຫັນໄດ້ໃນຄວາມຄາດຫວັງຂອງເງິນເດືອນ. ໃນທາງທີ່ດີ, ໂດຍບໍ່ມີການເຂົ້າໄປໃນລາຍລະອຽດ, ຄວນມີ juniors ທີ່ຕ້ອງການ X, ກາງທີ່ຕ້ອງການ 1,5X, ແລະຜູ້ສູງອາຍຸທີ່ຕ້ອງການ 2X. ແລະໃນປັດຈຸບັນ, ຖ້າທ່ານເບິ່ງຕະຫຼາດເງິນເດືອນ Moscow DevOps, ຄົນຮຸ່ນນ້ອຍຕ້ອງການຈາກ X ຫາ 3X ແລະຜູ້ອາວຸໂສຕ້ອງການຈາກ X ຫາ 3X.

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

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

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

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

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

ຄວາມປາດຖະຫນາແລະນາທີຂອງການໂຄສະນາ

- ເຈົ້າມີຄວາມປາຖະຫນາບໍ?

Dmitry: ແມ່ນແລ້ວ, ຂ້ອຍມີຄວາມປາດຖະໜາຫຼາຍຢ່າງ.

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

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

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

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

- ຂອບໃຈຫຼາຍໆ!

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

ໃນການສໍາພາດ, Dmitry ໄດ້ສໍາຜັດກັບບັນຫາຂອງ werf. ໃນປັດຈຸບັນນີ້ແມ່ນມີດສະວິດເຊີແລນທົ່ວໄປທີ່ແກ້ໄຂບັນຫາເກືອບທັງຫມົດ. ແຕ່​ວ່າ​ມັນ​ບໍ່​ແມ່ນ​ສະ​ເຫມີ​ໄປ​. ສຸດ DevOpsConf  ໃນງານບຸນ RIT++ Dmitry Stolyarov ຈະບອກທ່ານກ່ຽວກັບເຄື່ອງມືນີ້ຢ່າງລະອຽດ. ໃນບົດລາຍງານ "werf ແມ່ນເຄື່ອງມືຂອງພວກເຮົາສໍາລັບ CI / CD ໃນ Kubernetes" ຈະມີທຸກສິ່ງທຸກຢ່າງ: ບັນຫາແລະ nuances ທີ່ເຊື່ອງໄວ້ຂອງ Kubernetes, ທາງເລືອກໃນການແກ້ໄຂບັນຫາຄວາມຫຍຸ້ງຍາກເຫຼົ່ານີ້ແລະການປະຕິບັດໃນປະຈຸບັນຂອງ werf ໃນລາຍລະອຽດ. ເຂົ້າຮ່ວມກັບພວກເຮົາໃນວັນທີ 27 ແລະ 28 ເດືອນພຶດສະພາ, ພວກເຮົາຈະສ້າງເຄື່ອງມືທີ່ສົມບູນແບບ.

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