ກອງປະຊຸມ DEVOXX UK. ເລືອກກອບວຽກ: Docker Swarm, Kubernetes ຫຼື Mesos. ພາກທີ 3

Docker Swarm, Kubernetes, ແລະ Mesos ແມ່ນໂຄງຮ່າງການ orchestration ບັນຈຸທີ່ນິຍົມທີ່ສຸດ. ໃນການສົນທະນາຂອງລາວ, Arun Gupta ປຽບທຽບລັກສະນະຕໍ່ໄປນີ້ຂອງ Docker, Swarm, ແລະ Kubernetes:

• ການພັດທະນາທ້ອງຖິ່ນ.
• ປະຕິບັດຫນ້າທີ່.
• ຄໍາຮ້ອງສະຫມັກຫຼາຍຖັງ.
• ການຄົ້ນພົບການບໍລິການ.
• ການ​ຂະ​ຫຍາຍ​ການ​ບໍ​ລິ​ການ​.
• ເຮັດວຽກຄັ້ງດຽວ.
• ການປະສົມປະສານກັບ Maven.
• ການປັບປຸງ "ມ້ວນ".
• ການສ້າງກຸ່ມຖານຂໍ້ມູນ Couchbase.

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

Arun Gupta ເປັນຫົວຫນ້າເທກໂນໂລຍີສໍາລັບຜະລິດຕະພັນ open-source ຢູ່ Amazon Web Services, ຜູ້ທີ່ໄດ້ພັດທະນາຊຸມຊົນນັກພັດທະນາ Sun, Oracle, Red Hat ແລະ Couchbase ຫຼາຍກວ່າ 10 ປີ. ມີປະສົບການຢ່າງກວ້າງຂວາງໃນການເຮັດວຽກໃນທີມງານຂ້າມຫນ້າທີ່ຊັ້ນນໍາໃນການພັດທະນາແລະການປະຕິບັດຍຸດທະສາດສໍາລັບການໂຄສະນາການຕະຫຼາດແລະໂຄງການ. ລາວໄດ້ນໍາພາທີມງານຂອງວິສະວະກອນ Sun, ເປັນຫນຶ່ງໃນຜູ້ກໍ່ຕັ້ງຂອງທີມ Java EE ແລະຜູ້ສ້າງ Devoxx4Kids ສາຂາສະຫະລັດ. Arun Gupta ເປັນຜູ້ຂຽນຫຼາຍກວ່າ 2 ພັນຂໍ້ຄວາມໃນ blogs IT ແລະໄດ້ໃຫ້ການສົນທະນາໃນຫຼາຍກວ່າ 40 ປະເທດ.

ກອງປະຊຸມ DEVOXX UK. ເລືອກກອບວຽກ: Docker Swarm, Kubernetes ຫຼື Mesos. ພາກທີ 1
ກອງປະຊຸມ DEVOXX UK. ເລືອກກອບວຽກ: Docker Swarm, Kubernetes ຫຼື Mesos. ພາກທີ 2

ແຖວ 55 ມີ COUCHBASE_URI ຊີ້ໄປຫາການບໍລິການຖານຂໍ້ມູນນີ້, ເຊິ່ງໄດ້ຖືກສ້າງຂື້ນໂດຍໃຊ້ໄຟລ໌ການຕັ້ງຄ່າ Kubernetes. ຖ້າທ່ານເບິ່ງເສັ້ນ 2, ທ່ານສາມາດເບິ່ງປະເພດ: ການບໍລິການແມ່ນການບໍລິການທີ່ຂ້ອຍກໍາລັງສ້າງທີ່ເອີ້ນວ່າ couchbase-service, ແລະຊື່ດຽວກັນແມ່ນສະແດງຢູ່ໃນເສັ້ນ 4. ຂ້າງລຸ່ມນີ້ແມ່ນບາງພອດ.

ເສັ້ນທີ່ສໍາຄັນແມ່ນ 6 ແລະ 7. ໃນການບໍລິການຂ້ອຍເວົ້າວ່າ, "Hey, ນີ້ແມ່ນປ້າຍທີ່ຂ້ອຍກໍາລັງຊອກຫາ!", ແລະປ້າຍເຫຼົ່ານີ້ບໍ່ມີຫຍັງນອກເຫນືອຈາກຊື່ຄູ່ທີ່ປ່ຽນແປງໄດ້, ແລະເສັ້ນ 7 ຊີ້ໃຫ້ເຫັນ couchbase-rs-pod ຂອງຂ້ອຍ. ຄໍາຮ້ອງສະຫມັກ. ຕໍ່ໄປນີ້ແມ່ນພອດທີ່ສະຫນອງການເຂົ້າເຖິງປ້າຍດຽວກັນເຫຼົ່ານີ້.

