7 ການປະຕິບັດທີ່ດີທີ່ສຸດສໍາລັບການນໍາໃຊ້ containers ອີງຕາມ Google

ຫມາຍ​ເຫດ​. ແປ.: ຜູ້ຂຽນຂອງບົດຄວາມຕົ້ນສະບັບແມ່ນ Théo Chamley, Google Cloud Solutions Architect. ໃນບົດຂຽນນີ້ສໍາລັບ blog Google Cloud, ລາວໃຫ້ບົດສະຫຼຸບຂອງຄໍາແນະນໍາທີ່ລະອຽດກວ່າຂອງບໍລິສັດຂອງລາວ, ເອີ້ນວ່າ "ການປະຕິບັດທີ່ດີທີ່ສຸດສໍາລັບການປະຕິບັດການບັນຈຸ" ໃນນັ້ນ, ຜູ້ຊ່ຽວຊານຂອງ Google ໄດ້ເກັບກໍາຂໍ້ປະຕິບັດທີ່ດີທີ່ສຸດສໍາລັບການປະຕິບັດການບັນຈຸໃນສະພາບການຂອງການນໍາໃຊ້ Google Kubernetes Engine ແລະອື່ນໆ, ແຕະໃສ່ໃນຫົວຂໍ້ທີ່ກວ້າງຂວາງ: ຈາກຄວາມປອດໄພກັບການຕິດຕາມແລະການເຂົ້າສູ່ລະບົບ. ດັ່ງນັ້ນການປະຕິບັດພາຊະນະທີ່ສໍາຄັນທີ່ສຸດຕາມ Google ແມ່ນຫຍັງ?

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

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

1. ໃຊ້ກົນໄກການຕັດໄມ້ແບບພາຊະນະພື້ນເມືອງ

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

ຖ້າທ່ານຕ້ອງການ, ທ່ານຍັງສາມາດຂຽນບັນທຶກໄດ້ ຮູບແບບ JSON. ວິທີການນີ້ຈະເຮັດໃຫ້ມັນງ່າຍທີ່ຈະເພີ່ມ metadata ໃຫ້ເຂົາເຈົ້າ. ແລະກັບພວກເຂົາ, Stackdriver Logging ຈະມີຄວາມສາມາດຄົ້ນຫາຜ່ານບັນທຶກໂດຍໃຊ້ metadata ນີ້.

2. ໃຫ້ແນ່ໃຈວ່າຕູ້ຄອນເທນເນີບໍ່ມີລັດແລະບໍ່ປ່ຽນແປງໄດ້

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

ບໍ່ມີລັດ ໝາຍ ຄວາມວ່າລັດໃດ ໜຶ່ງ (ຂໍ້ມູນຄົງທີ່ຂອງປະເພດໃດ ໜຶ່ງ) ຖືກເກັບຮັກສາໄວ້ຢູ່ນອກກ່ອງບັນຈຸ. ສໍາລັບການນີ້, ອີງຕາມຄວາມຕ້ອງການ, ປະເພດທີ່ແຕກຕ່າງກັນຂອງການເກັບຮັກສາພາຍນອກສາມາດນໍາໃຊ້: Cloud Storage, ດິສຄົງທີ່, Redis, SQL ຄລາວ ຫຼືຖານຂໍ້ມູນທີ່ມີການຄຸ້ມຄອງອື່ນໆ. (ຫມາຍ​ເຫດ​. ແປ.: ອ່ານເພີ່ມເຕີມກ່ຽວກັບເລື່ອງນີ້ໃນບົດຄວາມຂອງພວກເຮົາ "ຜູ້ປະກອບການສໍາລັບ Kubernetes: ວິທີການດໍາເນີນການຄໍາຮ້ອງສະຫມັກຂອງລັດ".)

