ການເກັບຮັກສາຂໍ້ມູນຢູ່ໃນກຸ່ມ Kubernetes

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

ວິທີທີ 1: ລະບຸ PV ໃນ pod manifest

Manifest ປົກກະຕິທີ່ອະທິບາຍ pod ໃນກຸ່ມ Kubernetes:

ພາກສ່ວນຂອງ manifest ທີ່ອະທິບາຍປະລິມານທີ່ເຊື່ອມຕໍ່ແລະບ່ອນທີ່ຖືກເນັ້ນໃສ່ໃນສີ.

ສ່ວນ volumemounts ຊີ້ບອກຈຸດ mount (mountPath) - ໃນໄດເລກະທໍລີພາຍໃນບັນຈຸປະລິມານຖາວອນຈະຖືກຕິດຕັ້ງ, ເຊັ່ນດຽວກັນກັບຊື່ຂອງປະລິມານ.

ສ່ວນ x ລາຍຊື່ປະລິມານທັງໝົດທີ່ໃຊ້ໃນຝັກ. ລະບຸຊື່ຂອງແຕ່ລະປະລິມານ, ເຊັ່ນດຽວກັນກັບປະເພດ (ໃນກໍລະນີຂອງພວກເຮົາ: awsElasticBlockStore) ແລະຕົວກໍານົດການເຊື່ອມຕໍ່. ຕົວກໍານົດການໃດທີ່ລະບຸໄວ້ໃນ manifest ແມ່ນຂຶ້ນກັບປະເພດປະລິມານ.

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

ວິທີການເຊື່ອມຕໍ່ນີ້ໄດ້ຖືກຄິດຄົ້ນໃນຕອນເລີ່ມຕົ້ນ, ເມື່ອ Kubernetes ຢູ່ໃນໄວເດັກ, ແລະໃນມື້ນີ້ວິທີການແມ່ນລ້າສະໄຫມ.

ມີບັນຫາຫຼາຍຢ່າງໃນເວລາໃຊ້ມັນ:

1. ປະລິມານທັງໝົດຕ້ອງຖືກສ້າງດ້ວຍຕົນເອງ; Kubernetes ບໍ່ສາມາດສ້າງອັນໃດໃຫ້ພວກເຮົາໄດ້;
2. ຕົວກໍານົດການການເຂົ້າເຖິງສໍາລັບແຕ່ລະປະລິມານແມ່ນເປັນເອກະລັກ, ແລະພວກເຂົາຕ້ອງໄດ້ຮັບການລະບຸໄວ້ໃນ manifests ຂອງຝັກທັງຫມົດທີ່ໃຊ້ປະລິມານ;
3. ເພື່ອປ່ຽນລະບົບການເກັບຮັກສາ (ຕົວຢ່າງ, ຍ້າຍຈາກ AWS ໄປຫາ Google Cloud), ທ່ານຈໍາເປັນຕ້ອງປ່ຽນການຕັ້ງຄ່າແລະປະເພດຂອງປະລິມານທີ່ຕິດຕັ້ງຢູ່ໃນ manifests ທັງຫມົດ.

ທັງຫມົດນີ້ແມ່ນບໍ່ສະດວກຫຼາຍ, ດັ່ງນັ້ນໃນຄວາມເປັນຈິງວິທີການນີ້ຖືກນໍາໃຊ້ເພື່ອເຊື່ອມຕໍ່ພຽງແຕ່ບາງປະເພດພິເສດຂອງປະລິມານ: configMap, secret, emptyDir, hostPath:

• configMap ແລະຄວາມລັບແມ່ນປະລິມານການບໍລິການທີ່ອະນຸຍາດໃຫ້ທ່ານສ້າງປະລິມານທີ່ມີໄຟລ໌ຈາກ Kubernetes manifests ໃນບັນຈຸ.

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

