Kafka ໃນ Kubernetes ດີບໍ?

ຊົມເຊີຍ, Habr!

ໃນເວລາຫນຶ່ງ, ພວກເຮົາທໍາອິດທີ່ແນະນໍາຫົວຂໍ້ກັບຕະຫຼາດລັດເຊຍ Kafka ແລະສືບຕໍ່ ຕິດຕາມ ສໍາ​ລັບ​ການ​ພັດ​ທະ​ນາ​ຂອງ​ຕົນ​. ໂດຍສະເພາະ, ພວກເຮົາໄດ້ພົບເຫັນຫົວຂໍ້ຂອງການພົວພັນລະຫວ່າງ Kafka ແລະ Kubernetes. ສັງເກດໄດ້ (ແລະຂ້ອນຂ້າງລະມັດລະວັງ) ບົດຄວາມ ຫົວຂໍ້ນີ້ໄດ້ຖືກຈັດພີມມາຢູ່ໃນ blog Confluent ກັບຄືນໄປບ່ອນໃນເດືອນຕຸລາປີທີ່ຜ່ານມາພາຍໃຕ້ການປະພັນຂອງ Gwen Shapira. ມື້ນີ້ພວກເຮົາຢາກດຶງຄວາມສົນໃຈຂອງທ່ານໄປຫາບົດຄວາມທີ່ຜ່ານມາຈາກເດືອນເມສາໂດຍ Johann Gyger, ຜູ້ທີ່, ເຖິງແມ່ນວ່າບໍ່ມີເຄື່ອງຫມາຍຄໍາຖາມຢູ່ໃນຫົວຂໍ້, ກວດເບິ່ງຫົວຂໍ້ໃນລັກສະນະທີ່ຊັດເຈນກວ່າ, ມາພ້ອມກັບຂໍ້ຄວາມທີ່ມີການເຊື່ອມຕໍ່ທີ່ຫນ້າສົນໃຈ. ກະ​ລຸ​ນາ​ອະ​ໄພ​ໃຫ້​ພວກ​ເຮົາ​ການ​ແປ​ພາ​ສາ​ຟຣີ​ຂອງ "chaos monkey​" ຖ້າ​ຫາກ​ວ່າ​ທ່ານ​ສາ​ມາດ​ເຮັດ​ໄດ້​!

ການນໍາສະເຫນີ

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

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

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

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

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

ເວລາຂອງການສໍາເລັດ

ໃຫ້ເວົ້າກ່ຽວກັບສິ່ງພື້ນຖານ - ສະພາບແວດລ້ອມ runtime ຕົວຂອງມັນເອງ

ຂະບວນການ

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

ຫນ່ວຍຄວາມຈໍາ

ນາຍຫນ້າ Kafka ກິນຄວາມຊົງຈໍາ. ຂະຫນາດ JVM heap ປົກກະຕິແລ້ວແມ່ນຈໍາກັດຢູ່ທີ່ 4-5 GB, ແຕ່ທ່ານຍັງຈະຕ້ອງມີຫນ່ວຍຄວາມຈໍາຂອງລະບົບຫຼາຍນັບຕັ້ງແຕ່ Kafka ໃຊ້ cache ຫນ້າຫຼາຍ. ໃນ Kubernetes, ກໍານົດຊັບພະຍາກອນບັນຈຸແລະຂໍ້ຈໍາກັດການຮ້ອງຂໍຕາມຄວາມເຫມາະສົມ.

ຮ້ານເກັບຂໍ້ມູນ

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

ນີ້ແມ່ນເຫດຜົນທີ່ທ່ານຄວນໃຊ້ການເກັບຮັກສາຂໍ້ມູນໃນໄລຍະຍາວ. ໃຫ້ມັນເປັນການເກັບຮັກສາໄລຍະຍາວທີ່ບໍ່ແມ່ນທ້ອງຖິ່ນກັບລະບົບໄຟລ໌ XFS ຫຼື, ຊັດເຈນກວ່ານັ້ນ, ext4. ຢ່າໃຊ້ NFS. ຂ້າພະເຈົ້າໄດ້ເຕືອນທ່ານ. ເວີຊັນ NFS v3 ຫຼື v4 ຈະບໍ່ເຮັດວຽກ. ໃນສັ້ນ, ນາຍຫນ້າ Kafka ຈະຂັດຖ້າມັນບໍ່ສາມາດລຶບໄດເລກະທໍລີຂໍ້ມູນໄດ້ເນື່ອງຈາກບັນຫາ "ການປ່ຽນຊື່ໂງ່" ໃນ NFS. ຖ້າຂ້ອຍບໍ່ໄດ້ເຊື່ອເຈົ້າເທື່ອ, ໃຫ້ລະມັດລະວັງຫຼາຍ ອ່ານບົດຄວາມນີ້. ພື້ນທີ່ເກັບຂໍ້ມູນຄວນຈະບໍ່ແມ່ນຢູ່ໃນທ້ອງຖິ່ນ ເພື່ອໃຫ້ Kubernetes ສາມາດເລືອກ node ໃໝ່ໄດ້ຢ່າງຄ່ອງຕົວຫຼາຍຂື້ນຫຼັງຈາກການປິດເປີດ ຫຼືການຍົກຍ້າຍ.

