ປະລິມານ Ephemeral ທີ່ມີການຕິດຕາມຄວາມສາມາດໃນການເກັບຮັກສາ: EmptyDir ໃນ Steroids

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

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

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

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

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

• ປະລິມານ ephemeral ຈຸດປະສົງທົ່ວໄປ;

• ການຕິດຕາມຄວາມອາດສາມາດເກັບຮັກສາ CSI.

ຂໍ້ໄດ້ປຽບຂອງວິທີການໃຫມ່:

• ການເກັບຮັກສາສາມາດຢູ່ໃນທ້ອງຖິ່ນຫຼືເຊື່ອມຕໍ່ຜ່ານເຄືອຂ່າຍ;

• ປະລິມານສາມາດມີຂະຫນາດທີ່ກໍານົດໄວ້ທີ່ບໍ່ສາມາດເກີນຄໍາຮ້ອງສະຫມັກ;

• ເຮັດ​ວຽກ​ຮ່ວມ​ກັບ​ຄົນ​ຂັບ CSI ໃດ​ທີ່​ສະ​ຫນັບ​ສະ​ຫນູນ​ການ​ສະ​ຫນອງ​ປະ​ລິ​ມານ​ທີ່​ຄົງ​ຄ້າງ​ແລະ (ເພື່ອ​ສະ​ຫນັບ​ສະ​ຫນູນ​ການ​ຕິດ​ຕາມ​ຄວາມ​ສາ​ມາດ​) ປະ​ຕິ​ບັດ​ການ​ໂທ GetCapacity;

• ປະລິມານອາດຈະມີຂໍ້ມູນເບື້ອງຕົ້ນບາງຢ່າງຂຶ້ນກັບຄົນຂັບ ແລະການຕັ້ງຄ່າ;

• ການ​ດໍາ​ເນີນ​ງານ​ມາດ​ຕະ​ຖານ​ທັງ​ຫມົດ​ທີ່​ມີ​ປະ​ລິ​ມານ (ການ​ສ້າງ​ຮູບ​ພາບ​, ການ​ປັບ​ຂະ​ຫນາດ​, ແລະ​ອື່ນໆ​) ແມ່ນ​ສະ​ຫນັບ​ສະ​ຫນູນ​;

• ປະລິມານສາມາດຖືກນໍາໃຊ້ກັບຕົວຄວບຄຸມຄໍາຮ້ອງສະຫມັກໃດໆທີ່ຍອມຮັບໂມດູນຫຼືຂໍ້ກໍານົດປະລິມານ;

• ຕົວກຳນົດເວລາ Kubernetes ເລືອກ nodes ທີ່ເໝາະສົມດ້ວຍຕົວມັນເອງ, ສະນັ້ນ ບໍ່ຈໍາເປັນຕ້ອງຈັດຫາ ແລະກຳນົດຄ່າການຂະຫຍາຍຕົວກຳນົດເວລາ ຫຼື ແກ້ໄຂ webhooks.

ທາງເລືອກໃນການສະ ໝັກ

ດັ່ງນັ້ນ, ປະລິມານ ephemeral ທົ່ວໄປແມ່ນເຫມາະສົມສໍາລັບກໍລະນີການນໍາໃຊ້ດັ່ງຕໍ່ໄປນີ້:

ຫນ່ວຍຄວາມຈໍາຄົງທີ່ເປັນການທົດແທນສໍາລັບ RAM ສໍາລັບ memcached

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

LVM ພື້ນທີ່ເກັບຂໍ້ມູນໃນທ້ອງຖິ່ນເປັນພື້ນທີ່ເຮັດວຽກ

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

ການເຂົ້າເຖິງແບບອ່ານເທົ່ານັ້ນສໍາລັບປະລິມານຂໍ້ມູນ

ການຈັດສັນປະລິມານສາມາດສົ່ງຜົນໃຫ້ການສ້າງປະລິມານເຕັມເມື່ອ:

• ການຟື້ນຟູ ພາບຖ່າຍປະລິມານ;

• ການສ້າງ ສຳເນົາປະລິມານ;

