ການເຄື່ອນຍ້າຍຂອງ Cassandra ກັບ Kubernetes: ລັກສະນະແລະວິທີແກ້ໄຂ

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

"ຜູ້ໃດສາມາດປົກຄອງແມ່ຍິງກໍ່ສາມາດປົກຄອງລັດໄດ້"

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

• Cassandra ແມ່ນຂຽນໃນ Java.
• Topology Cassandra ປະກອບມີຫຼາຍລະດັບ:
  • ໂນດ - ນຶ່ງຕົວຢ່າງທີ່ນຳໃຊ້ Cassandra;
  • Rack ແມ່ນກຸ່ມຂອງ Cassandra instances, united ໂດຍບາງລັກສະນະ, ຕັ້ງຢູ່ໃນສູນຂໍ້ມູນດຽວກັນ;
  • Datacenter - ການລວບລວມກຸ່ມທັງຫມົດຂອງ Cassandra instances ທີ່ຕັ້ງຢູ່ໃນສູນຂໍ້ມູນຫນຶ່ງ;
  • Cluster ແມ່ນການເກັບກໍາຂອງສູນຂໍ້ມູນທັງຫມົດ.
• Cassandra ໃຊ້ທີ່ຢູ່ IP ເພື່ອກໍານົດ node.
• ເພື່ອເລັ່ງການເຮັດວຽກການຂຽນແລະການອ່ານ, Cassandra ເກັບຮັກສາຂໍ້ມູນບາງຢ່າງໄວ້ໃນ RAM.

ໃນປັດຈຸບັນ - ໄປສູ່ການຍ້າຍໄປ Kubernetes ທີ່ເປັນໄປໄດ້.

ກວດ​ສອບ​ການ​ໂອນ​

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

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

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

ຂຽນແຜນວາດການເຮັດທຸລະກໍາໃນ Cassandra

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

ພວກເຮົາຈະຈັດສັນ PersistentVolume ຂອງພວກເຮົາໃຫ້ກັບແຕ່ລະຝັກ Cassandra

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

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

2. ການຕິດຕາມ

ທາງເລືອກທີ່ບໍ່ມີການໂຕ້ຖຽງ virtually ສໍາລັບການປະຕິບັດການຕິດຕາມໃນ Kubernetes ແມ່ນ Prometheus (ພວກເຮົາໄດ້ເວົ້າກ່ຽວກັບເລື່ອງນີ້ໃນລາຍລະອຽດ ບົດ​ລາຍ​ງານ​ທີ່​ກ່ຽວ​ຂ້ອງ​). Cassandra ເຮັດແນວໃດກັບຜູ້ສົ່ງອອກ metrics ສໍາລັບ Prometheus? ແລະ, ສິ່ງທີ່ສໍາຄັນກວ່ານັ້ນ, ກັບ dashboards ທີ່ກົງກັນສໍາລັບ Grafana?

ຕົວຢ່າງຂອງຮູບລັກສະນະຂອງກາຟໃນ Grafana ສໍາລັບ Cassandra

ມີພຽງແຕ່ສອງຜູ້ສົ່ງອອກ: jmx_exporter и cassandra_exporter.

ພວກເຮົາເລືອກອັນທໍາອິດສໍາລັບຕົວເຮົາເອງເພາະວ່າ:

1. JMX Exporter ກໍາລັງເຕີບໂຕແລະພັດທະນາ, ໃນຂະນະທີ່ Cassandra Exporter ຍັງບໍ່ໄດ້ຮັບການສະຫນັບສະຫນູນຈາກຊຸມຊົນພຽງພໍ. Cassandra Exporter ຍັງບໍ່ຮອງຮັບ Cassandra ລຸ້ນສ່ວນໃຫຍ່.
2. ທ່ານສາມາດດໍາເນີນການມັນເປັນ javaagent ໂດຍການເພີ່ມທຸງ -javaagent:<plugin-dir-name>/cassandra-exporter.jar=--listen=:9180.
3. ມີຫນຶ່ງສໍາລັບລາວ dashboad ພຽງພໍ, ເຊິ່ງບໍ່ເຫມາະສົມກັບ Cassandra Exporter.