ໃນແຖວທີ 19 ຂ້ອຍສ້າງ ReplicaSet ປະເພດໃຫມ່, ເສັ້ນ 31 ມີຊື່ຂອງຮູບພາບ, ແລະເສັ້ນ 24-27 ຊີ້ໃຫ້ເຫັນ metadata ທີ່ກ່ຽວຂ້ອງກັບ pod ຂອງຂ້ອຍ. ນີ້ແມ່ນສິ່ງທີ່ບໍລິການກໍາລັງຊອກຫາແລະສິ່ງທີ່ການເຊື່ອມຕໍ່ຄວນຈະເຮັດ. ໃນຕອນທ້າຍຂອງໄຟລ໌ມີບາງປະເພດຂອງການເຊື່ອມຕໍ່ລະຫວ່າງສາຍ 55-56 ແລະ 4, ໂດຍກ່າວວ່າ: "ໃຊ້ບໍລິການນີ້!"

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

ດັ່ງນັ້ນ, ຂ້ອຍມີຝັກ WildFly ທີ່ຕິດຕໍ່ກັບ backend ຖານຂໍ້ມູນຜ່ານ Couchbase Service. ຂ້ອຍສາມາດໃຊ້ frontend ກັບ WildFly pods ຫຼາຍອັນ, ເຊິ່ງຍັງຕິດຕໍ່ສື່ສານກັບ couchbase backend ຜ່ານການບໍລິການ couchbase.

ຕໍ່ມາພວກເຮົາຈະເບິ່ງວິທີການບໍລິການທີ່ຢູ່ນອກກຸ່ມຕິດຕໍ່ສື່ສານຜ່ານທີ່ຢູ່ IP ຂອງມັນກັບອົງປະກອບທີ່ຢູ່ໃນກຸ່ມແລະມີທີ່ຢູ່ IP ພາຍໃນ.

ດັ່ງນັ້ນ, ຕູ້ຄອນເທນເນີທີ່ບໍ່ມີລັດແມ່ນດີຫຼາຍ, ແຕ່ການໃຊ້ຕູ້ຄອນເທນເນີທີ່ບໍ່ມີລັດຈະດີແນວໃດ? ລອງເບິ່ງການຕັ້ງຄ່າລະບົບສຳລັບກ່ອງບັນຈຸທີ່ມີສະຖານະ ຫຼືຄົງທີ່. ໃນ Docker, ມີ 4 ວິທີການທີ່ແຕກຕ່າງກັນກັບຮູບແບບການເກັບຮັກສາຂໍ້ມູນທີ່ທ່ານຄວນເອົາໃຈໃສ່. ທໍາອິດແມ່ນ Implicit Per-Container, ຊຶ່ງຫມາຍຄວາມວ່າເມື່ອໃຊ້ couchbase, MySQL ຫຼື MyDB satateful containers, ພວກມັນທັງຫມົດເລີ່ມຕົ້ນດ້ວຍ Sandbox ເລີ່ມຕົ້ນ. ນັ້ນແມ່ນ, ທຸກສິ່ງທຸກຢ່າງທີ່ເກັບໄວ້ໃນຖານຂໍ້ມູນແມ່ນເກັບໄວ້ໃນຖັງຂອງມັນເອງ. ຖ້າກ່ອງບັນຈຸຫາຍໄປ, ຂໍ້ມູນຈະຫາຍໄປພ້ອມກັບມັນ.

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

ແຕ່ລະວິທີການເຫຼົ່ານີ້ໃຊ້ສະຖານທີ່ເກັບຮັກສາສະເພາະ. ຂໍ້ມູນເກັບຂໍ້ມູນຕໍ່ຄອນເທນເນີຢ່າງຈະແຈ້ງ ແລະຊັດເຈນຢູ່ໃນໂຮດຢູ່ທີ່ /var/lib/docker/volumes. ເມື່ອໃຊ້ວິທີ Per-Host, ການເກັບຮັກສາແມ່ນຕິດຢູ່ພາຍໃນພາຊະນະ, ແລະຕົວບັນຈຸຕົວມັນເອງຖືກຕິດຕັ້ງຢູ່ເທິງໂຮດ. ສໍາລັບ multihosts, ວິທີແກ້ໄຂເຊັ່ນ Ceph, ClusterFS, NFS, ແລະອື່ນໆ.

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

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

