ຜູ້ປະກອບການໃນ Kubernetes ສໍາລັບການຄຸ້ມຄອງກຸ່ມຖານຂໍ້ມູນ. ວລາດີສະລາບ ຄລິເມນໂກ (ອັນຕິນິຕີ, 2019)

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

ໃນສ່ວນທໍາອິດຂອງບົດລາຍງານພວກເຮົາຈະພິຈາລະນາ:

• ຜູ້ປະກອບການໃນ Kubernetes ແມ່ນຫຍັງ ແລະເປັນຫຍັງມັນຈຶ່ງຕ້ອງການ;
• ຜູ້ປະຕິບັດການເຮັດໃຫ້ການຈັດການລະບົບຊັບຊ້ອນໄດ້ງ່າຍຂຶ້ນແນວໃດ;
• ສິ່ງທີ່ຜູ້ປະກອບການສາມາດແລະບໍ່ສາມາດເຮັດໄດ້.

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

• ການໂຕ້ຕອບລະຫວ່າງຜູ້ປະກອບການແລະ Kubernetes;
• ປະຕິບັດໜ້າທີ່ອັນໃດທີ່ຜູ້ດຳເນີນການເຮັດ ແລະໜ້າທີ່ອັນໃດທີ່ມັນມອບໝາຍໃຫ້ Kubernetes.

ໃຫ້ເບິ່ງການຈັດການ shards ແລະ replicas ຖານຂໍ້ມູນໃນ Kubernetes.
ຕໍ່ໄປ, ພວກເຮົາຈະປຶກສາຫາລືບັນຫາການເກັບຮັກສາຂໍ້ມູນ:

• ວິທີການເຮັດວຽກກັບ Persistent Storage ຈາກທັດສະນະຂອງຜູ້ປະຕິບັດງານ;
• ຄວາມຜິດພາດຂອງການນໍາໃຊ້ການເກັບຮັກສາທ້ອງຖິ່ນ.

ໃນສ່ວນສຸດທ້າຍຂອງບົດລາຍງານ, ພວກເຮົາຈະພິຈາລະນາຕົວຢ່າງການປະຕິບັດຕົວຈິງຂອງຄໍາຮ້ອງສະຫມັກ clickhouse-operator ກັບ Amazon ຫຼື Google Cloud Service. ບົດລາຍງານແມ່ນອີງໃສ່ຕົວຢ່າງຂອງການພັດທະນາແລະປະສົບການການດໍາເນີນງານຂອງຜູ້ປະຕິບັດງານສໍາລັບ ClickHouse.

ວິດີໂອ:

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

ເປັນຫຍັງພວກເຮົາມີໂອກາດທີ່ຈະເວົ້າກ່ຽວກັບຜູ້ປະຕິບັດງານແລະ ClickHouse?

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

ຂ້າພະເຈົ້າຢາກບອກທ່ານກ່ຽວກັບຫນຶ່ງໃນໂຄງການເຫຼົ່ານີ້. ນີ້ແມ່ນກ່ຽວກັບ ClickHouse-operator ສໍາລັບ Kubernetes.

ໃນບົດລາຍງານຂອງຂ້ອຍ, ຂ້ອຍຕ້ອງການສໍາຜັດກັບສອງຫົວຂໍ້:

• ຫົວຂໍ້ທໍາອິດແມ່ນວິທີການຄຸ້ມຄອງຖານຂໍ້ມູນ ClickHouse ຂອງພວກເຮົາເຮັດວຽກຢູ່ໃນ Kubernetes.
• ຫົວຂໍ້ທີສອງແມ່ນວິທີການປະຕິບັດການໃດໆ, i.e. ວິທີການພົວພັນກັບ Kubernetes.

ຢ່າງໃດກໍຕາມ, ສອງຄໍາຖາມນີ້ຈະຕັດກັນຕະຫຼອດບົດລາຍງານຂອງຂ້ອຍ.

ໃຜສົນໃຈຢາກຟັງສິ່ງທີ່ຂ້ອຍພະຍາຍາມບອກ?

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

ເພື່ອເຂົ້າໃຈສິ່ງທີ່ພວກເຮົາຈະສົນທະນາໃນມື້ນີ້ດີທີ່ສຸດ, ມັນເປັນຄວາມຄິດທີ່ດີທີ່ຈະຮູ້ວ່າ Kubernetes ເຮັດວຽກແນວໃດ ແລະ ມີການຝຶກອົບຮົມພື້ນຖານກ່ຽວກັບຄລາວ.

ClickHouse ແມ່ນຫຍັງ? ນີ້ແມ່ນຖານຂໍ້ມູນຖັນທີ່ມີລັກສະນະສະເພາະສໍາລັບການປະມວນຜົນອອນໄລນ໌ຂອງຄໍາຖາມການວິເຄາະ. ແລະມັນເປັນແຫຼ່ງເປີດຢ່າງສົມບູນ.

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

ເປັນຫຍັງລາວຈຶ່ງຕ້ອງການຢູ່ທີ່ນັ້ນ? ເປັນ​ຫຍັງ​ພວກ​ເຮົາ​ບໍ່​ສາ​ມາດ​ສືບ​ຕໍ່​ດໍາ​ເນີນ​ການ​ມັນ​ຕົວ​ເອງ​? ແລະຄໍາຕອບແມ່ນບາງສ່ວນທາງວິຊາການແລະສ່ວນຫນຶ່ງແມ່ນອົງການຈັດຕັ້ງ.

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