• hostPath - ຊ່ວຍໃຫ້ທ່ານສາມາດຕິດຕັ້ງໄດເລກະທໍລີໃດໆໃນແຜ່ນທ້ອງຖິ່ນຂອງເຄື່ອງແມ່ຂ່າຍທີ່ແອັບພລິເຄຊັນກໍາລັງແລ່ນຢູ່ໃນກ່ອງບັນຈຸກັບແອັບພລິເຄຊັນ, ລວມທັງ /etc/kubernetes. ນີ້ເປັນຄຸນສົມບັດທີ່ບໍ່ປອດໄພ, ສະນັ້ນ ໂດຍທົ່ວໄປແລ້ວນະໂຍບາຍຄວາມປອດໄພຫ້າມການໃຊ້ປະລິມານຂອງປະເພດນີ້. ຖ້າບໍ່ດັ່ງນັ້ນ, ແອັບພລິເຄຊັນຂອງຜູ້ໂຈມຕີຈະສາມາດຕິດຕັ້ງໄດເຣັກທໍຣີ HTC Kubernetes ພາຍໃນກ່ອງບັນຈຸຂອງມັນ ແລະລັກເອົາໃບຢັ້ງຢືນກຸ່ມທັງໝົດ. ໂດຍປົກກະຕິ, ປະລິມານ hostPath ໄດ້ຖືກອະນຸຍາດໃຫ້ໃຊ້ໂດຍແອັບພລິເຄຊັນລະບົບທີ່ເຮັດວຽກຢູ່ໃນ namespace kube-system.

ລະບົບການເກັບຮັກສາທີ່ Kubernetes ເຮັດວຽກກັບອອກຈາກກ່ອງ ແມ່ນໃຫ້ຢູ່ໃນເອກະສານ.

ວິທີການ 2. ການເຊື່ອມຕໍ່ກັບ SC/PVC/PV hearths

ວິທີການເຊື່ອມຕໍ່ທາງເລືອກແມ່ນແນວຄວາມຄິດຂອງ Storage class, PersistentVolumeClaim, PersistentVolume.

ຫ້ອງຮຽນເກັບຮັກສາ ເກັບຮັກສາຕົວກໍານົດການເຊື່ອມຕໍ່ກັບລະບົບການເກັບຮັກສາຂໍ້ມູນ.

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

ໂດຍເນື້ອແທ້ແລ້ວຂອງແນວຄວາມຄິດ: ໃນ pod manifest ເຂົາເຈົ້າຊີ້ໃຫ້ເຫັນປະລິມານຂອງປະເພດ PersistentVolumeClaim ແລະຊີ້ບອກຊື່ຂອງຫນ່ວຍງານນີ້ໃນຕົວກໍານົດການ claimName.

PersistentVolumeClaim manifest ອະທິບາຍຄວາມຕ້ອງການສໍາລັບປະລິມານຂອງຂໍ້ມູນທີ່ແອັບພລິເຄຊັນຕ້ອງການ. ລວມທັງ:

• ຂະຫນາດແຜ່ນ;
• ວິທີການເຂົ້າເຖິງ: ReadWriteOnce ຫຼື ReadWriteMany;
• link to Storage class - ທີ່ລະບົບການເກັບຮັກສາຂໍ້ມູນພວກເຮົາຕ້ອງການສ້າງປະລິມານ.

ຫ້ອງຮຽນການເກັບຮັກສາ manifest ເກັບຮັກສາປະເພດແລະຕົວກໍານົດການຂອງການເຊື່ອມຕໍ່ກັບລະບົບການເກັບຮັກສາ. cubelet ຕ້ອງການໃຫ້ພວກເຂົາຕິດຕັ້ງປະລິມານໃນ node ຂອງມັນ.

PersistentVolume manifests ຊີ້ບອກຫ້ອງຮຽນ Storage ແລະຕົວກໍານົດການເຂົ້າຫາສໍາລັບປະລິມານສະເພາະ (volume ID, path, ແລະອື່ນໆ).

ເມື່ອສ້າງ PVC, Kubernetes ເບິ່ງວ່າປະລິມານຂະຫນາດໃດແລະຊັ້ນເກັບຮັກສາທີ່ຕ້ອງການ, ແລະເລືອກ PersistentVolume ຟຣີ.