ອັນນີ້ຄວນຄຳນຶງເຖິງເວລາສ້າງພາຊະນະທີ່ມີສະຖານະ. ເຄື່ອງມື Docker ທີ່ເປັນປະໂຫຍດອີກອັນຫນຶ່ງແມ່ນ plugin Volume, ເຊິ່ງເຮັດວຽກຢູ່ໃນຫຼັກການຂອງ "ຫມໍ້ໄຟທີ່ມີຢູ່, ແຕ່ຕ້ອງຖືກປ່ຽນແທນ." ເມື່ອທ່ານເລີ່ມຕົ້ນ Docker container, ມັນເວົ້າວ່າ, "Hey, ເມື່ອທ່ານເລີ່ມຕົ້ນ container ກັບຖານຂໍ້ມູນ, ທ່ານສາມາດເກັບຮັກສາຂໍ້ມູນຂອງທ່ານໃນ container ນີ້!" ນີ້ແມ່ນຄຸນສົມບັດເລີ່ມຕົ້ນ, ແຕ່ທ່ານສາມາດປ່ຽນມັນໄດ້. ປັ໊ກອິນນີ້ອະນຸຍາດໃຫ້ທ່ານໃຊ້ drive ເຄືອຂ່າຍຫຼືບາງສິ່ງບາງຢ່າງທີ່ຄ້າຍຄືກັນແທນທີ່ຈະເປັນຖານຂໍ້ມູນບັນຈຸ. ມັນປະກອບມີໄດເວີເລີ່ມຕົ້ນສໍາລັບການເກັບຮັກສາທີ່ອີງໃສ່ໂຮດແລະອະນຸຍາດໃຫ້ປະສົມປະສານກັບບັນຈຸກັບລະບົບການເກັບຮັກສາພາຍນອກເຊັ່ນ Amazon EBS, Azure Storage ແລະ GCE Persistent disks.

ສະໄລ້ຕໍ່ໄປສະແດງໃຫ້ເຫັນສະຖາປັດຕະຍະກໍາຂອງ plugin Docker Volume.

ສີຟ້າສະແດງເຖິງລູກຄ້າ Docker ທີ່ກ່ຽວຂ້ອງກັບໂຮດ Docker ສີຟ້າ, ເຊິ່ງມີເຄື່ອງຈັກການເກັບຮັກສາທ້ອງຖິ່ນທີ່ສະໜອງກ່ອງບັນຈຸຂໍ້ມູນໃຫ້ກັບເຈົ້າ. ສີຂຽວຊີ້ໃຫ້ເຫັນ Plugin Client ແລະ Plugin Daemon, ເຊິ່ງຍັງເຊື່ອມຕໍ່ກັບໂຮດ. ພວກເຂົາເຈົ້າສະຫນອງໂອກາດທີ່ຈະເກັບຮັກສາຂໍ້ມູນໃນເຄືອຂ່າຍການເກັບຮັກສາຂອງປະເພດຂອງການເກັບຮັກສາ Backend ທີ່ທ່ານຕ້ອງການ.

ປັ໊ກອິນ Docker Volume ສາມາດໃຊ້ກັບບ່ອນເກັບຂໍ້ມູນ Portworx. ໂມດູນ PX-Dev ຕົວຈິງແລ້ວແມ່ນຕູ້ຄອນເທນເນີທີ່ທ່ານດໍາເນີນການທີ່ເຊື່ອມຕໍ່ກັບໂຮດ Docker ຂອງທ່ານແລະຊ່ວຍໃຫ້ທ່ານສາມາດເກັບຂໍ້ມູນໄດ້ງ່າຍໃນ Amazon EBS.

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

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

