ການປະຕິບັດທີ່ດີທີ່ສຸດ Kubernetes. ການສ້າງຖັງຂະຫນາດນ້ອຍ

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

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

ນອກຈາກນັ້ນ, ຮູບພາບສ່ວນໃຫຍ່ໃນ Docker ໃຊ້ Debian ຫຼື Ubuntu ສໍາລັບຮູບພາບພື້ນຖານ, ແລະໃນຂະນະທີ່ນີ້ສະຫນອງຄວາມເຂົ້າກັນໄດ້ທີ່ດີເລີດແລະການປັບແຕ່ງງ່າຍ (ໄຟລ໌ Docker ໃຊ້ເວລາພຽງແຕ່ສອງເສັ້ນຂອງລະຫັດ), ຮູບພາບພື້ນຖານສາມາດເພີ່ມການໂຫຼດເພີ່ມເຕີມຫຼາຍຮ້ອຍ megabytes ໃສ່ຖັງຂອງທ່ານ. ຕົວຢ່າງ, ໄຟລ໌ node.js ງ່າຍໆສໍາລັບແອັບພລິເຄຊັນ Go "hello-world" ແມ່ນປະມານ 700 megabytes, ໃນຂະນະທີ່ຄໍາຮ້ອງສະຫມັກຕົວຈິງຂອງເຈົ້າມີຂະຫນາດພຽງແຕ່ສອງສາມ megabytes.

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

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

ໂດຍຄ່າເລີ່ມຕົ້ນໃນ Docker, node:8 base image size is 670 MB, and the node: 8-alpine image size is only 65 MB, that is, 10 times smaller. ໂດຍການນໍາໃຊ້ຮູບພາບຖານ Alpine ຂະຫນາດນ້ອຍກວ່າ, ທ່ານຈະຫຼຸດລົງຢ່າງຫຼວງຫຼາຍຂອງຂະຫນາດບັນຈຸຂອງທ່ານ. Alpine ເປັນການແຈກຢາຍ Linux ຂະໜາດນ້ອຍ ແລະ ນ້ຳໜັກເບົາ ທີ່ເປັນທີ່ນິຍົມກັນຫຼາຍໃນບັນດາຜູ້ໃຊ້ Docker ເພາະວ່າມັນເຂົ້າກັນໄດ້ກັບຫຼາຍແອັບພລີເຄຊັນ ໃນຂະນະທີ່ເກັບຮັກສາບັນຈຸນ້ອຍໆ. ບໍ່ເຫມືອນກັບຮູບພາບ Docker "node" ມາດຕະຖານ, "node:alpine" ຈະເອົາໄຟລ໌ບໍລິການແລະໂຄງການຈໍານວນຫຼາຍ, ປ່ອຍໃຫ້ພຽງແຕ່ໄຟລ໌ທີ່ພຽງພໍເພື່ອດໍາເນີນການຄໍາຮ້ອງສະຫມັກຂອງທ່ານ.

ເພື່ອຍ້າຍໄປຫາຮູບພາບພື້ນຖານທີ່ນ້ອຍກວ່າ, ພຽງແຕ່ປັບປຸງ Dockerfile ເພື່ອເລີ່ມຕົ້ນການເຮັດວຽກກັບຮູບພາບພື້ນຖານໃຫມ່:

ໃນປັດຈຸບັນ, ບໍ່ເຫມືອນກັບຮູບພາບ onbuild ເກົ່າ, ທ່ານຈໍາເປັນຕ້ອງຄັດລອກລະຫັດຂອງທ່ານເຂົ້າໄປໃນຖັງແລະຕິດຕັ້ງການຂຶ້ນກັບໃດໆ. ໃນ Dockerfile ໃໝ່, container ເລີ່ມຕົ້ນດ້ວຍ node:alpine image, ຈາກນັ້ນສ້າງ directory ສໍາລັບ code, install dependencies ໂດຍໃຊ້ NPM package manager, ແລະສຸດທ້າຍ run server.js.

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

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

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