ເຄືອຂ່າຍ

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

ການຕັ້ງຄ່າ

manifestos ປົກກະຕິ

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

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

ກ່ຽວກັບ ໂຢເລັນ ສະຫນອງຊຸດ manifests ທີ່ສົມບູນແບບເພື່ອຊ່ວຍໃຫ້ທ່ານເລີ່ມຕົ້ນກັບ Kafka ໃນ Kubernetes.

ຕາຕະລາງຫມວກກັນກະທົບ

Helm ເປັນຕົວຈັດການແພັກເກັດສໍາລັບ Kubernetes ທີ່ສາມາດປຽບທຽບກັບຜູ້ຈັດການແພັກເກັດ OS ເຊັ່ນ yum, apt, Homebrew ຫຼື Chocolatey. ມັນເຮັດໃຫ້ມັນງ່າຍທີ່ຈະຕິດຕັ້ງແພັກເກັດຊອຟແວທີ່ກໍານົດໄວ້ລ່ວງຫນ້າທີ່ອະທິບາຍໄວ້ໃນຕາຕະລາງ Helm. ຕາຕະລາງ Helm ທີ່ຖືກເລືອກຢ່າງດີເຮັດໃຫ້ວຽກງານທີ່ຫຍຸ້ງຍາກຂອງວິທີການປັບຄ່າພາລາມິເຕີທັງຫມົດຢ່າງຖືກຕ້ອງເພື່ອໃຊ້ Kafka ໃນ Kubernetes ງ່າຍ. ມີແຜນວາດ Kafka ຫຼາຍ: ຢ່າງເປັນທາງການແມ່ນຕັ້ງຢູ່ ຢູ່ໃນສະພາບ incubator, ມີຫນຶ່ງຈາກ ສັບສົນ, ຫນຶ່ງຫຼາຍ - ຈາກ BitNami.

ຜູ້ປະຕິບັດງານ

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

ໃນບັນຊີ ຜູ້ປະກອບການທີ່ຫນ້າປະຫລາດໃຈ ສອງຜູ້ປະກອບການສໍາລັບ Kafka ໄດ້ຖືກກ່າວເຖິງ. ຫນຶ່ງ​ໃນ​ນັ້ນ - ສະຕຣີມຊີ. ດ້ວຍ Strimzi, ມັນງ່າຍທີ່ຈະເຮັດໃຫ້ກຸ່ມ Kafka ຂອງທ່ານຂຶ້ນ ແລະແລ່ນໃນນາທີ. ເກືອບບໍ່ມີການກຳນົດຄ່າທີ່ຕ້ອງການ, ນອກຈາກນັ້ນ, ຕົວປະຕິບັດການເອງກໍ່ໃຫ້ຄຸນສົມບັດທີ່ດີບາງຢ່າງ, ຕົວຢ່າງ, ການເຂົ້າລະຫັດ TLS point-to-point ພາຍໃນກຸ່ມ. Confluent ຍັງສະຫນອງ ຜູ້ປະກອບການຂອງຕົນເອງ.

ຜະລິດຕະພັນ

ມັນເປັນສິ່ງສໍາຄັນທີ່ຈະທົດສອບການປະຕິບັດໂດຍການປຽບທຽບຕົວຢ່າງ Kafka ຂອງທ່ານ. ການ​ທົດ​ສອບ​ດັ່ງ​ກ່າວ​ຈະ​ຊ່ວຍ​ໃຫ້​ທ່ານ​ຊອກ​ຫາ​ຂໍ້​ບົກ​ຜ່ອງ​ທີ່​ອາດ​ເກີດ​ຂຶ້ນ​ກ່ອນ​ທີ່​ຈະ​ເກີດ​ບັນ​ຫາ​. ໂຊກດີ, Kafka ໃຫ້ສອງເຄື່ອງມືການທົດສອບປະສິດທິພາບແລ້ວ: kafka-producer-perf-test.sh и kafka-consumer-perf-test.sh. ໃຊ້ພວກມັນຢ່າງຫ້າວຫັນ. ສໍາລັບການອ້າງອິງ, ທ່ານສາມາດອ້າງອີງເຖິງຜົນໄດ້ຮັບທີ່ອະທິບາຍໄວ້ໃນ ຕອບນີ້ Jay Kreps, ຫຼືສຸມໃສ່ ການທົບທວນຄືນນີ້ Amazon MSK ໂດຍ Stéphane Maarek.