ທໍາອິດແມ່ນວ່າຜູ້ໃດຜູ້ຫນຶ່ງໃນດ້ານເຄືອຂ່າຍ, ປົກກະຕິແລ້ວຜູ້ບໍລິຫານ, ສະຫນອງການເກັບຮັກສາຢ່າງຕໍ່ເນື່ອງ. ມີໄຟລ໌ການຕັ້ງຄ່າ PersistentVolume ທີ່ສອດຄ້ອງກັນສໍາລັບການນີ້. ຕໍ່ໄປ, ຜູ້ພັດທະນາແອັບພລິເຄຊັນຂຽນໄຟລ໌ການຕັ້ງຄ່າທີ່ເອີ້ນວ່າ PersistentVolumeClaim, ຫຼືຄໍາຮ້ອງຂໍການເກັບຮັກສາ PVC, ເຊິ່ງກ່າວວ່າ: "ຂ້ອຍມີບ່ອນເກັບຂໍ້ມູນ 50GB ທີ່ແຈກຢາຍ, ແຕ່ເພື່ອໃຫ້ຄົນອື່ນໃຊ້ຄວາມສາມາດຂອງມັນ, ຂ້ອຍບອກ PVC ນີ້ວ່າຂ້ອຍປະຈຸບັນ. ຕ້ອງການພຽງແຕ່ 10 GB". ສຸດທ້າຍ, ຂັ້ນຕອນທີສາມແມ່ນວ່າຄໍາຮ້ອງຂໍຂອງທ່ານຖືກຕິດຕັ້ງເປັນບ່ອນເກັບມ້ຽນ, ແລະແອັບພລິເຄຊັນທີ່ມີຝັກ, ຫຼືຊຸດແບບຈໍາລອງ, ຫຼືບາງສິ່ງບາງຢ່າງທີ່ຄ້າຍຄືກັນ, ເລີ່ມໃຊ້ມັນ. ມັນເປັນສິ່ງສໍາຄັນທີ່ຈະຈື່ຈໍາວ່າຂະບວນການນີ້ປະກອບດ້ວຍ 3 ຂັ້ນຕອນທີ່ໄດ້ກ່າວມາແລະສາມາດຂະຫຍາຍໄດ້.

ສະໄລ້ຕໍ່ໄປສະແດງໃຫ້ເຫັນ Kubernetes Persistence Container ຂອງສະຖາປັດຕະຍະກໍາ AWS.

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

ຄືກັນກັບ Docker, ທ່ານສາມາດນໍາໃຊ້ຖັງເກັບ Kubernetes ຄົງທີ່ກັບ Portworx.

ນີ້ແມ່ນສິ່ງທີ່ຢູ່ໃນຄໍາທີ່ໃຊ້ໃນ Kubernetes 1.6 ປະຈຸບັນເອີ້ນວ່າ "StatefulSet" - ວິທີການເຮັດວຽກກັບແອັບພລິເຄຊັນ Stateful ທີ່ປະມວນຜົນເຫດການກ່ຽວກັບການຢຸດ Pod ແລະປະຕິບັດການປິດດ້ວຍ Graceful. ໃນກໍລະນີຂອງພວກເຮົາ, ຄໍາຮ້ອງສະຫມັກດັ່ງກ່າວແມ່ນຖານຂໍ້ມູນ. ໃນ blog ຂອງຂ້ອຍທ່ານສາມາດອ່ານວິທີການສ້າງ StatefulSet ໃນ Kubernetes ໂດຍໃຊ້ Portworx.
ໃຫ້ເວົ້າກ່ຽວກັບລັກສະນະການພັດທະນາ. ດັ່ງທີ່ຂ້າພະເຈົ້າເວົ້າ, Docker ມີ 2 ຮຸ່ນ - CE ແລະ EE, ໃນກໍລະນີທໍາອິດທີ່ພວກເຮົາກໍາລັງເວົ້າເຖິງສະບັບທີ່ຫມັ້ນຄົງຂອງ Community Edition, ເຊິ່ງຖືກປັບປຸງທຸກໆ 3 ເດືອນ, ກົງກັນຂ້າມກັບສະບັບປັບປຸງປະຈໍາເດືອນຂອງ EE. ທ່ານສາມາດດາວໂຫລດ Docker ສໍາລັບ Mac, Linux ຫຼື Windows. ເມື່ອຕິດຕັ້ງແລ້ວ, Docker ຈະອັບເດດອັດຕະໂນມັດ ແລະມັນງ່າຍຫຼາຍທີ່ຈະເລີ່ມຕົ້ນ.