ມັນງ່າຍ ຫຼື ຍາກປານໃດ? ນີ້, ແນ່ນອນ, ສາມາດເຮັດໄດ້ດ້ວຍມື. ແຕ່ມັນບໍ່ງ່າຍດາຍ, ເພາະວ່າພວກເຮົາມີຄວາມຊັບຊ້ອນໃນການຄຸ້ມຄອງ Kubernetes ຕົວຂອງມັນເອງ, ແຕ່ໃນເວລາດຽວກັນ, ສະເພາະຂອງ ClickHouse ແມ່ນ superimposed. ແລະຜົນໄດ້ຮັບການລວບລວມດັ່ງກ່າວ.

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

ດ້ວຍການຕັ້ງຄ່າແບບເຄື່ອນໄຫວ, ClickHouse ມີບັນຫາຫຼາຍຢ່າງທີ່ສ້າງການໂຫຼດຄົງທີ່ໃນ DevOps:

• ເມື່ອພວກເຮົາຕ້ອງການປ່ຽນບາງສິ່ງບາງຢ່າງໃນ ClickHouse, ຕົວຢ່າງ, ເພີ່ມ replica ຫຼື shard, ຫຼັງຈາກນັ້ນພວກເຮົາຈໍາເປັນຕ້ອງຈັດການການຕັ້ງຄ່າ.
• ຫຼັງຈາກນັ້ນ, ມີການປ່ຽນແປງ schema ຂໍ້ມູນ, ເນື່ອງຈາກວ່າ ClickHouse ມີວິທີການ sharding ສະເພາະ. ຢູ່ທີ່ນັ້ນ, ທ່ານຈໍາເປັນຕ້ອງຈັດວາງແຜນວາດຂໍ້ມູນ, ຈັດວາງການຕັ້ງຄ່າ.
• ທ່ານຈໍາເປັນຕ້ອງໄດ້ຕັ້ງຄ່າການຕິດຕາມ.
• ການ​ເກັບ​ກໍາ​ຂໍ້​ມູນ​ສໍາ​ລັບ​ການ shards ໃຫມ່​, ສໍາ​ລັບ​ການ replicas ໃຫມ່​.
• ດູແລການຟື້ນຟູ.
• ແລະຣີສະຕາດ.

ເຫຼົ່ານີ້ແມ່ນວຽກງານປົກກະຕິທີ່ຂ້ອຍຢາກເຮັດໃຫ້ງ່າຍຕໍ່ການໃຊ້.

Kubernetes ຕົວຂອງມັນເອງຊ່ວຍໄດ້ດີໃນການດໍາເນີນງານ, ແຕ່ກ່ຽວກັບລະບົບພື້ນຖານ.

Kubernetes ແມ່ນດີໃນການອໍານວຍຄວາມສະດວກ ແລະອັດຕະໂນມັດສິ່ງຕ່າງໆເຊັ່ນ:

• ການຟື້ນຕົວ.
• ເລີ່ມ​ຕົ້ນ​ໃຫມ່.
• ການຄຸ້ມຄອງລະບົບການເກັບຮັກສາ.

ນັ້ນແມ່ນດີ, ນັ້ນແມ່ນທິດທາງທີ່ຖືກຕ້ອງ, ແຕ່ລາວບໍ່ມີຂໍ້ຄຶດຢ່າງສົມບູນກ່ຽວກັບວິທີການປະຕິບັດງານກຸ່ມຖານຂໍ້ມູນ.

ພວກເຮົາຕ້ອງການເພີ່ມເຕີມ, ພວກເຮົາຕ້ອງການໃຫ້ຖານຂໍ້ມູນທັງຫມົດເຮັດວຽກຢູ່ໃນ Kubernetes.

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

ແລະພວກເຮົາໄດ້ພະຍາຍາມແກ້ໄຂທີ່ຈະຊ່ວຍໃຫ້ວຽກງານງ່າຍຂຶ້ນ. ນີ້ແມ່ນ ClickHouse-operator ສໍາລັບ Kubernetes ຈາກ Altinity.

ຜູ້ປະກອບການແມ່ນໂຄງການທີ່ວຽກງານຕົ້ນຕໍແມ່ນການຄຸ້ມຄອງໂຄງການອື່ນໆ, i.e. ມັນເປັນຜູ້ຈັດການ.

ແລະມັນປະກອບດ້ວຍຮູບແບບຂອງພຶດຕິກໍາ. ທ່ານ​ສາ​ມາດ​ໂທ​ຫາ​ຄວາມ​ຮູ້​ທີ່​ລະ​ອຽດ​ນີ້​ກ່ຽວ​ກັບ​ວິ​ຊາ​ການ​.

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

ແລະພຽງແຕ່ຜູ້ປະຕິບັດງານແມ່ນຜູ້ຊ່ວຍຫຸ່ນຍົນທີ່ຈັດການກັບ microtasks ແລະຊ່ວຍ DevOps.

ເປັນຫຍັງທ່ານຕ້ອງການຜູ້ປະກອບການ? ລາວປະຕິບັດໄດ້ດີໂດຍສະເພາະໃນສອງດ້ານ:

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

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

ວິທີການທີ່ອີງໃສ່ຜູ້ປະກອບການແຕກຕ່າງຈາກລະບົບອື່ນໆແນວໃດ? ມີ Helm. ມັນຍັງຊ່ວຍຕິດຕັ້ງ ClickHouse; ທ່ານສາມາດແຕ້ມຕາຕະລາງ helm, ເຊິ່ງເຖິງແມ່ນວ່າຈະຕິດຕັ້ງກຸ່ມ ClickHouse ທັງຫມົດ. ຫຼັງຈາກນັ້ນແມ່ນຫຍັງຄືຄວາມແຕກຕ່າງລະຫວ່າງຜູ້ປະຕິບັດການແລະດຽວກັນ, ຕົວຢ່າງ, Helm?

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