3. ການເລືອກ Kubernetes primitives

ອີງຕາມໂຄງສ້າງຂ້າງເທິງຂອງກຸ່ມ Cassandra, ໃຫ້ພະຍາຍາມແປທຸກສິ່ງທຸກຢ່າງທີ່ອະທິບາຍຢູ່ທີ່ນັ້ນເຂົ້າໄປໃນຄໍາທີ່ໃຊ້ Kubernetes:

• Cassandra Node → Pod
• Cassandra Rack → StatefulSet
• Cassandra Datacenter → ສະນຸກເກີຈາກ StatefulSets
• ຄາແຊນດຣາ → ???

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

ປະກາດຊັບພະຍາກອນເພີ່ມເຕີມສຳລັບບັນທຶກ ແລະການແຈ້ງເຕືອນ

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

4. ການກໍານົດຂອງຝັກ

ໃນວັກຂ້າງເທິງ, ພວກເຮົາຕົກລົງເຫັນດີວ່າຫນຶ່ງໂຫນດ Cassandra ຈະເທົ່າກັບຫນຶ່ງຝັກໃນ Kubernetes. ແຕ່ທີ່ຢູ່ IP ຂອງຝັກຈະແຕກຕ່າງກັນໃນແຕ່ລະຄັ້ງ. ແລະການກໍານົດຂອງ node ໃນ Cassandra ແມ່ນອີງໃສ່ທີ່ຢູ່ IP ... ມັນ turns ໃຫ້ເຫັນວ່າຫຼັງຈາກການໂຍກຍ້າຍແຕ່ລະ pod, ກຸ່ມ Cassandra ຈະເພີ່ມ node ໃຫມ່.

ມີທາງອອກ, ແລະບໍ່ພຽງແຕ່ຫນຶ່ງ:

1. ພວກເຮົາສາມາດເກັບຮັກສາບັນທຶກໂດຍຕົວລະບຸເຈົ້າພາບ (UUIDs ທີ່ເປັນເອກະລັກສະເພາະຂອງຕົວຢ່າງ Cassandra) ຫຼືໂດຍທີ່ຢູ່ IP ແລະເກັບຮັກສາມັນທັງຫມົດໃນບາງໂຄງສ້າງ / ຕາຕະລາງ. ວິທີການມີສອງຂໍ້ເສຍປຽບຕົ້ນຕໍ:
   • ຄວາມສ່ຽງຂອງສະພາບການແຂ່ງຂັນທີ່ເກີດຂື້ນຖ້າຫາກວ່າສອງ nodes ຕົກລົງໃນເວລາດຽວກັນ. ຫຼັງຈາກການເພີ່ມຂຶ້ນຂອງ, Cassandra nodes ຈະພ້ອມກັນຮ້ອງຂໍໃຫ້ມີທີ່ຢູ່ IP ຈາກຕາຕະລາງແລະແຂ່ງຂັນສໍາລັບຊັບພະຍາກອນດຽວກັນ.
   • ຖ້າຂໍ້ Cassandra ສູນເສຍຂໍ້ມູນຂອງມັນ, ພວກເຮົາຈະບໍ່ສາມາດລະບຸມັນໄດ້ອີກຕໍ່ໄປ.
2. ການແກ້ໄຂທີສອງເບິ່ງຄືວ່າເປັນການ hack ຂະຫນາດນ້ອຍ, ແຕ່ຢ່າງໃດກໍ່ຕາມ: ພວກເຮົາສາມາດສ້າງບໍລິການທີ່ມີ ClusterIP ສໍາລັບແຕ່ລະ Cassandra node. ມີບັນຫາກັບການປະຕິບັດນີ້:
   • ຖ້າມີຫຼາຍ nodes ໃນກຸ່ມ Cassandra, ພວກເຮົາຈະຕ້ອງສ້າງບໍລິການຫຼາຍ.
   • ຄຸນສົມບັດ ClusterIP ຖືກປະຕິບັດຜ່ານ iptables. ນີ້ສາມາດກາຍເປັນບັນຫາຖ້າຫາກວ່າກຸ່ມ Cassandra ມີຫຼາຍ (1000 ... ຫຼືແມ້ກະທັ້ງ 100?) nodes. ເຖິງແມ່ນວ່າ ການດຸ່ນດ່ຽງໂດຍອີງໃສ່ IPVS ສາມາດແກ້ໄຂບັນຫານີ້ໄດ້.