ໃນ Dockerfile ໃໝ່, ກ່ອງບັນຈຸເລີ່ມຕົ້ນດ້ວຍຮູບ golang:alpine. ຫຼັງຈາກນັ້ນ, ມັນຈະສ້າງໄດເລກະທໍລີສໍາລັບລະຫັດ, ຄັດລອກມັນເຂົ້າໄປໃນລະຫັດແຫຼ່ງ, ສ້າງລະຫັດແຫຼ່ງນັ້ນ, ແລະດໍາເນີນການຄໍາຮ້ອງສະຫມັກ. ຕູ້ຄອນເທນເນີນີ້ມີຂະຫນາດນ້ອຍກວ່າຕູ້ຄອນເທນເນີ onbuild ຫຼາຍ, ແຕ່ມັນຍັງມີ compiler ແລະເຄື່ອງມື Go ອື່ນໆທີ່ພວກເຮົາບໍ່ຕ້ອງການແທ້ໆ. ດັ່ງນັ້ນ, ໃຫ້ພຽງແຕ່ສະກັດໂຄງການທີ່ລວບລວມແລະເອົາໃສ່ໃນຖັງຂອງມັນເອງ.

ທ່ານອາດຈະສັງເກດເຫັນບາງສິ່ງບາງຢ່າງທີ່ແປກປະຫລາດໃນໄຟລ໌ Docker ນີ້: ມັນມີສອງແຖວ FROM. ພາກສ່ວນ 4 ແຖວທໍາອິດມີລັກສະນະຄືກັນກັບ Dockerfile ທີ່ຜ່ານມາຍົກເວັ້ນວ່າມັນໃຊ້ຄໍາສໍາຄັນ AS ເພື່ອຕັ້ງຊື່ຂັ້ນຕອນນີ້. ພາກຕໍ່ໄປມີເສັ້ນ FROM ໃໝ່ເພື່ອເລີ່ມຕົ້ນຮູບໃໝ່, ເຊິ່ງແທນທີ່ຮູບ golang:alpine ພວກເຮົາຈະໃຊ້ Raw alpine ເປັນຮູບຖານ.

Raw Alpine Linux ບໍ່ມີໃບຮັບຮອງ SSL ໃດໆທີ່ຕິດຕັ້ງ, ເຊິ່ງຈະເຮັດໃຫ້ການໂທ API ສ່ວນໃຫຍ່ຜ່ານ HTTPS ລົ້ມເຫລວ, ສະນັ້ນໃຫ້ເຮົາຕິດຕັ້ງໃບຮັບຮອງ root CA ບາງອັນ.

ຕອນນີ້ມາຮອດສ່ວນທີ່ມ່ວນ: ເພື່ອຄັດລອກລະຫັດທີ່ລວບລວມຈາກຖັງທໍາອິດໄປຫາບ່ອນທີສອງ, ທ່ານສາມາດນໍາໃຊ້ຄໍາສັ່ງ COPY ຢູ່ໃນເສັ້ນ 5 ຂອງພາກທີສອງ. ມັນຈະສຳເນົາໄຟລ໌ແອັບພລິເຄຊັນພຽງອັນດຽວ ແລະຈະບໍ່ກະທົບກັບເຄື່ອງມືຂອງ Go. ໄຟລ໌ Docker ຫຼາຍຂັ້ນຕອນໃຫມ່ຈະມີຮູບ container ທີ່ມີຂະຫນາດພຽງແຕ່ 12 megabytes, ເມື່ອທຽບກັບຮູບ container ຕົ້ນສະບັບທີ່ມີ 700 megabytes, ຊຶ່ງເປັນຄວາມແຕກຕ່າງທີ່ຍິ່ງໃຫຍ່!
ດັ່ງນັ້ນ, ການນໍາໃຊ້ຮູບພາບພື້ນຖານຂະຫນາດນ້ອຍແລະ Builder Pattern ແມ່ນວິທີທີ່ດີທີ່ຈະສ້າງຖັງຂະຫນາດນ້ອຍກວ່າໂດຍບໍ່ມີການເຮັດວຽກຫຼາຍ.
ມັນເປັນໄປໄດ້ວ່າຂຶ້ນຢູ່ກັບ stack ຄໍາຮ້ອງສະຫມັກ, ມີວິທີການເພີ່ມເຕີມເພື່ອຫຼຸດຜ່ອນຮູບພາບແລະຂະຫນາດບັນຈຸ, ແຕ່ບັນຈຸຂະຫນາດນ້ອຍມີຜົນປະໂຫຍດທີ່ສາມາດວັດແທກໄດ້ບໍ? ຂໍໃຫ້ເບິ່ງສອງພື້ນທີ່ທີ່ບັນຈຸຂະຫນາດນ້ອຍມີປະສິດທິພາບທີ່ສຸດ - ການປະຕິບັດແລະຄວາມປອດໄພ.

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