ຖ້າ PVs ດັ່ງກ່າວບໍ່ສາມາດໃຊ້ໄດ້, Kubernetes ສາມາດເປີດຕົວໂຄງການພິເສດ - ຜູ້ສະຫນອງ (ຊື່ຂອງມັນຖືກລະບຸໄວ້ໃນຊັ້ນເກັບຮັກສາ). ໂປລແກລມນີ້ເຊື່ອມຕໍ່ກັບລະບົບການເກັບຮັກສາ, ສ້າງປະລິມານຂອງຂະຫນາດທີ່ຕ້ອງການ, ໄດ້ຮັບຕົວລະບຸແລະສ້າງ PersistentVolume manifest ໃນກຸ່ມ Kubernetes, ເຊິ່ງກ່ຽວຂ້ອງກັບ PersistentVolumeClaim.

ທຸກໆຊຸດຂອງ abstractions ນີ້ຊ່ວຍໃຫ້ທ່ານສາມາດເອົາຂໍ້ມູນກ່ຽວກັບລະບົບການເກັບຮັກສາທີ່ແອັບພລິເຄຊັນເຮັດວຽກກັບຈາກລະດັບ app manifest ໄປຫາລະດັບການບໍລິຫານ.

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

ວິທີທີ່ 3: ການໂຕ້ຕອບການເກັບຮັກສາຕູ້ຄອນເທນເນີ

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

ເພື່ອແກ້ໄຂບັນຫາ, ນັກພັດທະນາຈາກ Cloud Foundry, Kubernetes, Mesos ແລະ Docker ໄດ້ສ້າງການໂຕ້ຕອບການເກັບຮັກສາ Container (CSI) - ການໂຕ້ຕອບແບບປະສົມປະສານແບບງ່າຍດາຍທີ່ອະທິບາຍການໂຕ້ຕອບຂອງລະບົບການຈັດການຕູ້ຄອນເທນເນີແລະໄດເວີພິເສດ (CSI Driver) ທີ່ເຮັດວຽກກັບສະເພາະ. ລະບົບການເກັບຮັກສາ. ລະ​ຫັດ​ທັງ​ຫມົດ​ສໍາ​ລັບ​ການ​ພົວ​ພັນ​ກັບ​ລະ​ບົບ​ການ​ເກັບ​ຮັກ​ສາ​ໄດ້​ຖືກ​ຍ້າຍ​ຈາກ​ຫຼັກ Kubernetes ເປັນ​ລະ​ບົບ​ແຍກ​ຕ່າງ​ຫາກ​.

ເອກະສານການໂຕ້ຕອບການເກັບຮັກສາຕູ້ຄອນເທນເນີ.

ໂດຍປົກກະຕິ, CSI Driver ປະກອບດ້ວຍສອງອົງປະກອບ: Node Plugin ແລະ Controller plugin.

Node Plugin ແລ່ນຢູ່ໃນແຕ່ລະ node ແລະຮັບຜິດຊອບສໍາລັບການ mounting volumes ແລະປະຕິບັດການດໍາເນີນງານກ່ຽວກັບພວກມັນ. ປັ໊ກອິນ Controller ພົວພັນກັບລະບົບການເກັບຮັກສາ: ສ້າງຫຼືລຶບປະລິມານ, ມອບສິດການເຂົ້າເຖິງ, ແລະອື່ນໆ.

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

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

ໃຫ້ພິຈາລະນາຕົວຢ່າງເພື່ອເບິ່ງຜົນປະໂຫຍດທີ່ທ່ານໄດ້ຮັບໂດຍການປ່ຽນໄປສູ່ການເຊື່ອມຕໍ່ລະບົບການເກັບຮັກສາ Ceph ໂດຍໃຊ້ໄດເວີ CSI.

ເມື່ອເຮັດວຽກກັບ Ceph, ປັ໊ກອິນ CSI ສະຫນອງທາງເລືອກຫຼາຍສໍາລັບການເຮັດວຽກກັບລະບົບການເກັບຮັກສາຫຼາຍກ່ວາໄດເວີໃນຕົວ.