ນັ້ນແມ່ນສ່ວນທີ່ແນະນໍາ, ໃຫ້ເຮົາກ້າວຕໍ່ໄປ.

ພວກເຮົາຈະສ້າງຕົວປະຕິບັດການຂອງພວກເຮົາແນວໃດ? ພວກເຮົາກໍາລັງພະຍາຍາມເຂົ້າຫາບັນຫາເພື່ອຈັດການກຸ່ມ ClickHouse ເປັນຊັບພະຍາກອນດຽວ.

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

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

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

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

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

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

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

ພວກເຮົາສ້າງ manifesto ນີ້. ພວກເຮົາໃຫ້ອາຫານມັນໃຫ້ກັບຜູ້ປະກອບການຂອງພວກເຮົາ. ລາວເຮັດວຽກ, ລາວເຮັດ magic.

ພວກເຮົາເບິ່ງຢູ່ໃນ console ໄດ້. ສາມອົງປະກອບທີ່ມີຄວາມສົນໃຈ: Pod, ສອງການບໍລິການ, ແລະ StatefulSet.

ຜູ້ປະຕິບັດງານໄດ້ເຮັດວຽກ, ແລະພວກເຮົາສາມາດເຫັນໄດ້ວ່າລາວສ້າງຫຍັງ.

ລາວສ້າງບາງສິ່ງບາງຢ່າງເຊັ່ນນີ້. ພວກເຮົາມີ StatefulSet, Pod, ConfigMap ສໍາລັບແຕ່ລະ replica, ConfigMap ສໍາລັບກຸ່ມທັງຫມົດ. ບໍລິການແມ່ນຕ້ອງການເປັນຈຸດເຂົ້າໄປໃນກຸ່ມ.

ການບໍລິການແມ່ນການບໍລິການ Balancer Load ສູນກາງແລະຍັງສາມາດຖືກນໍາໃຊ້ສໍາລັບແຕ່ລະ replica, ສໍາລັບແຕ່ລະ shard.

ກຸ່ມພື້ນຖານຂອງພວກເຮົາມີລັກສະນະຄ້າຍຄືນີ້. ມັນແມ່ນມາຈາກຂໍ້ດຽວ.

ໃຫ້ເຮົາໄປຕື່ມອີກ ແລະຊັບຊ້ອນສິ່ງຕ່າງໆ. ພວກເຮົາຈໍາເປັນຕ້ອງໄດ້ແຍກກຸ່ມ.

ວຽກ​ງານ​ຂອງ​ພວກ​ເຮົາ​ມີ​ການ​ຂະ​ຫຍາຍ​ຕົວ​, ນະ​ໂຍ​ບາຍ​ດ້ານ​ການ​ເລີ່ມ​ຕົ້ນ​. ພວກເຮົາຕ້ອງການເພີ່ມ shard. ພວກເຮົາປະຕິບັດຕາມການພັດທະນາ. ພວກເຮົາກໍາລັງປ່ຽນແປງສະເພາະຂອງພວກເຮົາ. ພວກເຮົາຊີ້ໃຫ້ເຫັນວ່າພວກເຮົາຕ້ອງການສອງ shards.

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

ພວກເຮົາໃຫ້ອາຫານແກ່ຕົວປະຕິບັດການ YAML ແລະເບິ່ງວ່າມີຫຍັງເກີດຂື້ນ.

ຜູ້ປະຕິບັດການຄິດແລະສ້າງຫນ່ວຍງານດັ່ງຕໍ່ໄປນີ້. ພວກເຮົາມີສອງ Pods, ສາມບໍລິການແລະ, ທັນທີທັນໃດ, 2 StatefulSets. ເປັນຫຍັງ 2 StatefulSets?

ໃນແຜນວາດມັນເປັນແບບນີ້ - ນີ້ແມ່ນສະພາບເບື້ອງຕົ້ນຂອງພວກເຮົາ, ເມື່ອພວກເຮົາມີຝັກຫນຶ່ງ.

ມັນໄດ້ກາຍເປັນແບບນີ້. ມາຮອດປະຈຸ, ທຸກສິ່ງທຸກຢ່າງແມ່ນງ່າຍດາຍ, ມັນໄດ້ຖືກຊ້ໍາກັນ.

ແລະເປັນຫຍັງມັນຈຶ່ງກາຍເປັນ StatefulSets ສອງອັນ? ທີ່ນີ້ພວກເຮົາຈໍາເປັນຕ້ອງໄດ້ digress ແລະປຶກສາຫາລືຄໍາຖາມຂອງວິທີການ Pods ໄດ້ຖືກຄຸ້ມຄອງໃນ Kubernetes.

ມີວັດຖຸທີ່ເອີ້ນວ່າ StatefulSet ທີ່ອະນຸຍາດໃຫ້ທ່ານສ້າງຊຸດຂອງ Pods ຈາກແມ່ແບບ. ປັດໃຈສໍາຄັນຢູ່ທີ່ນີ້ແມ່ນແມ່ແບບ. ແລະທ່ານສາມາດເປີດຕົວ Pods ຈໍານວນຫຼາຍໂດຍໃຊ້ແມ່ແບບດຽວໃນ StatefulSet ດຽວ. ແລະປະໂຫຍກທີ່ສໍາຄັນຢູ່ທີ່ນີ້ແມ່ນ "Pods ຫຼາຍສໍາລັບແມ່ແບບດຽວ."

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

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

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

