Container to conveyor: CRI-O ດຽວນີ້ເປັນຄ່າເລີ່ມຕົ້ນໃນ OpenShift Container Platform 4

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

ວິທີແກ້ໄຂທີ່ຊັດເຈນແມ່ນການໃຊ້ Red Hat Enterprise ເປັນມາດຕະຖານ. Linux CoreOS (ລຸ້ນ Red Hat Enterprise) Linux) ແລະ CRI-O, ແລະນີ້ແມ່ນເຫດຜົນ...

ເນື່ອງຈາກຫົວຂໍ້ຂອງການແລ່ນເຮືອແມ່ນເປັນສິ່ງທີ່ດີຫຼາຍສໍາລັບການຊອກຫາການປຽບທຽບໃນເວລາທີ່ອະທິບາຍການເຮັດວຽກຂອງ Kubernetes ແລະຕູ້ຄອນເທນເນີ, ໃຫ້ພວກເຮົາພະຍາຍາມເວົ້າກ່ຽວກັບບັນຫາທຸລະກິດທີ່ CoreOS ແລະ CRI-O ແກ້ໄຂ, ໂດຍໃຊ້ຕົວຢ່າງ. ການປະດິດສ້າງຂອງ Brunel ສໍາລັບການຜະລິດຕັນ rigging. ໃນປີ 1803, Marc Brunel ໄດ້ຖືກມອບຫມາຍໃຫ້ຜະລິດ 100 ຕັນ rigging ສໍາລັບຄວາມຕ້ອງການຂອງກອງທັບເຮືອອັງກິດການຂະຫຍາຍຕົວ. ຕັນ rigging ແມ່ນປະເພດຂອງ rigging ທີ່ຖືກນໍາໃຊ້ເພື່ອຕິດເຊືອກກັບ sails. ຈົນກ່ວາໃນຕອນຕົ້ນຂອງສະຕະວັດທີ 19, ຕັນເຫຼົ່ານີ້ແມ່ນເຮັດດ້ວຍມື, ແຕ່ Brunel ຄຸ້ມຄອງການຜະລິດອັດຕະໂນມັດແລະໄດ້ເລີ່ມຕົ້ນການຜະລິດຕັນໄດ້ມາດຕະຖານໂດຍໃຊ້ເຄື່ອງມືເຄື່ອງຈັກ. ອັດຕະໂນມັດຂອງຂະບວນການນີ້ຫມາຍຄວາມວ່າຕັນຜົນໄດ້ຮັບແມ່ນຄືກັນ, ສາມາດທົດແທນໄດ້ຢ່າງງ່າຍດາຍຖ້າຫາກວ່າແຕກຫັກ, ແລະສາມາດຜະລິດໄດ້ໃນປະລິມານຫຼາຍ.

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

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

OpenShift 4 ໄດ້ຖືກສ້າງຂື້ນໃນລັກສະນະດັ່ງກ່າວເພື່ອໃຫ້ຄວາມສາມາດໃນການປັບປຸງລະບົບໄດ້ສະດວກສະບາຍຕະຫຼອດວົງຈອນຊີວິດທັງຫມົດຂອງແພລະຕະຟອມ (ສໍາລັບຮຸ່ນ 4.X) ສໍາລັບຜູ້ໃຫ້ບໍລິການຄອມພິວເຕີ້ຟັງທີ່ສໍາຄັນທັງຫມົດ, ເວທີ virtualization ແລະແມ້ກະທັ້ງລະບົບໂລຫະເປົ່າ. ເພື່ອເຮັດສິ່ງນີ້, ໂຫນດຕ້ອງຖືກສ້າງຂື້ນບົນພື້ນຖານຂອງອົງປະກອບທີ່ສາມາດແລກປ່ຽນກັນໄດ້. ເມື່ອກຸ່ມຕ້ອງການ Kubernetes ລຸ້ນໃໝ່, ມັນຍັງໄດ້ຮັບລຸ້ນທີ່ສອດຄ້ອງກັນຂອງ CRI-O ໃນ CoreOS. ນັບຕັ້ງແຕ່ສະບັບ CRI-O ຖືກຜູກມັດໂດຍກົງກັບ Kubernetes, ນີ້ເຮັດໃຫ້ການປ່ຽນແປງໃດໆສໍາລັບການທົດສອບ, ແກ້ໄຂບັນຫາ, ຫຼືຈຸດປະສົງສະຫນັບສະຫນູນ. ນອກຈາກນັ້ນ, ວິທີການນີ້ຫຼຸດຜ່ອນຄ່າໃຊ້ຈ່າຍສໍາລັບຜູ້ໃຊ້ສຸດທ້າຍແລະ Red Hat.