ສໍາລັບ Kubernetes, ຂ້ອຍມັກລຸ້ນ Minikube - ມັນເປັນວິທີທີ່ດີທີ່ຈະເລີ່ມຕົ້ນກັບແພລະຕະຟອມໂດຍການສ້າງກຸ່ມຢູ່ໃນໂຫນດດຽວ. ເພື່ອສ້າງກຸ່ມຂອງຫຼາຍ nodes, ທາງເລືອກຂອງຮຸ່ນແມ່ນກວ້າງກວ່າ: ເຫຼົ່ານີ້ແມ່ນ kops, kube-aws (CoreOS+AWS), kube-up (ລ້າສະໄຫມ). ຖ້າທ່ານກໍາລັງຊອກຫາໃຊ້ AWS-based Kubernetes, ຂ້າພະເຈົ້າຂໍແນະນໍາໃຫ້ເຂົ້າຮ່ວມ AWS SIG, ເຊິ່ງພົບກັນອອນໄລນ໌ທຸກໆວັນສຸກແລະເຜີຍແຜ່ເອກະສານທີ່ຫຼາກຫຼາຍທີ່ຫນ້າສົນໃຈໃນການເຮັດວຽກກັບ AWS Kubernetes.

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

ເພື່ອເຮັດສິ່ງນີ້, ຂ້ອຍໃຊ້ຄໍາສັ່ງປັບປຸງການບໍລິການ docker (ຊື່ບໍລິການ), ເຊິ່ງຂ້ອຍລະບຸສະບັບໃຫມ່ຂອງຮູບພາບ WildFly: 2 ແລະວິທີການປັບປຸງການປັບປຸງ - parallelism 2. ຕົວເລກ 2 ຫມາຍຄວາມວ່າລະບົບຈະປັບປຸງ 2 ຮູບພາບແອັບພລິເຄຊັນ. ໃນ​ເວ​ລາ​ດຽວ​ກັນ​, ຫຼັງ​ຈາກ​ນັ້ນ​ການ​ຊັກ​ຊ້າ​ການ​ປັບ​ປຸງ 10 ວິ​ນາ​ທີ 10s​, ຫຼັງ​ຈາກ​ນັ້ນ 2 ຮູບ​ພາບ​ຕໍ່​ໄປ​ຈະ​ໄດ້​ຮັບ​ການ​ປັບ​ປຸງ​ໃນ 2 nodes​, ແລະ​ອື່ນໆ​. ກົນໄກການອັບເດດແບບມ້ວນແບບງ່າຍໆນີ້ແມ່ນສະຫນອງໃຫ້ທ່ານເປັນສ່ວນຫນຶ່ງຂອງ Docker.

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

ໃນກໍລະນີນີ້, ພວກເຮົາມີ 3 pods ໃນ Replication controller ແລ່ນຄໍາຮ້ອງສະຫມັກ WildFly ຮຸ່ນ 1. ໃນເວລາທີ່ການປັບປຸງໃນພື້ນຫລັງ, ຕົວຄວບຄຸມ replication ອື່ນແມ່ນສ້າງດ້ວຍຊື່ດຽວກັນແລະດັດສະນີຢູ່ທ້າຍ - - xxxxx, ບ່ອນທີ່ x ເປັນຕົວເລກສຸ່ມ, ແລະ. ກັບປ້າຍຊື່ດຽວກັນ. ໃນປັດຈຸບັນການບໍລິການຄໍາຮ້ອງສະຫມັກມີສາມຝັກທີ່ມີຮຸ່ນເກົ່າຂອງແອັບພລິເຄຊັນແລະສາມຝັກທີ່ມີຮຸ່ນໃຫມ່ໃນຕົວຄວບຄຸມການຈໍາລອງໃຫມ່. ຫຼັງຈາກນີ້, ຝັກເກົ່າຖືກລຶບ, ຕົວຄວບຄຸມການຈໍາລອງທີ່ມີຝັກໃຫມ່ຖືກປ່ຽນຊື່ແລະປະຕິບັດ.