ໃຫ້ກັບຄືນໄປຫາບັນຫາພາກປະຕິບັດ. ໃນກຸ່ມຂອງພວກເຮົາ, ພວກເຮົາຈໍາເປັນຕ້ອງໄດ້ configure ຜູ້ໃຊ້, i.e. ທ່ານຈໍາເປັນຕ້ອງເຮັດບາງການຕັ້ງຄ່າຂອງ ClickHouse ໃນ Kubernetes. ຜູ້ປະກອບການສະຫນອງຄວາມເປັນໄປໄດ້ທັງຫມົດສໍາລັບການນີ້.

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

ເຈົ້າສາມາດຂຽນແບບນີ້ໄດ້. ນີ້ແມ່ນຕົວຢ່າງ. ລະຫັດຜ່ານສາມາດເຂົ້າລະຫັດໄດ້. ຢ່າງແທ້ຈິງທາງເລືອກການຕັ້ງຄ່າ ClickHouse ທັງຫມົດແມ່ນສະຫນັບສະຫນູນ. ນີ້ແມ່ນພຽງແຕ່ຕົວຢ່າງ.

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

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

ພວກເຮົາຕ້ອງການຫຍັງສໍາລັບການຈໍາລອງ?

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

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

ແລະແຜນວາດການໂຕ້ຕອບຂອງລະບົບທັງຫມົດ turns ອອກເຊັ່ນນີ້. ພວກເຮົາມີ Kubernetes ເປັນເວທີ. ມັນປະຕິບັດຕົວປະຕິບັດການ ClickHouse. ຂ້ອຍໄດ້ຮູບ ZooKeeper ຢູ່ທີ່ນີ້. ແລະຜູ້ປະຕິບັດການພົວພັນກັບທັງ ClickHouse ແລະ ZooKeeper. ນັ້ນແມ່ນ, ຜົນໄດ້ຮັບການໂຕ້ຕອບ.

ແລະທັງຫມົດນີ້ແມ່ນມີຄວາມຈໍາເປັນສໍາລັບ ClickHouse ເພື່ອສົບຜົນສໍາເລັດ replicate ຂໍ້ມູນໃນ k8s.

ຕອນນີ້ໃຫ້ເບິ່ງຫນ້າວຽກຂອງມັນເອງ, ໃນສິ່ງທີ່ manifest ສໍາລັບການຈໍາລອງຈະມີລັກສະນະແນວໃດ.

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

ມັນເປັນແບບນີ້.

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

ແລະມັນເຖິງເວລາທີ່ຈະເພີ່ມວຽກງານຕໍ່ໄປ. ພວກເຮົາຈະເພີ່ມການເກັບຮັກສາແບບຄົງທີ່.

ສໍາລັບການເກັບຮັກສາຄົງທີ່ພວກເຮົາມີທາງເລືອກຕ່າງໆ.

ຖ້າພວກເຮົາກໍາລັງເຮັດວຽກຢູ່ໃນຜູ້ໃຫ້ບໍລິການຟັງ, ຕົວຢ່າງເຊັ່ນ, ການນໍາໃຊ້ Amazon, Google, ຫຼັງຈາກນັ້ນມີການລໍ້ລວງທີ່ດີທີ່ຈະໃຊ້ການເກັບຮັກສາຟັງ. ມັນສະດວກຫຼາຍ, ມັນດີ.

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

ມາເບິ່ງສິ່ງທີ່ພວກເຮົາມີກ່ຽວກັບການເກັບຮັກສາຟັງ.

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

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

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

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

Kubernetes ສະໜອງສິ່ງຫຍໍ້ທໍ້ສາມຢ່າງສຳລັບການນຳໃຊ້ບ່ອນເກັບຂໍ້ມູນໃນທ້ອງຖິ່ນໃນ Kubernetes. ນີ້:

• EmptyDir
• HostPath.
• ທ້ອງຖິ່ນ

ຂໍໃຫ້ພິຈາລະນາເບິ່ງວ່າພວກມັນແຕກຕ່າງກັນແນວໃດແລະມັນຄ້າຍຄືກັນແນວໃດ.

ກ່ອນອື່ນ ໝົດ, ໃນທັງສາມວິທີການທີ່ພວກເຮົາມີບ່ອນເກັບມ້ຽນ - ເຫຼົ່ານີ້ແມ່ນແຜ່ນທ້ອງຖິ່ນທີ່ຕັ້ງຢູ່ໃນ node k8s ທາງດ້ານຮ່າງກາຍດຽວກັນ. ແຕ່ພວກເຂົາມີຄວາມແຕກຕ່າງບາງຢ່າງ.

ໃຫ້ເລີ່ມຕົ້ນດ້ວຍອັນທີ່ງ່າຍດາຍທີ່ສຸດ, i.e. emptyDir. ນີ້ແມ່ນຫຍັງໃນການປະຕິບັດ? ໃນສະເພາະຂອງພວກເຮົາ, ພວກເຮົາຂໍໃຫ້ລະບົບບັນຈຸ (ສ່ວນຫຼາຍແມ່ນ Docker) ໃຫ້ພວກເຮົາເຂົ້າເຖິງໂຟນເດີໃນແຜ່ນທ້ອງຖິ່ນ.

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

ການເຮັດວຽກນີ້ຈະມີປະສິດທິພາບແນວໃດ? ນີ້ຈະເຮັດວຽກຢູ່ທີ່ຄວາມໄວຂອງແຜ່ນທ້ອງຖິ່ນ, i.e. ນີ້ແມ່ນການເຂົ້າເຖິງສະກູຂອງທ່ານຢ່າງເຕັມທີ່.

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

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

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

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