Docker ຈະ cache ຊັ້ນຂໍ້ມູນດັ່ງນັ້ນການກໍ່ສ້າງຕໍ່ໄປຈະໄວຫຼາຍ. ຢ່າງໃດກໍຕາມ, ລະບົບ CI ຈໍານວນຫຼາຍທີ່ໃຊ້ໃນການກໍ່ສ້າງແລະການທົດສອບ containers ບໍ່ cache layers, ສະນັ້ນມີການປະຫຍັດເວລາທີ່ສໍາຄັນ. ດັ່ງທີ່ເຈົ້າເຫັນ, ເວລາທີ່ຈະສ້າງຕູ້ຄອນເທນເນີຂະຫນາດໃຫຍ່, ຂຶ້ນກັບພະລັງງານຂອງເຄື່ອງຂອງເຈົ້າແມ່ນຈາກ 34 ຫາ 54 ວິນາທີ, ແລະເມື່ອໃຊ້ຕູ້ຄອນເທນເນີຫຼຸດລົງໂດຍໃຊ້ຮູບແບບ Builder - ຈາກ 23 ຫາ 28 ວິນາທີ. ສໍາລັບການດໍາເນີນງານຂອງປະເພດນີ້, ຜົນຜະລິດຈະເພີ່ມຂຶ້ນ 40-50%. ດັ່ງນັ້ນພຽງແຕ່ຄິດກ່ຽວກັບຈໍານວນຄັ້ງທີ່ທ່ານສ້າງແລະທົດສອບລະຫັດຂອງທ່ານ.

ຫຼັງ​ຈາກ​ການ​ສ້າງ​ພາ​ຊະ​ນະ​, ທ່ານ​ຈໍາ​ເປັນ​ຕ້ອງ​ໄດ້​ຊຸກ​ດັນ​ຮູບ​ພາບ​ຂອງ​ຕົນ (ຮູບ​ພາບ​ການ​ຊຸກ​ຍູ້​ພາ​ຊະ​ນະ​) ເຂົ້າ​ໄປ​ໃນ​ການ​ຈົດ​ທະ​ບຽນ​ຕູ້​ເກັບ​ຮັກ​ສາ​ດັ່ງ​ນັ້ນ​ທ່ານ​ສາ​ມາດ​ນໍາ​ໃຊ້​ມັນ​ໃນ​ກຸ່ມ Kubernetes ຂອງ​ທ່ານ​. ຂ້ອຍຂໍແນະນໍາໃຫ້ໃຊ້ Google Container Registry.

ດ້ວຍ Google Container Registry (GCR), ທ່ານຈ່າຍພຽງແຕ່ສໍາລັບການເກັບຮັກສາດິບແລະເຄືອຂ່າຍ, ແລະບໍ່ມີຄ່າທໍານຽມການຄຸ້ມຄອງຕູ້ຄອນເທນເນີເພີ່ມເຕີມ. ມັນເປັນສ່ວນຕົວ, ປອດໄພ ແລະໄວຫຼາຍ. GCR ໃຊ້ຫຼາຍ tricks ເພື່ອເລັ່ງການດໍາເນີນງານການດຶງ. ດັ່ງທີ່ທ່ານສາມາດເບິ່ງເຫັນໄດ້, ການໃສ່ກ່ອງບັນຈຸຮູບພາບຂອງ Docker Container ໂດຍໃຊ້ go:onbuild ຈະໃຊ້ເວລາຈາກ 15 ຫາ 48 ວິນາທີ, ຂຶ້ນກັບການປະຕິບັດຂອງຄອມພິວເຕີ, ແລະການດໍາເນີນງານດຽວກັນກັບພາຊະນະຂະຫນາດນ້ອຍຈະໃຊ້ເວລາຈາກ 14 ຫາ 16 ວິນາທີ, ແລະສໍາລັບເຄື່ອງຈັກທີ່ມີຜົນຜະລິດຫນ້ອຍ. ຄວາມໄດ້ປຽບໃນຄວາມໄວການດໍາເນີນງານເພີ່ມຂຶ້ນ 3 ເທົ່າ. ສໍາລັບເຄື່ອງຈັກຂະຫນາດໃຫຍ່, ເວລາແມ່ນປະມານດຽວກັນ, ເນື່ອງຈາກວ່າ GCR ໃຊ້ cache ທົ່ວໂລກສໍາລັບຖານຂໍ້ມູນຮູບພາບທີ່ແບ່ງປັນ, ຊຶ່ງຫມາຍຄວາມວ່າທ່ານບໍ່ຈໍາເປັນຕ້ອງໂຫລດພວກມັນເລີຍ. ໃນຄອມພິວເຕີທີ່ມີພະລັງງານຕ່ໍາ, CPU ແມ່ນຄໍຂວດ, ດັ່ງນັ້ນປະໂຫຍດຂອງການນໍາໃຊ້ບັນຈຸຂະຫນາດນ້ອຍແມ່ນມີຫຼາຍກວ່ານີ້.