3. ການແກ້ໄຂທີສາມແມ່ນການນໍາໃຊ້ເຄືອຂ່າຍຂອງ nodes ສໍາລັບ Cassandra nodes ແທນທີ່ຈະເປັນເຄືອຂ່າຍທີ່ອຸທິດຕົນຂອງ pods ໂດຍການເປີດໃຊ້ການຕັ້ງຄ່າ. hostNetwork: true. ວິທີການນີ້ກໍານົດຂໍ້ຈໍາກັດບາງຢ່າງ:
   • ເພື່ອທົດແທນຫົວຫນ່ວຍ. ມັນເປັນສິ່ງຈໍາເປັນທີ່ node ໃຫມ່ຕ້ອງມີທີ່ຢູ່ IP ດຽວກັນກັບອັນທີ່ຜ່ານມາ (ໃນເມຄເຊັ່ນ AWS, GCP ນີ້ແມ່ນເກືອບເປັນໄປບໍ່ໄດ້ທີ່ຈະເຮັດ);
   • ການນໍາໃຊ້ເຄືອຂ່າຍຂອງ nodes cluster, ພວກເຮົາເລີ່ມຕົ້ນທີ່ຈະແຂ່ງຂັນສໍາລັບຊັບພະຍາກອນເຄືອຂ່າຍ. ດັ່ງນັ້ນ, ການວາງຫຼາຍກວ່າຫນຶ່ງຝັກກັບ Cassandra ຢູ່ໃນຫນຶ່ງ cluster node ຈະມີບັນຫາ.

5. ຂໍ້ມູນສຳຮອງ

ພວກເຮົາຕ້ອງການບັນທຶກສະບັບເຕັມຂອງຂໍ້ມູນຂອງ Cassandra node ດຽວຢູ່ໃນຕາຕະລາງ. Kubernetes ສະໜອງຄຸນສົມບັດທີ່ສະດວກໃນການໃຊ້ CronJob, ແຕ່ນີ້ Cassandra ຕົວເອງວາງຄໍາເວົ້າຢູ່ໃນລໍ້ຂອງພວກເຮົາ.

ຂ້ອຍຂໍເຕືອນເຈົ້າວ່າ Cassandra ເກັບຂໍ້ມູນບາງຢ່າງໄວ້ໃນຄວາມຊົງຈໍາ. ເພື່ອເຮັດການສໍາຮອງຂໍ້ມູນຢ່າງເຕັມທີ່, ທ່ານຕ້ອງການຂໍ້ມູນຈາກຫນ່ວຍຄວາມຈໍາ (Memtables) ຍ້າຍໄປ disk (SSTables). ໃນຈຸດນີ້, ໂຫນດ Cassandra ຢຸດເຊົາການຍອມຮັບການເຊື່ອມຕໍ່, ປິດທັງຫມົດຈາກກຸ່ມ.

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

ການແຜ່ກະຈາຍຂອງ tokens ເພື່ອກໍານົດສິ່ງທີ່ຂໍ້ມູນ Cassandra nodes ຮັບຜິດຊອບ

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

set -eu

if [[ -z "$1" ]]; then
  info "Please provide a keyspace"
  exit 1
fi

KEYSPACE="$1"

result=$(nodetool snapshot "${KEYSPACE}")

if [[ $? -ne 0 ]]; then
  echo "Error while making snapshot"
  exit 1
fi

timestamp=$(echo "$result" | awk '/Snapshot directory: / { print $3 }')

mkdir -p /tmp/backup

for path in $(find "/var/lib/cassandra/data/${KEYSPACE}" -name $timestamp); do
  table=$(echo "${path}" | awk -F "[/-]" '{print $7}')
  mkdir /tmp/backup/$table
  mv $path /tmp/backup/$table
done


tar -zcf /tmp/backup.tar.gz -C /tmp/backup .