ຍັງມີຂໍ້ເສຍປຽບ. ນີ້ແມ່ນຄວາມສັບສົນຂອງການຄຸ້ມຄອງ. Kubernetes ຂອງພວກເຮົາອາດຈະຕ້ອງການຍ້າຍ Pod ໄປຫາ node ອື່ນ. ແລະນີ້ແມ່ນບ່ອນທີ່ DevOps ເຂົ້າມາຫຼິ້ນ. ລາວຕ້ອງອະທິບາຍຢ່າງຖືກຕ້ອງກັບລະບົບທັງຫມົດວ່າ pods ເຫຼົ່ານີ້ພຽງແຕ່ສາມາດຍ້າຍໄປທີ່ nodes ທີ່ທ່ານມີບາງສິ່ງບາງຢ່າງ mounted ຕາມເສັ້ນທາງເຫຼົ່ານີ້, ແລະບໍ່ມີຫຼາຍກ່ວາຫນຶ່ງ node ໃນເວລານັ້ນ. ມັນຂ້ອນຂ້າງຍາກ.

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

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

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

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

ຫຼັງຈາກນີ້, k8s ຈະຮ້ອງຂໍການເກັບຮັກສາ. ຈະຈັດສັນມັນໃຫ້ພວກເຮົາຢູ່ໃນ StatefulSet. ແລະໃນທີ່ສຸດມັນຈະຢູ່ໃນການກໍາຈັດ ClickHouse.

ພວກເຮົາມີໂຄງການນີ້. ການເກັບຮັກສາແບບຄົງທີ່ຂອງພວກເຮົາແມ່ນສີແດງ, ເຊິ່ງເບິ່ງຄືວ່າມັນຈໍາເປັນຕ້ອງເຮັດ.

ແລະມັນປ່ຽນເປັນສີຂຽວ. ຕອນນີ້ໂຄງການກຸ່ມ ClickHouse ຢູ່ໃນ k8s ແມ່ນສໍາເລັດສົມບູນແລ້ວ. ພວກເຮົາມີ shards, replicas, ZooKeeper, ພວກເຮົາມີ Persistent ທີ່ແທ້ຈິງ, ເຊິ່ງຖືກປະຕິບັດໃນທາງຫນຶ່ງຫຼືອື່ນ. ໂຄງ​ການ​ດັ່ງ​ກ່າວ​ແມ່ນ​ມີ​ການ​ປະ​ຕິ​ບັດ​ຢ່າງ​ເຕັມ​ທີ່​.

ພວກເຮົາສືບຕໍ່ດໍາລົງຊີວິດ. ກຸ່ມຂອງພວກເຮົາກໍາລັງພັດທະນາ. ແລະ Alexey ພະຍາຍາມ, ແລະປ່ອຍເວີຊັນໃຫມ່ຂອງ ClickHouse.

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

ພວກເຮົາສາມາດເວົ້າຫຍັງກ່ຽວກັບເລື່ອງນີ້?

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

ໃຫ້ເຂົ້າໄປເລິກເຂົ້າໄປອີກໜ້ອຍໜຶ່ງ. ກ່ອນນີ້, ພວກເຮົາໄດ້ເວົ້າກ່ຽວກັບວິທີການ ClickHouse-operator ເຮັດວຽກທີ່ກ່ຽວຂ້ອງກັບສະເພາະຂອງ ClickHouse.

ຕອນນີ້ຂ້ອຍຢາກເວົ້າສອງສາມຄໍາກ່ຽວກັບວິທີການປະຕິບັດການໃດໆໂດຍທົ່ວໄປ, ເຊັ່ນດຽວກັນກັບວິທີທີ່ມັນພົວພັນກັບ K8s.

ໃຫ້ເບິ່ງການພົວພັນກັບ K8s ກ່ອນ. ຈະເກີດຫຍັງຂຶ້ນເມື່ອພວກເຮົາໃຊ້ kubectl? ວັດຖຸຂອງພວກເຮົາປາກົດຢູ່ໃນ etcd ຜ່ານ API.

ຕົວຢ່າງ, ວັດຖຸ Kubernetes ພື້ນຖານ: pod, StatefulSet, ບໍລິການ, ແລະອື່ນໆລົງບັນຊີລາຍຊື່.

ໃນເວລາດຽວກັນ, ບໍ່ມີຫຍັງເກີດຂຶ້ນທາງດ້ານຮ່າງກາຍ. ວັດຖຸເຫຼົ່ານີ້ຕ້ອງຖືກສ້າງຢູ່ໃນກຸ່ມ.

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

ແລະມັນເຮັດໃຫ້ວັດຖຸຂອງພວກເຮົາຢູ່ໃນ K8s.

ແຕ່ພວກເຮົາຕ້ອງການທີ່ຈະປະຕິບັດງານບໍ່ພຽງແຕ່ມີຝັກແລະ StatefulSets, ພວກເຮົາຕ້ອງການສ້າງ ClickHouseInstallation, i.e. ວັດຖຸຂອງປະເພດ ClickHouse, ເພື່ອດໍາເນີນການກັບມັນທັງຫມົດ. ມາຮອດປະຈຸບັນບໍ່ມີຄວາມເປັນໄປໄດ້ດັ່ງກ່າວ.