ຖ້າທ່ານກໍາລັງໃຊ້ GCR, ຂ້າພະເຈົ້າຂໍແນະນໍາໃຫ້ໃຊ້ Google Container Builder (GCB) ເປັນສ່ວນຫນຶ່ງຂອງລະບົບການກໍ່ສ້າງຂອງທ່ານ.

ດັ່ງທີ່ທ່ານສາມາດເຫັນໄດ້, ການນໍາໃຊ້ຂອງມັນຊ່ວຍໃຫ້ທ່ານບັນລຸຜົນໄດ້ຮັບທີ່ດີກວ່າໃນການຫຼຸດຜ່ອນໄລຍະເວລາຂອງການດໍາເນີນງານ Build + Push ກ່ວາເຄື່ອງຈັກທີ່ຜະລິດ - ໃນກໍລະນີນີ້, ຂະບວນການສ້າງແລະສົ່ງຕູ້ຄອນເທນເນີກັບເຈົ້າພາບແມ່ນເລັ່ງເກືອບ 2 ເທົ່າ. . ນອກຈາກນັ້ນ, ທ່ານໄດ້ຮັບ 120 ນາທີກໍ່ສ້າງຟຣີທຸກໆມື້, ເຊິ່ງກວມເອົາຄວາມຕ້ອງການການກໍ່ສ້າງຕູ້ຄອນເທນເນີຂອງທ່ານໃນກໍລະນີຫຼາຍທີ່ສຸດ.

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

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

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

ຂໍໃຫ້ພິຈາລະນາບັນຫາຄວາມປອດໄພ. ຕູ້ຄອນເທນເນີຂະໜາດນ້ອຍແມ່ນຖືວ່າປອດໄພກວ່າຕູ້ບັນຈຸຂະໜາດໃຫຍ່ ເພາະວ່າມັນມີໜ້າດິນການໂຈມຕີທີ່ນ້ອຍກວ່າ. ແມ່ນແທ້ບໍ? ຫນຶ່ງໃນລັກສະນະທີ່ເປັນປະໂຫຍດທີ່ສຸດຂອງ Google Container Registry ແມ່ນຄວາມສາມາດໃນການສະແກນກ່ອງບັນຈຸຂອງທ່ານໂດຍອັດຕະໂນມັດສໍາລັບຊ່ອງຫວ່າງ. ສອງສາມເດືອນກ່ອນຫນ້ານີ້ຂ້າພະເຈົ້າໄດ້ສ້າງທັງ onbuild ແລະ multistage containers, ດັ່ງນັ້ນໃຫ້ພວກເຮົາເບິ່ງວ່າມີຊ່ອງຫວ່າງໃດໆຢູ່ທີ່ນັ້ນ.

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

Takeaway ແມ່ນຈະແຈ້ງ: ສ້າງຕູ້ຄອນເທນເນີຂະຫນາດນ້ອຍເພາະວ່າພວກເຂົາສະຫນອງການປະຕິບັດທີ່ແທ້ຈິງແລະຜົນປະໂຫຍດດ້ານຄວາມປອດໄພກັບລະບົບຂອງທ່ານ.

ການປະຕິບັດທີ່ດີທີ່ສຸດ Kubernetes. ການຈັດຕັ້ງຂອງ Kubernetes ທີ່ມີ namespace

ບາງໂຄສະນາ🙂

ຂອບໃຈສໍາລັບການຢູ່ກັບພວກເຮົາ. ເຈົ້າມັກບົດຄວາມຂອງພວກເຮົາບໍ? ຕ້ອງການເບິ່ງເນື້ອຫາທີ່ຫນ້າສົນໃຈຫຼາຍບໍ? ສະຫນັບສະຫນູນພວກເຮົາໂດຍການວາງຄໍາສັ່ງຫຼືແນະນໍາໃຫ້ຫມູ່ເພື່ອນ, 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