ໃຫ້ກ້າວໄປສູ່ການຕິດຕາມ. Docker ມີຄໍາສັ່ງຕິດຕາມກວດກາຫຼາຍຕົວ. ຕົວຢ່າງ, ການໂຕ້ຕອບເສັ້ນຄໍາສັ່ງ docker container stats ອະນຸຍາດໃຫ້ທ່ານສະແດງຂໍ້ມູນກ່ຽວກັບສະຖານະຂອງ containers ກັບ console ທຸກໆວິນາທີ - ການໃຊ້ໂປເຊດເຊີ, ການນໍາໃຊ້ແຜ່ນ, ການໂຫຼດເຄືອຂ່າຍ. ເຄື່ອງມື Docker Remote API ໃຫ້ຂໍ້ມູນກ່ຽວກັບວິທີທີ່ລູກຄ້າຕິດຕໍ່ສື່ສານກັບເຄື່ອງແມ່ຂ່າຍ. ມັນໃຊ້ຄໍາສັ່ງງ່າຍໆ, ແຕ່ແມ່ນອີງໃສ່ Docker REST API. ໃນກໍລະນີນີ້, ຄໍາວ່າ REST, Flash, Remote ຫມາຍເຖິງສິ່ງດຽວກັນ. ເມື່ອທ່ານຕິດຕໍ່ສື່ສານກັບເຈົ້າພາບ, ມັນເປັນ REST API. Docker Remote API ອະນຸຍາດໃຫ້ທ່ານໄດ້ຮັບຂໍ້ມູນເພີ່ມເຕີມກ່ຽວກັບການແລ່ນບັນຈຸ. blog ຂອງຂ້ອຍອະທິບາຍລາຍລະອຽດຂອງການນໍາໃຊ້ການຕິດຕາມນີ້ກັບ Windows Server.

ການຕິດຕາມເຫດການຂອງລະບົບ docker ໃນເວລາແລ່ນຫຼາຍ host cluster ເຮັດໃຫ້ມັນເປັນໄປໄດ້ທີ່ຈະໄດ້ຮັບຂໍ້ມູນກ່ຽວກັບ host crash ຫຼື container crash ໃນ host ສະເພາະ, scaling services, ແລະອື່ນໆ. ເລີ່ມຕົ້ນດ້ວຍ Docker 1.20, ມັນປະກອບມີ Prometheus, ເຊິ່ງຝັງຈຸດສິ້ນສຸດເຂົ້າໄປໃນແອັບພລິເຄຊັນທີ່ມີຢູ່. ນີ້ອະນຸຍາດໃຫ້ທ່ານໄດ້ຮັບ metrics ຜ່ານ HTTP ແລະສະແດງໃຫ້ພວກເຂົາຢູ່ໃນ dashboards.

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

ສະໄລ້ຕໍ່ໄປສະແດງໃຫ້ເຫັນເຖິງສິ່ງທີ່ຜົນໄດ້ຮັບຂອງຈຸດສິ້ນສຸດຂອງ Prometheus ແລະຕົວຊີ້ວັດທີ່ມີໃຫ້ສະແດງ.

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

Kubernetes ຍັງລວມເອົາເຄື່ອງມືການຕິດຕາມໃນຕົວ. ສະໄລ້ນີ້ສະແດງກຸ່ມປົກກະຕິທີ່ມີໜຶ່ງແມ່ແບບ ແລະສາມໂຫນດຂອງພະນັກງານ.

ແຕ່ລະໂຫນດທີ່ເຮັດວຽກປະກອບດ້ວຍ cAdvisor ທີ່ເປີດໂດຍອັດຕະໂນມັດ. ນອກຈາກນັ້ນ, ຍັງມີ Heapster, ລະບົບການຕິດຕາມປະສິດທິພາບ ແລະລະບົບເກັບກຳຂໍ້ມູນວັດແທກທີ່ເຂົ້າກັນໄດ້ກັບ Kubernetes ເວີຊັນ 1.0.6 ແລະສູງກວ່າ. Heapster ອະນຸຍາດໃຫ້ທ່ານເກັບກໍາບໍ່ພຽງແຕ່ metrics ປະສິດທິພາບຂອງ workloads, pods ແລະ containers, ແຕ່ຍັງເຫດການແລະສັນຍານອື່ນໆທີ່ສ້າງຂຶ້ນໂດຍ cluster ທັງຫມົດ. ເພື່ອເກັບກໍາຂໍ້ມູນ, ມັນສົນທະນາກັບ Kubelet ຂອງແຕ່ລະຝັກ, ເກັບຮັກສາຂໍ້ມູນອັດຕະໂນມັດໃນຖານຂໍ້ມູນ InfluxDB, ແລະສົ່ງອອກເປັນ metrics ກັບ dashboard Grafana. ຢ່າງໃດກໍ່ຕາມ, ຈົ່ງຈື່ໄວ້ວ່າຖ້າທ່ານໃຊ້ miniKube, ຄຸນສົມບັດນີ້ບໍ່ມີຢູ່ໂດຍຄ່າເລີ່ມຕົ້ນ, ດັ່ງນັ້ນທ່ານຈະຕ້ອງໃຊ້ addons ສໍາລັບການຕິດຕາມ. ສະນັ້ນມັນທັງຫມົດແມ່ນຂຶ້ນກັບບ່ອນທີ່ທ່ານດໍາເນີນການບັນຈຸແລະເຄື່ອງມືຕິດຕາມກວດກາທີ່ທ່ານສາມາດນໍາໃຊ້ໂດຍຄ່າເລີ່ມຕົ້ນແລະທີ່ທ່ານຕ້ອງການຕິດຕັ້ງເປັນ add-ons ແຍກຕ່າງຫາກ.