ແຕ່ K8s ມີສິ່ງດີໆຕໍ່ໄປນີ້. ພວກເຮົາຕ້ອງການໃຫ້ພວກເຮົາມີບ່ອນໃດຫນຶ່ງເຊັ່ນ: ຫນ່ວຍງານທີ່ຊັບຊ້ອນນີ້ທີ່ກຸ່ມຂອງພວກເຮົາຈະຖືກລວບລວມຈາກ pods ແລະ StatefulSet.

ແລະສິ່ງທີ່ຕ້ອງເຮັດສໍາລັບການນີ້? ຫນ້າທໍາອິດ, Custom Resource Definition ເຂົ້າມາໃນຮູບ. ມັນ​ແມ່ນ​ຫຍັງ? ນີ້ແມ່ນຄໍາອະທິບາຍສໍາລັບ K8s, ວ່າທ່ານຈະມີຂໍ້ມູນອີກຫນຶ່ງປະເພດ, ທີ່ພວກເຮົາຕ້ອງການເພີ່ມຊັບພະຍາກອນທີ່ກໍາຫນົດເອງໃສ່ຝັກ, StatefulSet, ເຊິ່ງຈະສັບສົນພາຍໃນ. ນີ້ແມ່ນລາຍລະອຽດຂອງໂຄງສ້າງຂໍ້ມູນ.

ພວກເຮົາຍັງສົ່ງໄປທີ່ນັ້ນໂດຍຜ່ານ kubectl ສະຫມັກ. Kubernetes ເອົາມັນຢ່າງມີຄວາມສຸກ.

ແລະໃນປັດຈຸບັນຢູ່ໃນບ່ອນເກັບມ້ຽນຂອງພວກເຮົາ, ວັດຖຸໃນ etcd ມີໂອກາດທີ່ຈະບັນທຶກຊັບພະຍາກອນທີ່ກໍາຫນົດເອງທີ່ເອີ້ນວ່າ ClickHouseInstallation.

ແຕ່ສໍາລັບໃນປັດຈຸບັນບໍ່ມີຫຍັງຕໍ່ໄປອີກແລ້ວຈະເກີດຂຶ້ນ. ນັ້ນແມ່ນ, ຖ້າພວກເຮົາສ້າງໄຟລ໌ YAML ທີ່ພວກເຮົາເບິ່ງການອະທິບາຍ shards ແລະ replicas ແລະເວົ້າວ່າ "kubectl ນໍາໃຊ້," ຫຼັງຈາກນັ້ນ Kubernetes ຈະຍອມຮັບມັນ, ເອົາໃສ່ໃນ etcd ແລະເວົ້າວ່າ: "ດີ, ແຕ່ຂ້ອຍບໍ່ຮູ້ວ່າຈະເຮັດແນວໃດ. ກັບ​ມັນ. ຂ້ອຍບໍ່ຮູ້ວິທີຮັກສາ ClickHouseInstallation."

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

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

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

ຜູ້ປະກອບການເຮັດວຽກແນວໃດ? ໃຫ້ເບິ່ງເບື້ອງຂວາເພື່ອເບິ່ງວ່າລາວເຮັດແນວໃດ. ຂໍໃຫ້ຊອກຫາວິທີທີ່ຜູ້ປະຕິບັດການເຮັດໃຫ້ສິ່ງທັງຫມົດນີ້ແລະວິທີການພົວພັນກັບ K8s ຕື່ມອີກ.

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

ຜູ້ປະກອບການລົງທະບຽນກັບເຫດການຕ່າງໆແລະຕ້ອງເຮັດບາງປະຕິກິລິຍາ. ວຽກງານຂອງມັນແມ່ນເພື່ອຕອບສະຫນອງຕໍ່ເຫດການທີ່ເກີດຂື້ນ.

ເຫດການແມ່ນສ້າງຂຶ້ນໂດຍການປັບປຸງທີ່ແນ່ນອນ. ໄຟລ໌ YAML ຂອງພວກເຮົາທີ່ມີລາຍລະອຽດຂອງ ClickHouseInstallation ມາຮອດ. ລາວໄດ້ໄປຫາ etcd ຜ່ານ kubectl ສະຫມັກ. ເຫດການຫນຶ່ງໄດ້ເກີດຂຶ້ນຢູ່ທີ່ນັ້ນ, ແລະເປັນຜົນມາຈາກເຫດການນີ້ໄດ້ມາຮອດ ClickHouse-operator. ຜູ້ປະກອບການໄດ້ຮັບຄໍາອະທິບາຍນີ້. ແລະລາວຕ້ອງເຮັດບາງສິ່ງບາງຢ່າງ. ຖ້າການອັບເດດມາຮອດສໍາລັບ ClickHouseInstallation object, ຫຼັງຈາກນັ້ນທ່ານຈໍາເປັນຕ້ອງໄດ້ປັບປຸງ cluster. ແລະວຽກງານຂອງຜູ້ປະຕິບັດງານແມ່ນການປັບປຸງກຸ່ມ.

ລາວເຮັດຫຍັງ? ກ່ອນອື່ນ ໝົດ, ພວກເຮົາ ຈຳ ເປັນຕ້ອງສ້າງແຜນການປະຕິບັດງານ ສຳ ລັບສິ່ງທີ່ພວກເຮົາຈະເຮັດກັບການປັບປຸງນີ້. ການປັບປຸງສາມາດມີຂະຫນາດນ້ອຍຫຼາຍ, i.e. ຂະຫນາດນ້ອຍໃນການປະຕິບັດ YAML, ແຕ່ສາມາດມີການປ່ຽນແປງຂະຫນາດໃຫຍ່ຫຼາຍໃນກຸ່ມ. ດັ່ງນັ້ນ, ຜູ້ປະກອບການສ້າງແຜນການ, ແລະຫຼັງຈາກນັ້ນລາວຕິດກັບມັນ.