• ເຮັດວຽກ ຕົວຍຶດຂໍ້ມູນ.

ປະລິມານເຫຼົ່ານີ້ສາມາດຖືກຕິດຕັ້ງຢູ່ໃນໂໝດອ່ານເທົ່ານັ້ນ.

ວິທີການເຮັດວຽກນີ້

ຈຸດປະສົງທົ່ວໄປ Volumes Ephemeral

ຄຸນ​ນະ​ສົມ​ບັດ​ທີ່​ສໍາ​ຄັນ​ຂອງ​ປະ​ລິ​ມານ ephemeral ໂດຍ​ທົ່ວ​ໄປ​ແມ່ນ​ແຫຼ່ງ​ປະ​ລິ​ມານ​ໃຫມ່​, EphemeralVolumeSource, ປະກອບດ້ວຍຊ່ອງຂໍ້ມູນທັງຫມົດເພື່ອສ້າງການຮ້ອງຂໍປະລິມານ (ປະຫວັດສາດເອີ້ນວ່າຄໍາຮ້ອງຂໍປະລິມານຄົງທີ່, PVC). ຕົວຄວບຄຸມໃຫມ່ໃນ kube-controller-manager ເບິ່ງຝັກທີ່ສ້າງແຫຼ່ງປະລິມານດັ່ງກ່າວ, ແລະຫຼັງຈາກນັ້ນສ້າງ PVC ສໍາລັບຝັກເຫຼົ່ານັ້ນ. ສໍາລັບຜູ້ຂັບຂີ່ CSI, ການຮ້ອງຂໍນີ້ມີລັກສະນະດຽວກັນກັບຄົນອື່ນ, ດັ່ງນັ້ນບໍ່ຈໍາເປັນຕ້ອງມີການສະຫນັບສະຫນູນພິເສດຢູ່ທີ່ນີ້.

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

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

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

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

ການຕິດຕາມຄວາມສາມາດໃນການເກັບຮັກສາ

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

ໃໝ່ API CSIStorageCapacity, ເຊິ່ງຢູ່ໃນຂັ້ນຕອນ alpha, ອະນຸຍາດໃຫ້ຂໍ້ມູນທີ່ຈໍາເປັນຖືກເກັບໄວ້ໃນ etcd ເພື່ອໃຫ້ມັນມີຢູ່ໃນຕາຕະລາງ. ບໍ່ເຫມືອນກັບການສະຫນັບສະຫນູນສໍາລັບປະລິມານ ephemeral ທົ່ວໄປ, ເມື່ອທ່ານຕິດຕັ້ງໄດເວີ, ທ່ານຕ້ອງເປີດໃຊ້ການຕິດຕາມຄວາມສາມາດໃນການເກັບຮັກສາ: external-provisioner ຄວນເຜີຍແຜ່ຂໍ້ມູນຄວາມສາມາດທີ່ໄດ້ຮັບຈາກຄົນຂັບຜ່ານທາງປົກກະຕິ GetCapacity.

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

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

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

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

ຄວາມປອດໄພ

CSIStorage ຄວາມອາດສາມາດ

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

ຈຸດປະສົງທົ່ວໄປ Volumes Ephemeral

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

ຕົວຢ່າງ:

ແຍກຕ່າງຫາກ ສາຂາ PMEM-CSI ປະກອບດ້ວຍການປ່ຽນແປງທີ່ຈໍາເປັນທັງໝົດເພື່ອແລ່ນກຸ່ມ Kubernetes 1.19 ພາຍໃນເຄື່ອງຈັກສະເໝືອນ QEMU ທີ່ມີຄຸນສົມບັດທັງໝົດໃນຂັ້ນຕອນອັນຟາ. ລະຫັດຄົນຂັບບໍ່ໄດ້ມີການປ່ຽນແປງ, ພຽງແຕ່ການປັບຕົວໄດ້ມີການປ່ຽນແປງ.