ນີ້ແມ່ນວິທີການໃຫມ່ໂດຍພື້ນຖານຂອງການຄິດກ່ຽວກັບກຸ່ມ Kubernetes ແລະວາງພື້ນຖານສໍາລັບການວາງແຜນລັກສະນະໃຫມ່ທີ່ເປັນປະໂຫຍດແລະຫນ້າສົນໃຈຫຼາຍ. CRI-O (Container Runtime Interface - Open Container Initiative, ຫຍໍ້ CRI-OCI) ໄດ້ກາຍເປັນທາງເລືອກທີ່ປະສົບຜົນສໍາເລັດທີ່ສຸດສໍາລັບການສ້າງມະຫາຊົນຂອງ nodes ທີ່ຈໍາເປັນເພື່ອເຮັດວຽກກັບ OpenShift. CRI-O ຈະທົດແທນເຄື່ອງຈັກ Docker ທີ່ໃຊ້ໃນເມື່ອກ່ອນ, ສະເຫນີໃຫ້ຜູ້ໃຊ້ OpenShift ເສດຖະກິດ, ຄວາມຫມັ້ນຄົງ, ງ່າຍດາຍແລະຫນ້າເບື່ອ - ແມ່ນແລ້ວ, ທ່ານໄດ້ຍິນຖືກຕ້ອງ - ເຄື່ອງຈັກບັນຈຸຖັງທີ່ຫນ້າເບື່ອທີ່ສ້າງຂຶ້ນໂດຍສະເພາະສໍາລັບການເຮັດວຽກກັບ Kubernetes.

ໂລກຂອງຕູ້ຄອນເທນເນີເປີດ

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

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

ຊຸມຊົນ Kubernetes ຫຼັງຈາກນັ້ນໄດ້ພັດທະນາມາດຕະຖານດຽວສໍາລັບການໂຕ້ຕອບ pluggable, ເອີ້ນວ່າ Container Runtime Interface (CRI). ຂໍຂອບໃຈກັບສິ່ງດັ່ງກ່າວ, ຜູ້ໃຊ້ Kubernetes ສາມາດເຊື່ອມຕໍ່ເຄື່ອງຈັກຕ່າງໆເພື່ອເຮັດວຽກກັບບັນຈຸນອກເຫນືອໄປຈາກ Docker.

ວິສະວະກອນທີ່ Red Hat ແລະ Google ໄດ້ເຫັນຄວາມຕ້ອງການຂອງຕະຫຼາດເຄື່ອງຈັກບັນຈຸທີ່ສາມາດຍອມຮັບຄໍາຮ້ອງຂໍ Kubelet ໃນໄລຍະອະນຸສັນຍາ CRI ແລະແນະນໍາເຄື່ອງບັນຈຸທີ່ເຂົ້າກັນໄດ້ກັບຂໍ້ກໍານົດຂອງ OCI ທີ່ໄດ້ກ່າວມາຂ້າງເທິງ. ດັ່ງນັ້ນ OCID ປາກົດ. ແຕ່​ຂໍ​ອະ​ໄພ, ພວກ​ເຮົາ​ບໍ່​ໄດ້​ເວົ້າ​ວ່າ​ອຸ​ປະ​ກອນ​ການ​ນີ້​ຈະ​ອຸ​ທິດ​ຕົນ​ເພື່ອ CRI-O? ຕົວຈິງແລ້ວມັນແມ່ນ, ພຽງແຕ່ມີການປ່ອຍ ຮຸ່ນ 1.0 ໂຄງການດັ່ງກ່າວໄດ້ປ່ຽນຊື່ເປັນ CRI-O.

ຊາວ. . 1.

ນະວັດຕະກໍາກັບ CRI-O ແລະ CoreOS

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

ລໍຖ້າ, ນີ້ແມ່ນແນວໃດ?

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

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