ອີງຕາມແຜນການນີ້, ລາວເລີ່ມຕົ້ນທີ່ຈະແຕ່ງກິນໂຄງສ້າງນີ້ພາຍໃນເພື່ອການຜະລິດເປັນຝັກ, ການບໍລິການ, i.e. ເຮັດໃນສິ່ງທີ່ວຽກງານຕົ້ນຕໍຂອງລາວແມ່ນ. ນີ້ແມ່ນວິທີການສ້າງກຸ່ມ ClickHouse ໃນ Kubernetes.

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

Kubernetes ແມ່ນຮັບຜິດຊອບສໍາລັບສິ່ງທີ່ລະບົບ, i.e. ສໍາລັບຊຸດພື້ນຖານຂອງວັດຖຸທີ່ສາມາດຖືກຕີຄວາມວ່າລະບົບຂອບເຂດ. Kubernetes ຮູ້ວິທີການເປີດຕົວ pods, ວິທີການ restart containers, ວິທີການ mount volumes, ວິທີການເຮັດວຽກກັບ ConfigMap, i.e. ທຸກສິ່ງທຸກຢ່າງທີ່ສາມາດເອີ້ນວ່າລະບົບ.

ຜູ້ປະກອບການດໍາເນີນການຢູ່ໃນໂດເມນ. ແຕ່ລະຕົວປະຕິບັດການແມ່ນສ້າງຂຶ້ນສໍາລັບສາຂາວິຊາຂອງຕົນເອງ. ພວກເຮົາໄດ້ເຮັດມັນສໍາລັບ ClickHouse.

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

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

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

ລາວໄດ້ກະກຽມມັນທັງຫມົດແລະສົ່ງມັນໄປຫາ K8s. ລາວບອກວ່າລາວຕ້ອງການ ConfigMap, StatefulSet, Volume. Kubernetes ເຮັດວຽກ. ລາວ materializes ຫນ່ວຍງານພື້ນຖານທີ່ລາວດໍາເນີນການ.

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

ແລະພຽງແຕ່ຫຼັງຈາກນັ້ນ ClickHouse ຕົວຂອງມັນເອງເຂົ້າມາຫຼິ້ນ, i.e. ໜ່ວຍ​ງານ​ລະດັບ​ສູງ​ອື່ນ. ນີ້ແມ່ນຖານຂໍ້ມູນແລ້ວ. ມັນ​ມີ​ຕົວ​ຢ່າງ​ຂອງ​ຕົນ​ເອງ, replica ໄດ້​ກໍາ​ນົດ​ຄ່າ​ອື່ນ​ທີ່​ພ້ອມ​ທີ່​ຈະ​ເຂົ້າ​ຮ່ວມ​ກຸ່ມ.

ມັນ turns ໃຫ້ເຫັນວ່າລະບົບຕ່ອງໂສ້ການປະຕິບັດແລະການແບ່ງຄວາມຮັບຜິດຊອບໃນເວລາທີ່ເພີ່ມ replica ແມ່ນຂ້ອນຂ້າງຍາວ.

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

ພວກເຮົາໄດ້ສ້າງມັນເພື່ອໃຫ້ທ່ານສາມາດວາງເຂົ້າໄປໃນ xml ທີ່ມີຢູ່ແລ້ວ, ເຊິ່ງ ClickHouse ເຂົ້າໃຈ.

ທ່ານສາມາດປັບ ClickHouse. ພຽງແຕ່ zoned deployment ແມ່ນສິ່ງທີ່ຂ້າພະເຈົ້າໄດ້ເວົ້າກ່ຽວກັບການອະທິບາຍ hostPath, ການເກັບຮັກສາທ້ອງຖິ່ນ. ນີ້ແມ່ນວິທີການປະຕິບັດ zoned ຢ່າງຖືກຕ້ອງ.

ວຽກງານພາກປະຕິບັດຕໍ່ໄປແມ່ນການຕິດຕາມ.

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

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

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

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

ກຸ່ມຂອງພວກເຮົາພັດທະນາແນວໃດ? ໃນຕອນເລີ່ມຕົ້ນລາວເປັນແບບນັ້ນ.

ແລ້ວລາວກໍເປັນແບບນີ້.

ໃນທີ່ສຸດ, ລາວກາຍເປັນແບບນີ້.

ແລະການຕິດຕາມແມ່ນເຮັດໂດຍອັດຕະໂນມັດໂດຍຜູ້ປະຕິບັດງານ. ຈຸດດຽວຂອງການເຂົ້າ.

ແລະພຽງແຕ່ຢູ່ທີ່ທາງອອກພວກເຮົາເບິ່ງ dashboard Grafana ເພື່ອເບິ່ງວ່າຊີວິດຂອງກຸ່ມຂອງພວກເຮົາແມ່ນຕົ້ມຢູ່ພາຍໃນແນວໃດ.

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

ພວກເຮົາຢາກຈະໄປໃສຕໍ່ໄປ? ນີ້:

• ພັດທະນາອັດຕະໂນມັດການທົດສອບ. ວຽກງານຕົ້ນຕໍແມ່ນການທົດສອບອັດຕະໂນມັດຂອງສະບັບໃຫມ່.
• ພວກເຮົາກໍ່ຕ້ອງການເຮັດໃຫ້ການເຊື່ອມໂຍງເຂົ້າກັບ ZooKeeper ໂດຍອັດຕະໂນມັດ. ແລະມີແຜນທີ່ຈະເຊື່ອມໂຍງກັບ ZooKeeper-operator. ເຫຼົ່ານັ້ນ. ຜູ້ປະກອບການໄດ້ຖືກຂຽນໄວ້ສໍາລັບ ZooKeeper ແລະມັນສົມເຫດສົມຜົນທີ່ທັງສອງປະຕິບັດການເລີ່ມຕົ້ນປະສົມປະສານເພື່ອສ້າງການແກ້ໄຂທີ່ສະດວກກວ່າ.
• ພວກ​ເຮົາ​ຕ້ອງ​ການ​ທີ່​ຈະ​ເຮັດ​ສັນ​ຍານ​ທີ່​ສໍາ​ຄັນ​ທີ່​ຊັບ​ຊ້ອນ​ຫຼາຍ​ຂຶ້ນ​.
• ຂ້າພະເຈົ້າໄດ້ເນັ້ນໃສ່ສີຂຽວວ່າພວກເຮົາກໍາລັງເຂົ້າຫາການສືບທອດຂອງ Templates - DONE, i.e. ກັບການປ່ອຍຕົວປະຕິບັດການຕໍ່ໄປພວກເຮົາຈະມີການສືບທອດຂອງແມ່ແບບ. ນີ້ແມ່ນເຄື່ອງມືທີ່ມີປະສິດທິພາບທີ່ຊ່ວຍໃຫ້ທ່ານສ້າງການຕັ້ງຄ່າທີ່ສັບສົນຈາກຕ່ອນຕ່າງໆ.
• ແລະພວກເຮົາຕ້ອງການອັດຕະໂນມັດຂອງວຽກງານທີ່ຊັບຊ້ອນ. ອັນຕົ້ນຕໍແມ່ນ Re-sharding.

ໃຫ້ເອົາຜົນໄດ້ຮັບລະດັບປານກາງບາງອັນ.

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

ໃນ​ຜົນ​ຜະ​ລິດ​ທີ່​ພວກ​ເຮົາ​ໄດ້​ຮັບ​:

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

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

ຄໍາຕອບແມ່ນທຸກຢ່າງດີ! ຂ້າພະເຈົ້າຈະບໍ່ເຂົ້າໄປໃນລາຍລະອຽດ, ນີ້ແມ່ນຫົວຂໍ້ຂອງບົດລາຍງານແຍກຕ່າງຫາກ.

ແຕ່ມີໂຄງການດັ່ງກ່າວເປັນ TSBS. ຫນ້າທີ່ຕົ້ນຕໍຂອງມັນແມ່ນຫຍັງ? ນີ້ແມ່ນການທົດສອບການປະຕິບັດຖານຂໍ້ມູນ. ນີ້ແມ່ນຄວາມພະຍາຍາມທີ່ຈະປຽບທຽບອົບອຸ່ນກັບອົບອຸ່ນ, ອ່ອນກັບອ່ອນ.

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

ມັນສະຫນັບສະຫນູນຖານຂໍ້ມູນຂະຫນາດໃຫຍ່ແລ້ວ. ຂ້າພະເຈົ້າໄດ້ກໍານົດສາມຕົ້ນຕໍ. ນີ້:

• TimescaleDB.
• InfluxDB.
• ClickHouse.

ການປຽບທຽບຍັງເຮັດດ້ວຍການແກ້ໄຂທີ່ຄ້າຍຄືກັນອື່ນ. ການປຽບທຽບກັບ RedShift. ການປຽບທຽບໄດ້ຖືກເຮັດຢູ່ໃນ Amazon. ClickHouse ຍັງນໍາຫນ້າຂອງທຸກຄົນໃນເລື່ອງນີ້.

ບົດສະຫຼຸບອັນໃດທີ່ສາມາດດຶງອອກມາຈາກສິ່ງທີ່ຂ້ອຍເວົ້າ?

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

ແຫຼ່ງເປີດ - ເຂົ້າຮ່ວມກັບພວກເຮົາ!

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

ຂອບໃຈທຸກທ່ານ!

ຄໍາຖາມຂອງທ່ານ

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

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

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

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

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

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

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

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

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

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

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

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

ຈະເກີດຫຍັງຂຶ້ນຖ້າຕົວປະຕິບັດການຂັດຂ້ອງ ແລະປິດເປີດໃໝ່, ແມ່ນບໍ?

ແມ່ນແລ້ວ. ແລະ​ໃນ​ເວ​ລາ​ນັ້ນ​ເຫດ​ການ​ໄດ້​ມາ​ເຖິງ.

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

ສະບາຍດີ! ຂອບໃຈສໍາລັບບົດລາຍງານ! Dmitry Zavyalov, ບໍລິສັດ Smedova. ມີແຜນທີ່ຈະເພີ່ມຄວາມສາມາດໃນການກໍາຫນົດຄ່າດ້ວຍ haproxy ກັບຜູ້ປະຕິບັດການບໍ? ຂ້ອຍຈະສົນໃຈຕົວດຸ່ນດ່ຽງອື່ນໆນອກເຫນືອຈາກມາດຕະຖານຫນຶ່ງ, ເພື່ອໃຫ້ມັນສະຫລາດແລະເຂົ້າໃຈວ່າ ClickHouse ແມ່ນແທ້ໆ.

ເຈົ້າເວົ້າກ່ຽວກັບ Ingress ບໍ?

ແມ່ນແລ້ວ, ແທນທີ່ Ingress ດ້ວຍ haproxy. ໃນ haproxy ທ່ານສາມາດລະບຸ topology ຂອງ cluster ບ່ອນທີ່ມັນມີ replicas.

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

ມີແລ້ວ.

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

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