nodetool clearsnapshot "${KEYSPACE}"

ຕົວຢ່າງຂອງ bash script ສໍາລັບການສໍາຮອງຂໍ້ມູນຈາກຫນຶ່ງ Cassandra node

ວິທີແກ້ໄຂທີ່ກຽມພ້ອມສໍາລັບ Cassandra ໃນ Kubernetes

ປະຈຸບັນນີ້ໃຊ້ອັນໃດເພື່ອນຳໃຊ້ Cassandra ໃນ Kubernetes ແລະອັນໃດທີ່ເໝາະສົມກັບຄວາມຕ້ອງການທີ່ກຳນົດໄວ້?

1. ວິທີແກ້ໄຂໂດຍອີງໃສ່ຕາຕະລາງ StatefulSet ຫຼື Helm

ການນໍາໃຊ້ຟັງຊັນ StatefulSets ພື້ນຖານເພື່ອດໍາເນີນການກຸ່ມ Cassandra ເປັນທາງເລືອກທີ່ດີ. ການນໍາໃຊ້ຕາຕະລາງ Helm ແລະແມ່ແບບ Go, ທ່ານສາມາດໃຫ້ຜູ້ໃຊ້ມີການໂຕ້ຕອບແບບຍືດຫຍຸ່ນສໍາລັບການນໍາໃຊ້ Cassandra.

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

ຕົວແທນ:

• ຕາຕະລາງຈາກບ່ອນເກັບມ້ຽນ Helm ຫຼັກ;
• ຕາຕະລາງຈາກ bitnami.

ຕາຕະລາງທັງສອງແມ່ນດີເທົ່າທຽມກັນ, ແຕ່ຂຶ້ນກັບບັນຫາທີ່ໄດ້ອະທິບາຍຂ້າງເທິງ.

2. ການແກ້ໄຂໂດຍອີງໃສ່ Kubernetes Operator

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

ລະບົບການຈັດການ Node ໃນຕົວປະຕິບັດການ Cassandra ທີ່ຖືກອອກແບບດີ

ໃຫ້ເບິ່ງຜູ້ປະຕິບັດການທີ່ມີຢູ່ແລ້ວ.

1. Cassandra-operator ຈາກ instaclustr

• GitHub
• ຄວາມພ້ອມ: ອັນຟາ
• ໃບອະນຸຍາດ: Apache 2.0
• ປະຕິບັດໃນ: Java

ນີ້​ແມ່ນ​ແທ້​ຈິງ​ແລ້ວ​ເປັນ​ໂຄງ​ການ​ທີ່​ດີ​ທີ່​ສຸດ​ແລະ​ການ​ພັດ​ທະ​ນາ​ຢ່າງ​ຫ້າວ​ຫັນ​ຈາກ​ບໍ​ລິ​ສັດ​ທີ່​ສະ​ຫນອງ​ການ​ຈັດ​ການ Cassandra ການ​ຈັດ​ການ. ມັນ, ດັ່ງທີ່ອະທິບາຍໄວ້ຂ້າງເທິງ, ໃຊ້ຖັງ sidecar ທີ່ຍອມຮັບຄໍາສັ່ງຜ່ານ HTTP. ຂຽນໃນ Java, ບາງຄັ້ງມັນຂາດການທໍາງານທີ່ກ້າວຫນ້າຂອງຫ້ອງສະຫມຸດລູກຄ້າໄປ. ນອກຈາກນີ້, ຜູ້ປະກອບການບໍ່ສະຫນັບສະຫນູນ Racks ທີ່ແຕກຕ່າງກັນສໍາລັບຫນຶ່ງ Datacenter.

ແຕ່ຜູ້ປະຕິບັດການມີຂໍ້ດີເຊັ່ນການສະຫນັບສະຫນູນການຕິດຕາມ, ການຄຸ້ມຄອງກຸ່ມທີ່ມີລະດັບສູງໂດຍໃຊ້ CRD, ແລະແມ້ກະທັ້ງເອກະສານສໍາລັບການເຮັດການສໍາຮອງຂໍ້ມູນ.

2. Navigator ຈາກ Jetstack