ສະໄລ້ຕໍ່ໄປສະແດງໃຫ້ເຫັນກະດານ Grafana ທີ່ສະແດງສະຖານະການແລ່ນຂອງກ່ອງບັນຈຸຂອງຂ້ອຍ. ມີຂໍ້ມູນທີ່ຫນ້າສົນໃຈຫຼາຍຢູ່ທີ່ນີ້. ແນ່ນອນ, ມີເຄື່ອງມືກວດສອບຂະບວນການ Docker ແລະ Kubernetes ການຄ້າຈໍານວນຫຼາຍ, ເຊັ່ນ: SysDig, DataDog, NewRelic. ບາງສ່ວນຂອງພວກມັນມີໄລຍະທົດລອງໃຊ້ຟຣີ 30 ປີ, ດັ່ງນັ້ນທ່ານສາມາດລອງຊອກຫາອັນທີ່ເໝາະສົມກັບທ່ານທີ່ສຸດ. ສ່ວນບຸກຄົນ, ຂ້າພະເຈົ້າມັກໃຊ້ SysDig ແລະ NewRelic, ເຊິ່ງປະສົມປະສານໄດ້ດີກັບ Kubernetes. ມີເຄື່ອງມືທີ່ປະສົມປະສານຢ່າງເທົ່າທຽມກັນໃນທັງສອງເວທີ Docker ແລະ Kubernetes.

ບາງໂຄສະນາ🙂

ຂອບໃຈສໍາລັບການຢູ່ກັບພວກເຮົາ. ເຈົ້າມັກບົດຄວາມຂອງພວກເຮົາບໍ? ຕ້ອງການເບິ່ງເນື້ອຫາທີ່ຫນ້າສົນໃຈຫຼາຍບໍ? ສະຫນັບສະຫນູນພວກເຮົາໂດຍການວາງຄໍາສັ່ງຫຼືແນະນໍາໃຫ້ຫມູ່ເພື່ອນ, cloud VPS ສໍາລັບນັກພັດທະນາຈາກ $4.99, ການປຽບທຽບທີ່ເປັນເອກະລັກຂອງເຊີບເວີລະດັບເຂົ້າ, ເຊິ່ງຖືກປະດິດໂດຍພວກເຮົາສໍາລັບທ່ານ: ຄວາມຈິງທັງໝົດກ່ຽວກັບ VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps ຈາກ $19 ຫຼືວິທີການແບ່ງປັນເຄື່ອງແມ່ຂ່າຍ? (ສາມາດໃຊ້ໄດ້ກັບ RAID1 ແລະ RAID10, ສູງສຸດ 24 cores ແລະສູງສຸດ 40GB DDR4).

Dell R730xd 2x ລາຄາຖືກກວ່າຢູ່ໃນສູນຂໍ້ມູນ Equinix Tier IV ໃນ Amsterdam? ທີ່ນີ້ເທົ່ານັ້ນ 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV ຈາກ $199 ໃນປະເທດເນເທີແລນ! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - ຈາກ $99! ອ່ານກ່ຽວກັບ ວິທີການສ້າງໂຄງສ້າງພື້ນຖານຂອງບໍລິສັດ. ຫ້ອງຮຽນທີ່ມີການນໍາໃຊ້ເຄື່ອງແມ່ຂ່າຍຂອງ Dell R730xd E5-2650 v4 ມູນຄ່າ 9000 ເອີໂຣສໍາລັບເງິນບໍ?

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