ປ່ຽນແປງໄດ້ ຫມາຍ​ຄວາມ​ວ່າ container ຈະ​ບໍ່​ໄດ້​ຮັບ​ການ​ດັດ​ແກ້​ໃນ​ໄລ​ຍະ​ຊີ​ວິດ​ຂອງ​ຕົນ: ບໍ່​ມີ​ການ​ປັບ​ປຸງ, patches, ການ​ປ່ຽນ​ແປງ​ການ​ຕັ້ງ​ຄ່າ. ຖ້າທ່ານຕ້ອງການປັບປຸງລະຫັດຄໍາຮ້ອງສະຫມັກຂອງທ່ານຫຼືນໍາໃຊ້ patch, ສ້າງຮູບພາບໃຫມ່ແລະນໍາໃຊ້ມັນ. ມັນ​ແມ່ນ​ແນະ​ນໍາ​ໃຫ້​ຍ້າຍ​ການ​ຕັ້ງ​ຄ່າ​ພາ​ຊະ​ນະ (ພອດ​ຟັງ​, ທາງ​ເລືອກ​ສະ​ພາບ​ແວດ​ລ້ອມ runtime​, ແລະ​ອື່ນໆ​) ອອກ​ນອກ - to ຄວາມລັບ и ConfigMaps. ພວກເຂົາສາມາດປັບປຸງໄດ້ໂດຍບໍ່ຕ້ອງສ້າງຮູບພາບບັນຈຸໃຫມ່. ເພື່ອສ້າງທໍ່ໄດ້ຢ່າງງ່າຍດາຍດ້ວຍການປະກອບຮູບພາບ, ທ່ານສາມາດນໍາໃຊ້ Cloud Build. (ຫມາຍ​ເຫດ​. ແປ.: ພວກເຮົາໃຊ້ເຄື່ອງມື Open Source ສໍາລັບຈຸດປະສົງເຫຼົ່ານີ້ ດີບ.)

ຕົວຢ່າງຂອງການປັບປຸງການຕັ້ງຄ່າ Deployment ໃນ Kubernetes ໂດຍໃຊ້ ConfigMap ທີ່ຕິດຕັ້ງຢູ່ໃນ pods ເປັນ config

3. ຫຼີກເວັ້ນການບັນຈຸສິດທິພິເສດ

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

ຖ້າທ່ານຄຸ້ມຄອງກຸ່ມ, ທ່ານສາມາດນໍາໃຊ້ ນະໂຍບາຍຄວາມປອດໄພ Pod ສໍາ​ລັບ​ຂໍ້​ຈໍາ​ກັດ​ກ່ຽວ​ກັບ​ການ​ນໍາ​ໃຊ້​ພາ​ຊະ​ນະ​ທີ່​ມີ​ສິດ​ທິ​ພິ​ເສດ​.

4. ຫຼີກເວັ້ນການແລ່ນເປັນຮາກ

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

ວິທີທີ່ດີທີ່ສຸດເພື່ອຫຼີກເວັ້ນການນີ້ແມ່ນບໍ່ດໍາເນີນການຫຍັງເປັນຮາກໃນສະຖານທີ່ທໍາອິດ. ເພື່ອເຮັດສິ່ງນີ້, ທ່ານສາມາດນໍາໃຊ້ຄໍາສັ່ງ USER в Dockerfile ຫຼື runAsUser ໃນ Kubernetes. ຜູ້ເບິ່ງແຍງກຸ່ມຍັງສາມາດກຳນົດຄ່າພຶດຕິກຳການບັງຄັບໃຊ້ໄດ້ ນະໂຍບາຍຄວາມປອດໄພ Pod.

5. ເຮັດໃຫ້ແອັບພລິເຄຊັນງ່າຍຕໍ່ການຕິດຕາມ