ໃນເຄື່ອງທີ່ເຫມາະສົມ (Linux, ຜູ້ໃຊ້ປົກກະຕິສາມາດໃຊ້ Docker, ເບິ່ງ ທີ່ນີ້ ລາຍລະອຽດ) ຄໍາສັ່ງເຫຼົ່ານີ້ຈະນໍາເອົາກຸ່ມແລະຕິດຕັ້ງໄດເວີ PMEM-CSI:

git clone --branch=kubernetes-1-19-blog-post https://github.com/intel/pmem-csi.git
cd pmem-csi
export TEST_KUBERNETES_VERSION=1.19 TEST_FEATURE_GATES=CSIStorageCapacity=true,GenericEphemeralVolume=true TEST_PMEM_REGISTRY=intel
make start && echo && test/setup-deployment.sh

ຫຼັງຈາກທຸກສິ່ງທຸກຢ່າງເຮັດວຽກ, ຜົນຜະລິດຈະມີຄໍາແນະນໍາສໍາລັບການນໍາໃຊ້:

The test cluster is ready. Log in with [...]/pmem-csi/_work/pmem-govm/ssh.0, run
kubectl once logged in.  Alternatively, use kubectl directly with the
following env variable:
   KUBECONFIG=[...]/pmem-csi/_work/pmem-govm/kube.config

secret/pmem-csi-registry-secrets created
secret/pmem-csi-node-secrets created
serviceaccount/pmem-csi-controller created
...
To try out the pmem-csi driver ephemeral volumes:
   cat deploy/kubernetes-1.19/pmem-app-ephemeral.yaml |
   [...]/pmem-csi/_work/pmem-govm/ssh.0 kubectl create -f -

CSIStorageCapacity objects ບໍ່ໄດ້ຫມາຍເຖິງການອ່ານໂດຍມະນຸດ, ດັ່ງນັ້ນການປຸງແຕ່ງບາງຢ່າງແມ່ນຈໍາເປັນ. ຕົວກອງແມ່ແບບ Golang ຈະສະແດງຫ້ອງຮຽນການເກັບຮັກສາ, ຕົວຢ່າງນີ້ຈະສະແດງຊື່, topology ແລະຄວາມສາມາດ:

$ kubectl get 
        -o go-template='{{range .items}}{{if eq .storageClassName "pmem-csi-sc-late-binding"}}{{.metadata.name}} {{.nodeTopology.matchLabels}} {{.capacity}}
{{end}}{{end}}' 
        csistoragecapacities
csisc-2js6n map[pmem-csi.intel.com/node:pmem-csi-pmem-govm-worker2] 30716Mi
csisc-sqdnt map[pmem-csi.intel.com/node:pmem-csi-pmem-govm-worker1] 30716Mi
csisc-ws4bv map[pmem-csi.intel.com/node:pmem-csi-pmem-govm-worker3] 30716Mi

ວັດຖຸດຽວມີເນື້ອໃນດັ່ງຕໍ່ໄປນີ້:

$ kubectl describe csistoragecapacities/csisc-6cw8j
Name:         csisc-sqdnt
Namespace:    default
Labels:       <none>
Annotations:  <none>
API Version:  storage.k8s.io/v1alpha1
Capacity:     30716Mi
Kind:         CSIStorageCapacity
Metadata:
  Creation Timestamp:  2020-08-11T15:41:03Z
  Generate Name:       csisc-
  Managed Fields:
    ...
  Owner References:
    API Version:     apps/v1
    Controller:      true
    Kind:            StatefulSet
    Name:            pmem-csi-controller
    UID:             590237f9-1eb4-4208-b37b-5f7eab4597d1
  Resource Version:  2994
  Self Link:         /apis/storage.k8s.io/v1alpha1/namespaces/default/csistoragecapacities/csisc-sqdnt
  UID:               da36215b-3b9d-404a-a4c7-3f1c3502ab13
Node Topology:
  Match Labels:
    pmem-csi.intel.com/node:  pmem-csi-pmem-govm-worker1
Storage Class Name:           pmem-csi-sc-late-binding
Events:                       <none>