ການປະຕິບັດງານ

ການຕິດຕາມ

ຄວາມໂປ່ງໃສໃນລະບົບແມ່ນມີຄວາມສໍາຄັນຫຼາຍ - ຖ້າບໍ່ດັ່ງນັ້ນທ່ານຈະບໍ່ເຂົ້າໃຈສິ່ງທີ່ເກີດຂື້ນໃນມັນ. ມື້​ນີ້​ມີ​ຊຸດ​ເຄື່ອງ​ມື​ແຂງ​ທີ່​ສະ​ຫນອງ​ການ​ຕິດ​ຕາມ​ຕົວ​ຊີ້​ວັດ​ໃນ​ແບບ​ພື້ນ​ເມືອງ​ຟັງ​ໄດ້​. ສອງເຄື່ອງມືທີ່ນິຍົມສໍາລັບຈຸດປະສົງນີ້ແມ່ນ Prometheus ແລະ Grafana. Prometheus ສາມາດເກັບກໍາ metrics ຈາກຂະບວນການ Java ທັງຫມົດ (Kafka, Zookeeper, Kafka Connect) ໂດຍໃຊ້ JMX exporter - ໃນວິທີທີ່ງ່າຍທີ່ສຸດ. ຖ້າທ່ານເພີ່ມ cAdvisor metrics, ທ່ານສາມາດເຂົ້າໃຈໄດ້ຢ່າງເຕັມສ່ວນວ່າຊັບພະຍາກອນຖືກນໍາໃຊ້ແນວໃດໃນ Kubernetes.

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

ແຫຼ່ງຂໍ້ມູນ: streamzi.io/docs/master/#kafka_dashboard

ມັນຈະເປັນການດີທີ່ຈະເສີມທັງຫມົດນີ້ດ້ວຍການຕິດຕາມກວດກາລູກຄ້າ (metrics ກ່ຽວກັບຜູ້ບໍລິໂພກແລະຜູ້ຜະລິດ), ເຊັ່ນດຽວກັນກັບການຕິດຕາມ latency (ສໍາລັບເລື່ອງນີ້ມີ. Burrow) ແລະການຕິດຕາມໃນຕອນທ້າຍ - ສໍາລັບການນໍາໃຊ້ນີ້ ຈໍພາບ Kafka.

ການຕັດໄມ້

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

ການທົດສອບການເຮັດວຽກ

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

ກຳລັງອອກອັບເດດ

StatefulSets ສະຫນັບສະຫນູນການປັບປຸງອັດຕະໂນມັດ: ຖ້າທ່ານເລືອກຍຸດທະສາດ RollingUpdate, ແຕ່ລະພາຍໃຕ້ Kafka ຈະຖືກປັບປຸງ. ດ້ວຍວິທີນີ້, ເວລາຢຸດສາມາດຫຼຸດລົງເປັນສູນ.

ການປັບຂະໜາດ

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

ການບໍລິຫານ

ວຽກງານທີ່ກ່ຽວຂ້ອງກັບການຄຸ້ມຄອງກຸ່ມ Kafka ຂອງທ່ານ, ເຊັ່ນ: ການສ້າງຫົວຂໍ້ແລະການມອບຫມາຍໃຫມ່, ສາມາດເຮັດໄດ້ໂດຍໃຊ້ shell scripts ທີ່ມີຢູ່ແລ້ວໂດຍການເປີດການໂຕ້ຕອບເສັ້ນຄໍາສັ່ງໃນ pods ຂອງທ່ານ. ຢ່າງໃດກໍຕາມ, ການແກ້ໄຂນີ້ແມ່ນບໍ່ງາມຫຼາຍ. Strimzi ສະຫນັບສະຫນູນການຈັດການຫົວຂໍ້ໂດຍໃຊ້ຕົວປະຕິບັດການທີ່ແຕກຕ່າງກັນ. ມີບາງຫ້ອງສໍາລັບການປັບປຸງຢູ່ທີ່ນີ້.

Резервноекопированиеивосстановлениеນ

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

ສະຫລຸບ

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

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