ການນໍາໃຊ້ Operators ໃນແພລະຕະຟອມ, OpenShift 4 ເອົາ paradigm ໃຫມ່ນີ້ (ການນໍາໃຊ້ແນວຄວາມຄິດຂອງການຕັ້ງຄ່າແລະສະຖານະຕົວຈິງ) ກັບການຄຸ້ມຄອງຂອງ RHEL CoreOS ແລະ CRI-O. ວຽກງານຂອງການຕັ້ງຄ່າແລະການຄຸ້ມຄອງສະບັບຂອງລະບົບປະຕິບັດການແລະເຄື່ອງຈັກບັນຈຸແມ່ນອັດຕະໂນມັດໂດຍໃຊ້ອັນທີ່ເອີ້ນວ່າ. ຕົວປະຕິບັດການປັບຄ່າເຄື່ອງຈັກ (MCO). MCO ປັບປຸງການເຮັດວຽກຂອງຜູ້ບໍລິຫານກຸ່ມຢ່າງງ່າຍດາຍ, ໂດຍພື້ນຖານແລ້ວແມ່ນເຮັດໃຫ້ການຕິດຕັ້ງຂັ້ນຕອນສຸດທ້າຍຂອງການຕິດຕັ້ງອັດຕະໂນມັດ, ເຊັ່ນດຽວກັນກັບການດໍາເນີນງານຫຼັງການຕິດຕັ້ງຕໍ່ມາ (ມື້ສອງການດໍາເນີນງານ). ທັງຫມົດນີ້ເຮັດໃຫ້ OpenShift 4 ເປັນແພລະຕະຟອມຟັງທີ່ແທ້ຈິງ. ພວກເຮົາຈະເຂົ້າໄປໃນເລື່ອງນີ້ເລັກນ້ອຍຕໍ່ມາ.

ແລ່ນບັນຈຸ

ຜູ້ໃຊ້ໄດ້ມີໂອກາດທີ່ຈະໃຊ້ເຄື່ອງຈັກ CRI-O ໃນແພລະຕະຟອມ OpenShift ຕັ້ງແຕ່ຮຸ່ນ 3.7 ໃນສະຖານະ Tech Preview ແລະຈາກຮຸ່ນ 3.9 ໃນສະຖານະທົ່ວໄປ (ປະຈຸບັນໄດ້ຮັບການສະຫນັບສະຫນູນ). ນອກຈາກນັ້ນ, Red Hat ນໍາໃຊ້ຢ່າງຫຼວງຫຼາຍ CRI-O ສໍາລັບການເຮັດວຽກການຜະລິດ ໃນ OpenShift Online ຕັ້ງແຕ່ເວີຊັນ 3.10. ທັງໝົດນີ້ເຮັດໃຫ້ທີມງານທີ່ເຮັດວຽກຢູ່ CRI-O ໄດ້ຮັບປະສົບການຢ່າງກວ້າງຂວາງໃນການເປີດຕົວບັນຈຸບັນຈຸຢູ່ໃນກຸ່ມ Kubernetes ຂະຫນາດໃຫຍ່. ເພື່ອໃຫ້ໄດ້ຄວາມເຂົ້າໃຈຂັ້ນພື້ນຖານກ່ຽວກັບວິທີການ Kubernetes ໃຊ້ CRI-O, ໃຫ້ເບິ່ງຕົວຢ່າງຕໍ່ໄປນີ້, ເຊິ່ງສະແດງໃຫ້ເຫັນວິທີການເຮັດວຽກຂອງສະຖາປັດຕະຍະກໍາ.

ເຂົ້າ. 2. ກ່ອງບັນຈຸເຮັດວຽກແນວໃດໃນກຸ່ມ Kubernetes

CRI-O ເຮັດໃຫ້ການສ້າງ hosts ບັນຈຸໃຫມ່ງ່າຍຂຶ້ນໂດຍການ synchronizing ລະດັບເທິງທັງຫມົດໃນເວລາທີ່ເລີ່ມຕົ້ນ nodes ໃຫມ່, ແລະໃນເວລາທີ່ປ່ອຍເວີຊັນໃຫມ່ຂອງແພລະຕະຟອມ OpenShift. ການແກ້ໄຂຂອງແພລະຕະຟອມທັງຫມົດອະນຸຍາດໃຫ້ມີການປັບປຸງການເຮັດທຸລະກໍາ / rollbacks, ແລະຍັງປ້ອງກັນການຢຸດຊະງັກຂອງການເພິ່ງພາອາໄສລະຫວ່າງແກນຫາງຕູ້ຄອນເທນເນີ, ເຄື່ອງຈັກບັນຈຸ, ໂຫນດ (Kubelets) ແລະ Kubernetes Master node. ໂດຍສູນກາງການຄຸ້ມຄອງອົງປະກອບຂອງແພລະຕະຟອມທັງຫມົດ, ດ້ວຍການຄວບຄຸມແລະສະບັບ, ມີເສັ້ນທາງທີ່ຊັດເຈນສະເຫມີຈາກລັດ A ຫາລັດ B. ນີ້ເຮັດໃຫ້ຂະບວນການປັບປຸງງ່າຍຂຶ້ນ, ປັບປຸງຄວາມປອດໄພ, ປັບປຸງການລາຍງານການປະຕິບັດ, ແລະຊ່ວຍຫຼຸດຜ່ອນຄ່າໃຊ້ຈ່າຍໃນການປັບປຸງແລະການຕິດຕັ້ງເວີຊັນໃຫມ່. .