1. ການສ້າງແຜ່ນໄດນາມິກ. ໂດຍປົກກະຕິແຜ່ນ RBD ຖືກນໍາໃຊ້ພຽງແຕ່ໃນໂຫມດ RWO, ແຕ່ CSI ສໍາລັບ Ceph ອະນຸຍາດໃຫ້ພວກເຂົາໃຊ້ໃນໂຫມດ RWX. ຝັກຫຼາຍໃນ nodes ທີ່ແຕກຕ່າງກັນສາມາດຕິດຕັ້ງແຜ່ນ RDB ດຽວກັນຢູ່ໃນ nodes ຂອງເຂົາເຈົ້າແລະເຮັດວຽກກັບເຂົາເຈົ້າໃນຂະຫນານ. ເພື່ອໃຫ້ມີຄວາມຍຸຕິທໍາ, ບໍ່ແມ່ນທຸກສິ່ງທຸກຢ່າງຈະສົດໃສ - ແຜ່ນນີ້ສາມາດເຊື່ອມຕໍ່ພຽງແຕ່ເປັນອຸປະກອນບລັອກ, ຊຶ່ງຫມາຍຄວາມວ່າທ່ານຈະຕ້ອງປັບແອັບພລິເຄຊັນເພື່ອເຮັດວຽກກັບມັນໃນຮູບແບບການເຂົ້າເຖິງຫຼາຍ.
2. ການສ້າງພາບຖ່າຍ. ໃນກຸ່ມ Kubernetes, ທ່ານສາມາດສ້າງ manifest ທີ່ມີຄວາມຕ້ອງການເພື່ອສ້າງຮູບຖ່າຍ. plugin CSI ຈະເຫັນມັນແລະຖ່າຍຮູບຈາກແຜ່ນ. ອີງຕາມມັນ, ທ່ານສາມາດເຮັດການສໍາຮອງຂໍ້ມູນຫຼືສໍາເນົາຂອງ PersistentVolume.
3. ການເພີ່ມຂະຫນາດແຜ່ນ ຢູ່ໃນບ່ອນເກັບຂໍ້ມູນ ແລະ PersistentVolume ໃນກຸ່ມ Kubernetes.
4. ໂຄຕ້າ. ໄດເວີ CephFS ທີ່ສ້າງຂຶ້ນໃນ Kubernetes ບໍ່ຮອງຮັບໂຄຕ້າ, ແຕ່ປລັກອິນ CSI ໃໝ່ໆທີ່ມີ Ceph Nautilus ຫຼ້າສຸດສາມາດເປີດໃຊ້ໂຄຕ້າໃນພາທິຊັນ CephFS ໄດ້.
5. ເມຕຣິກ. ປັ໊ກອິນ CSI ສາມາດໃຫ້ Prometheus ມີຄວາມຫລາກຫລາຍຂອງ metrics ກ່ຽວກັບປະລິມານທີ່ເຊື່ອມຕໍ່, ການສື່ສານແມ່ນຫຍັງ, ແລະອື່ນໆ.
6. ຮູ້ຈັກ Topology. ອະນຸຍາດໃຫ້ທ່ານລະບຸໃນ manifests ແນວໃດ cluster ໄດ້ຖືກແຈກຢາຍຕາມພູມສັນຖານ, ແລະຫຼີກເວັ້ນການເຊື່ອມຕໍ່ລະບົບການເກັບຮັກສາທີ່ຢູ່ໃນ Amsterdam ກັບ pods ແລ່ນໃນລອນດອນ.

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

ຜູ້ຂຽນຂອງບົດຄວາມ: Sergey Bondarev, ຝຶກຫັດສະຖາປະນິກຢູ່ Southbridge, ຜູ້ບໍລິຫານ Kubernetes ທີ່ໄດ້ຮັບການຮັບຮອງ, ຫນຶ່ງໃນຜູ້ພັດທະນາ kubespray.

Post Scriptum ພຽງເລັກນ້ອຍບໍ່ແມ່ນສໍາລັບການໂຄສະນາ, ແຕ່ສໍາລັບຜົນປະໂຫຍດ ...

PS Sergey Bondarev ນໍາພາສອງຫຼັກສູດທີ່ເຂັ້ມງວດ: ປັບປຸງ ຖານ Kubernetes ວັນທີ 28-30 ກັນຍາ ແລະ ກ້າວໜ້າ Kubernetes Mega ວັນທີ 14–16 ຕຸລາ.

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