• GitHub
• ຄວາມພ້ອມ: ອັນຟາ
• ໃບອະນຸຍາດ: Apache 2.0
• ປະຕິບັດໃນ: Golang

ຖະແຫຼງການທີ່ອອກແບບມາເພື່ອນຳໃຊ້ DB-as-a-Service. ໃນປັດຈຸບັນສະຫນັບສະຫນູນສອງຖານຂໍ້ມູນ: Elasticsearch ແລະ Cassandra. ມັນມີວິທີແກ້ໄຂທີ່ຫນ້າສົນໃຈເຊັ່ນການຄວບຄຸມການເຂົ້າເຖິງຖານຂໍ້ມູນຜ່ານ RBAC (ສໍາລັບການນີ້ມັນມີ navigator-apiserver ແຍກຕ່າງຫາກຂອງຕົນເອງ). ໂຄງການທີ່ຫນ້າສົນໃຈທີ່ຈະມີມູນຄ່າການພິຈາລະນາຢ່າງໃກ້ຊິດ, ແຕ່ວ່າຄໍາຫມັ້ນສັນຍາຄັ້ງສຸດທ້າຍໄດ້ດໍາເນີນເມື່ອຫນຶ່ງປີແລະເຄິ່ງຫນຶ່ງກ່ອນຫນ້ານີ້, ເຊິ່ງຫຼຸດລົງຢ່າງຊັດເຈນທ່າແຮງຂອງມັນ.

3. Cassandra-operator ໂດຍ vgkowski

• GitHub
• ຄວາມພ້ອມ: ອັນຟາ
• ໃບອະນຸຍາດ: Apache 2.0
• ປະຕິບັດໃນ: Golang

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

4. Cassandra-operator ໂດຍ Rook

• GitHub
• ຄວາມພ້ອມ: ອັນຟາ
• ໃບອະນຸຍາດ: Apache 2.0
• ປະຕິບັດໃນ: Golang

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

NB: ພວກເຮົາໃຊ້ຕົວປະຕິບັດການນີ້ດ້ວຍການດັດແປງເລັກນ້ອຍໃນໂຄງການຫນຶ່ງຂອງພວກເຮົາ. ບໍ່ພົບບັນຫາໃດໆໃນການເຮັດວຽກຂອງຜູ້ປະຕິບັດງານໃນໄລຍະເວລາທັງຫມົດຂອງການດໍາເນີນງານ (~ 4 ເດືອນຂອງການດໍາເນີນງານ).

5. CassKop ຈາກສີສົ້ມ

• GitHub
• ຄວາມພ້ອມ: ອັນຟາ
• ໃບອະນຸຍາດ: Apache 2.0
• ປະຕິບັດໃນ: Golang

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

ການຄົ້ນພົບ

ຈໍານວນຂອງວິທີການແລະທາງເລືອກທີ່ເປັນໄປໄດ້ສໍາລັບການ porting Cassandra ກັບ Kubernetes ເວົ້າສໍາລັບຕົວມັນເອງ: ຫົວຂໍ້ແມ່ນຢູ່ໃນຄວາມຕ້ອງການ.

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

ຂ້າ​ພະ​ເຈົ້າ​ຄິດ​ວ່າ​ໃນ​ອະ​ນາ​ຄົດ​ຜູ້​ຍິງ​ກ່ຽວ​ກັບ​ການ​ດັ່ງ​ກ່າວ​ຈະ​ມາ​ໃນ handy!

PS

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

• «ການເຄື່ອນຍ້າຍຂອງ MongoDB ໄປ Kubernetes ແບບບໍ່ຕິດຂັດ"
• «ການເຄື່ອນຍ້າຍຂອງ RabbitMQ ໄປ Kubernetes ແບບບໍ່ຕິດຂັດ"
• «ຖານຂໍ້ມູນ ແລະ Kubernetes (ການທົບທວນ ແລະລາຍງານວິດີໂອ)"
• «ເຄັດລັບ ແລະເຄັດລັບຂອງ K8s: ການເລັ່ງບູດສະເຕດສຳລັບຖານຂໍ້ມູນຂະໜາດໃຫຍ່".

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