ສະແດງໃຫ້ເຫັນພະລັງງານຂອງອົງປະກອບທົດແທນ

ດັ່ງທີ່ໄດ້ກ່າວມາກ່ອນຫນ້ານີ້, ການນໍາໃຊ້ Machine Config Operator ເພື່ອຈັດການ host host ແລະ container engine ໃນ OpenShift 4 ສະຫນອງລະດັບໃຫມ່ຂອງອັດຕະໂນມັດທີ່ບໍ່ເປັນໄປໄດ້ໃນເວທີ Kubernetes. ເພື່ອສະແດງຄຸນສົມບັດໃໝ່, ພວກເຮົາຈະສະແດງວິທີທີ່ທ່ານສາມາດປ່ຽນແປງໄຟລ໌ crio.conf. ເພື່ອຫຼີກເວັ້ນການສັບສົນໂດຍຄໍາສັບ, ພະຍາຍາມສຸມໃສ່ຜົນໄດ້ຮັບ.

ທຳອິດ, ໃຫ້ເຮົາສ້າງສິ່ງທີ່ເອີ້ນວ່າ container runtime configuration - Container Runtime Config . ຄິດວ່າມັນເປັນຊັບພະຍາກອນ Kubernetes ທີ່ເປັນຕົວແທນຂອງການຕັ້ງຄ່າສໍາລັບ CRI-O. ໃນຄວາມເປັນຈິງ, ມັນແມ່ນສະບັບພິເສດຂອງບາງສິ່ງບາງຢ່າງທີ່ເອີ້ນວ່າ MachineConfig, ເຊິ່ງເປັນການຕັ້ງຄ່າໃດໆທີ່ຖືກນໍາໃຊ້ກັບເຄື່ອງຈັກ RHEL CoreOS ເປັນສ່ວນຫນຶ່ງຂອງກຸ່ມ OpenShift.

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

ສັງເກດເຫັນສອງແຖວສຸດທ້າຍທີ່ພວກເຮົາຈະປ່ຽນຢູ່ໃນໄຟລ໌ /etc/crio/crio.conf. ສອງເສັ້ນນີ້ແມ່ນຄ້າຍຄືກັນກັບສາຍໃນໄຟລ໌ crio.conf, ພວກມັນຄື:

vi ContainerRuntimeConfig.yaml

ສະຫຼຸບ:

apiVersion: machineconfiguration.openshift.io/v1
kind: ContainerRuntimeConfig
metadata:
 name: set-log-and-pid
spec:
 machineConfigPoolSelector:
   matchLabels:
     debug-crio: config-log-and-pid
 containerRuntimeConfig:
   pidsLimit: 2048
   logLevel: debug

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

oc create -f ContainerRuntimeConfig.yaml
oc get ContainerRuntimeConfig

ສະຫຼຸບ:

NAME              AGE
set-log-and-pid   22h

ເມື່ອພວກເຮົາສ້າງ ContainerRuntimeConfig, ພວກເຮົາຈໍາເປັນຕ້ອງໄດ້ແກ້ໄຂຫນຶ່ງໃນ MachineConfigPools ເພື່ອສົ່ງສັນຍານໃຫ້ Kubernetes ວ່າພວກເຮົາຕ້ອງການໃຊ້ການຕັ້ງຄ່ານີ້ກັບກຸ່ມສະເພາະຂອງເຄື່ອງຈັກໃນກຸ່ມ. ໃນກໍລະນີນີ້ພວກເຮົາຈະປ່ຽນ MachineConfigPool ສໍາລັບແມ່ບົດ nodes:

oc edit MachineConfigPool/master

ສະຫຼຸບ (ເພື່ອຄວາມຊັດເຈນ, ເນື້ອໃນຕົ້ນຕໍແມ່ນປະໄວ້):

...
metadata:
 creationTimestamp: 2019-04-10T23:42:28Z
 generation: 1
 labels:
   debug-crio: config-log-and-pid
   operator.machineconfiguration.openshift.io/required-for-upgrade: ""
...