ໃຫ້ພະຍາຍາມສ້າງຄໍາຮ້ອງສະຫມັກຕົວຢ່າງທີ່ມີປະລິມານ ephemeral ຈຸດປະສົງທົ່ວໄປດຽວ. ເນື້ອໃນໄຟລ໌ pmem-app-ephemeral.yaml:

# This example Pod definition demonstrates
# how to use generic ephemeral inline volumes
# with a PMEM-CSI storage class.
kind: Pod
apiVersion: v1
metadata:
  name: my-csi-app-inline-volume
spec:
  containers:
    - name: my-frontend
      image: intel/pmem-csi-driver-test:v0.7.14
      command: [ "sleep", "100000" ]
      volumeMounts:
      - mountPath: "/data"
        name: my-csi-volume
  volumes:
  - name: my-csi-volume
    ephemeral:
      volumeClaimTemplate:
        spec:
          accessModes:
          - ReadWriteOnce
          resources:
            requests:
              storage: 4Gi
          storageClassName: pmem-csi-sc-late-binding

ຫຼັງຈາກການສ້າງ, ດັ່ງທີ່ສະແດງຢູ່ໃນຄໍາແນະນໍາຂ້າງເທິງ, ພວກເຮົາມີຝັກແລະ PVC ເພີ່ມເຕີມ:

$ kubectl get pods/my-csi-app-inline-volume -o wide
NAME                       READY   STATUS    RESTARTS   AGE     IP          NODE                         NOMINATED NODE   READINESS GATES
my-csi-app-inline-volume   1/1     Running   0          6m58s   10.36.0.2   pmem-csi-pmem-govm-worker1   <none>           <none>
$ kubectl get pvc/my-csi-app-inline-volume-my-csi-volume
NAME                                     STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS               AGE
my-csi-app-inline-volume-my-csi-volume   Bound    pvc-c11eb7ab-a4fa-46fe-b515-b366be908823   4Gi        RWO            pmem-csi-sc-late-binding   9m21s

ເຈົ້າຂອງ PVC - ພາຍໃຕ້:

$ kubectl get -o yaml pvc/my-csi-app-inline-volume-my-csi-volume
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  annotations:
    pv.kubernetes.io/bind-completed: "yes"
    pv.kubernetes.io/bound-by-controller: "yes"
    volume.beta.kubernetes.io/storage-provisioner: pmem-csi.intel.com
    volume.kubernetes.io/selected-node: pmem-csi-pmem-govm-worker1
  creationTimestamp: "2020-08-11T15:44:57Z"
  finalizers:
  - kubernetes.io/pvc-protection
  managedFields:
    ...
  name: my-csi-app-inline-volume-my-csi-volume
  namespace: default
  ownerReferences:
  - apiVersion: v1
    blockOwnerDeletion: true
    controller: true
    kind: Pod
    name: my-csi-app-inline-volume
    uid: 75c925bf-ca8e-441a-ac67-f190b7a2265f
...

ຄາດວ່າຈະມີການປັບປຸງຂໍ້ມູນຂ່າວສານສໍາລັບ pmem-csi-pmem-govm-worker1:

csisc-2js6n map[pmem-csi.intel.com/node:pmem-csi-pmem-govm-worker2] 30716Mi
csisc-sqdnt map[pmem-csi.intel.com/node:pmem-csi-pmem-govm-worker1] 26620Mi
csisc-ws4bv map[pmem-csi.intel.com/node:pmem-csi-pmem-govm-worker3] 30716Mi

ຖ້າແອັບພລິເຄຊັນອື່ນຕ້ອງການຫຼາຍກວ່າ 26620Mi, ຕົວກໍານົດເວລາຈະບໍ່ຄໍານຶງເຖິງ pmem-csi-pmem-govm-worker1 ໃນ​ກໍ​ລະ​ນີ​ໃດ​ກໍ​ຕາມ.

ຈະເປັນແນວໃດຕໍ່ໄປ?

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

• KEP-1698: ປະລິມານໃນແຖວ ephemeral ທົ່ວໄປ

• KEP-1472: ການຕິດຕາມຄວາມສາມາດໃນການເກັບຮັກສາ

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