ເຊັ່ນດຽວກັນກັບການບັນທຶກ, ການຕິດຕາມແມ່ນສ່ວນຫນຶ່ງທີ່ສໍາຄັນຂອງການຄຸ້ມຄອງຄໍາຮ້ອງສະຫມັກ. ການແກ້ໄຂການຕິດຕາມທີ່ນິຍົມໃນຊຸມຊົນ Kubernetes ແມ່ນ Prometheus - ລະບົບທີ່ອັດຕະໂນມັດກວດພົບຝັກແລະການບໍລິການທີ່ຕ້ອງການການຕິດຕາມ. (ຫມາຍ​ເຫດ​. ແປ.: ເບິ່ງຂອງພວກເຮົາ ລາຍ​ງານ​ລະ​ອຽດ​ ກ່ຽວກັບຫົວຂໍ້ການຕິດຕາມການນໍາໃຊ້ Prometheus ແລະ Kubernetes.) Stackdriver ມີຄວາມສາມາດຕິດຕາມກຸ່ມ Kubernetes ແລະປະກອບມີ Prometheus ລຸ້ນຂອງຕົນເອງເພື່ອກວດສອບແອັບພລິເຄຊັນ.

Kubernetes Dashboard ໃນ Stackdriver

Prometheus ຄາດວ່າແອັບພລິເຄຊັນຈະສົ່ງຕໍ່ metrics ໄປຫາຈຸດສິ້ນສຸດ HTTP. ສາມາດໃຊ້ໄດ້ສໍາລັບການນີ້ ຫ້ອງສະຫມຸດລູກຄ້າ Prometheus. ຮູບແບບດຽວກັນຖືກນໍາໃຊ້ໂດຍເຄື່ອງມືອື່ນໆເຊັ່ນ: OpenCensus и ອິຊິໂອ.

6. ເຮັດໃຫ້ສະຖານະສຸຂະພາບຂອງແອັບຯສາມາດໃຊ້ໄດ້

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

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

ທ່ານສາມາດອ່ານເພີ່ມເຕີມກ່ຽວກັບເລື່ອງນີ້ໃນບົດຄວາມທີ່ກ່ຽວຂ້ອງຈາກ Sandeep Dinesh, ຜູ້ສະຫນັບສະຫນູນຜູ້ພັດທະນາຈາກ Google: "ການປະຕິບັດທີ່ດີທີ່ສຸດ Kubernetes: ຕັ້ງຄ່າການກວດສຸຂະພາບດ້ວຍການສຳຫຼວດຄວາມພ້ອມ ແລະຊີວິດການເປັນຢູ່".

7. ເລືອກສະບັບຮູບພາບຂອງທ່ານຢ່າງລະມັດລະວັງ

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

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

PS ຈາກນັກແປ

ອ່ານຍັງຢູ່ໃນ blog ຂອງພວກເຮົາ:

• «ສະຖິຕິ CNCF ໃໝ່ກ່ຽວກັບຕູ້ຄອນເທນເນີ, cloud native ແລະ Kubernetes"
• «7 ຫຼັກການໃນການອອກແບບຄໍາຮ້ອງສະຫມັກທີ່ໃຊ້ໃນຕູ້ຄອນເທນເນີ"
• «11 ວິທີທີ່ຈະ (ບໍ່) ຕົກເປັນເຫຍື່ອຂອງການ Hack Kubernetes"
• «ປະສົບການຂອງພວກເຮົາກັບ Kubernetes ໃນໂຄງການຂະຫນາດນ້ອຍ» (ການ​ທົບ​ທວນ​ຄືນ​ແລະ​ລາຍ​ງານ​ວິ​ດີ​ໂອ​);
• «ການຕິດຕາມແລະ Kubernetes» (ການ​ທົບ​ທວນ​ຄືນ​ແລະ​ລາຍ​ງານ​ວິ​ດີ​ໂອ​);
• «ພວກເຮົາສ້າງຮູບພາບ Docker ສໍາລັບ CI/CD ຢ່າງວ່ອງໄວແລະສະດວກດ້ວຍ dapp» (ການ​ທົບ​ທວນ​ຄືນ​ແລະ​ລາຍ​ງານ​ວິ​ດີ​ໂອ​);
• «ການປະຕິບັດການຈັດສົ່ງຢ່າງຕໍ່ເນື່ອງກັບ Docker» (ການ​ທົບ​ທວນ​ຄືນ​ແລະ​ລາຍ​ງານ​ວິ​ດີ​ໂອ​);
• «ການເສຍຊີວິດຂອງບ້າບໍລິການຈຸລະພາກໃນປີ 2018".

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