ໃນຈຸດນີ້, MCO ເລີ່ມສ້າງໄຟລ໌ crio.conf ໃຫມ່ສໍາລັບກຸ່ມ. ໃນກໍລະນີນີ້, ໄຟລ໌ການຕັ້ງຄ່າສໍາເລັດສົມບູນສາມາດເບິ່ງໄດ້ໂດຍໃຊ້ Kubernetes API. ຈືຂໍ້ມູນການ, ContainerRuntimeConfig ແມ່ນພຽງແຕ່ສະບັບພິເສດຂອງ MachineConfig, ດັ່ງນັ້ນພວກເຮົາສາມາດເຫັນຜົນໄດ້ຮັບໂດຍການເບິ່ງເສັ້ນທີ່ກ່ຽວຂ້ອງໃນ MachineConfigs:

oc get MachineConfigs | grep rendered

ສະຫຼຸບ:

rendered-master-c923f24f01a0e38c77a05acfd631910b                  4.0.22-201904011459-dirty 2.2.0 16h
rendered-master-f722b027a98ac5b8e0b41d71e992f626                  4.0.22-201904011459-dirty 2.2.0 4m
rendered-worker-9777325797fe7e74c3f2dd11d359bc62                  4.0.22-201904011459-dirty 2.2.0 16h

ກະ​ລຸ​ນາ​ສັງ​ເກດ​ວ່າ​ໄຟລ​໌​ການ​ຕັ້ງ​ຄ່າ​ທີ່​ເປັນ​ຜົນ​ໄດ້​ຮັບ​ສໍາ​ລັບ​ຂໍ້​ຕົ້ນ​ສະ​ບັບ​ແມ່ນ​ສະ​ບັບ​ໃຫມ່​ກ​່​ວາ​ການ​ຕັ້ງ​ຄ່າ​ຕົ້ນ​ສະ​ບັບ​. ເພື່ອເບິ່ງມັນ, ດໍາເນີນການຄໍາສັ່ງຕໍ່ໄປນີ້. ໃນເວລາຜ່ານໄປ, ພວກເຮົາສັງເກດວ່ານີ້ອາດຈະເປັນຫນຶ່ງທີ່ດີທີ່ສຸດໃນປະຫວັດສາດຂອງ Kubernetes:

python3 -c "import sys, urllib.parse; print(urllib.parse.unquote(sys.argv[1]))" $(oc get MachineConfig/rendered-master-f722b027a98ac5b8e0b41d71e992f626 -o YAML | grep -B4 crio.conf | grep source | tail -n 1 | cut -d, -f2) | grep pid

ສະຫຼຸບ:

pids_limit = 2048

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

oc get node | grep master

Output:

ip-10-0-135-153.us-east-2.compute.internal   Ready master 23h v1.12.4+509916ce1

ip-10-0-154-0.us-east-2.compute.internal     Ready master 23h v1.12.4+509916ce1

ip-10-0-166-79.us-east-2.compute.internal    Ready master 23h v1.12.4+509916ce1

ຕອນນີ້ໃຫ້ເບິ່ງໄຟລ໌ທີ່ຕິດຕັ້ງ. ທ່ານຈະເຫັນວ່າໄຟລ໌ໄດ້ຖືກປັບປຸງດ້ວຍຄ່າໃຫມ່ສໍາລັບຄໍາສັ່ງ pid ແລະ debug ທີ່ພວກເຮົາກໍານົດໄວ້ໃນຊັບພະຍາກອນ ContainerRuntimeConfig. Elegance ຕົວຂອງມັນເອງ:

oc debug node/ip-10-0-135-153.us-east-2.compute.internal — cat /host/etc/crio/crio.conf | egrep 'debug||pid’

ສະຫຼຸບ:

...
pids_limit = 2048
...
log_level = "debug"
...

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

ຕົວຢ່າງຂ້າງເທິງສະແດງໃຫ້ເຫັນຄວາມສາມາດໃນການເຮັດການປ່ຽນແປງຂອງ OpenShift Container Platform 4 cluster ຂະຫນາດນ້ອຍທີ່ມີສາມໂຫນດການຜະລິດຫຼືກຸ່ມການຜະລິດຂະຫນາດໃຫຍ່ທີ່ມີ 3000 nodes. ໃນກໍລະນີໃດກໍ່ຕາມ, ຈໍານວນການເຮັດວຽກຈະຄືກັນ - ແລະນ້ອຍຫຼາຍ - ພຽງແຕ່ກໍານົດໄຟລ໌ ContainerRuntimeConfig, ແລະປ່ຽນປ້າຍຫນຶ່ງໃນ MachineConfigPool. ແລະທ່ານສາມາດເຮັດສິ່ງນີ້ໄດ້ກັບທຸກລຸ້ນຂອງ OpenShift Container Platform 4.X ທີ່ແລ່ນ Kubernetes ຕະຫຼອດຊີວິດຂອງມັນ.

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

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