ການແກ້ໄຂຂຸມໃນກຸ່ມ Kubernetes. ລາຍງານ ແລະຖອດຂໍ້ຄວາມຈາກ DevOpsConf

Pavel Selivanov, ສະຖາປະນິກການແກ້ໄຂ Southbridge ແລະຄູສອນ Slurm, ໃຫ້ການນຳສະເໜີຢູ່ທີ່ DevOpsConf 2019. ການສົນທະນານີ້ແມ່ນສ່ວນໜຶ່ງຂອງຫົວຂໍ້ໜຶ່ງຂອງຫຼັກສູດທີ່ເລິກເຊິ່ງກ່ຽວກັບ Kubernetes “Slurm Mega”.

Slurm Basic: ການແນະນໍາກ່ຽວກັບ Kubernetes ຈັດຂຶ້ນທີ່ Moscow ໃນວັນທີ 18-20 ພະຈິກ.
Slurm Mega: ຊອກຫາພາຍໃຕ້ຝາປິດຂອງ Kubernetes — Moscow, ວັນທີ 22-24 ພະຈິກ.
Slurm Online: ທັງສອງຫຼັກສູດ Kubernetes ມີຢູ່ສະເໝີ.

ຂ້າງລຸ່ມນີ້ການຕັດແມ່ນ transcript ຂອງບົດລາຍງານ.

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

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

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

ບໍລິສັດທີ່ຜ່ານມາຂອງຂ້ອຍໄດ້ພະຍາຍາມຂາຍບໍລິການດັ່ງກ່າວ. ແລະຂ້ອຍໄດ້ຖືກຖາມໃຫ້ເຈາະກຸ່ມເພື່ອເບິ່ງວ່າການແກ້ໄຂນີ້ເຫມາະສົມຫຼືບໍ່.

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

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

ຂ້າ​ພະ​ເຈົ້າ​ຈະ​ບອກ​ທ່ານ​ດ້ວຍ​ຕົວ​ຢ່າງ​ທີ່​ຂ້າ​ພະ​ເຈົ້າ​ໄດ້​ເຮັດ​ນີ້​ແລະ​ວິ​ທີ​ການ​ປົກ​ປັກ​ຮັກ​ສາ​ຕົວ​ທ່ານ​ເອງ​ຈາກ​ນີ້.

ແຕ່ທໍາອິດ, ໃຫ້ຂ້ອຍແນະນໍາຕົວເອງ. ຂ້ອຍຊື່ Pavel Selivanov. ຂ້ອຍເປັນສະຖາປະນິກຢູ່ Southbridge. ຂ້ອຍເຂົ້າໃຈ Kubernetes, DevOps ແລະສິ່ງແປກປະຫຼາດທຸກປະເພດ. ວິສະວະກອນ Southbridge ແລະຂ້ອຍກໍາລັງກໍ່ສ້າງທັງຫມົດນີ້, ແລະຂ້ອຍກໍາລັງປຶກສາ.

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

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

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

ມີ​ສາມ​ຈຸດ​ທີ່​ຂ້າ​ພະ​ເຈົ້າ​ຈະ​ເວົ້າ​ເຖິງ​ໃນ​ມື້​ນີ້​ແມ່ນ​:

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

ສິ່ງທົ່ວໄປອີກອັນຫນຶ່ງທີ່ຂ້ອຍຈະກ່າວເຖິງແມ່ນສິ່ງທີ່ຂ້ອຍໄດ້ທົດສອບທັງຫມົດນີ້, ເຊິ່ງຂ້ອຍສາມາດເວົ້າໄດ້ຢ່າງແນ່ນອນວ່າມັນເຮັດວຽກທັງຫມົດ.

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

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

ຂ້ອຍສັນຍາວ່າສິ່ງທໍາອິດທີ່ພວກເຮົາຈະເຮັດແມ່ນໄດ້ຮັບສິດທິ admin ກັບ cluster. ພວກເຮົາຕ້ອງການຝັກທີ່ກຽມໄວ້ພິເສດທີ່ຈະທໍາລາຍກຸ່ມ Kubernetes. ທັງໝົດທີ່ພວກເຮົາຕ້ອງເຮັດແມ່ນນຳໃຊ້ມັນໃສ່ກັບກຸ່ມ Kubernetes.

kubectl apply -f pod.yaml

ຝັກນີ້ຈະມາຮອດໜຶ່ງໃນແມ່ບົດຂອງກຸ່ມ Kubernetes. ແລະຫຼັງຈາກນີ້, cluster ຈະສົ່ງຄືນໄຟລ໌ທີ່ເອີ້ນວ່າ admin.conf ກັບພວກເຮົາຢ່າງມີຄວາມສຸກ. ໃນ Cube, ໄຟລ໌ນີ້ເກັບຮັກສາໃບຢັ້ງຢືນຜູ້ເບິ່ງແຍງລະບົບທັງຫມົດ, ແລະໃນເວລາດຽວກັນ configure cluster API. ນີ້ແມ່ນວິທີທີ່ງ່າຍຕໍ່ການເຂົ້າເຖິງ admin, ຂ້າພະເຈົ້າຄິດວ່າ, 98% ຂອງກຸ່ມ Kubernetes.

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

ແລະໃນປັດຈຸບັນກ່ຽວກັບຝັກທີ່ກະກຽມພິເສດ. ພວກເຮົາດໍາເນີນການມັນຢູ່ໃນຮູບພາບໃດກໍ່ຕາມ. ໃຫ້ເອົາ debian:jessie ເປັນຕົວຢ່າງ.

ພວກເຮົາມີສິ່ງນີ້:

tolerations:
-   effect: NoSchedule 
    operator: Exists 
nodeSelector: 
    node-role.kubernetes.io/master: "" 

ຄວາມທົນທານແມ່ນຫຍັງ? ແມ່ບົດໃນກຸ່ມ Kubernetes ປົກກະຕິແລ້ວຖືກໝາຍດ້ວຍສິ່ງທີ່ເອີ້ນວ່າ taint. ແລະຄວາມສໍາຄັນຂອງ "ການຕິດເຊື້ອ" ນີ້ແມ່ນວ່າມັນບອກວ່າ pods ບໍ່ສາມາດຖືກມອບຫມາຍໃຫ້ແມ່ບົດ. ແຕ່ບໍ່ມີໃຜລົບກວນທີ່ຈະຊີ້ບອກໃນຝັກໃດໆວ່າມັນທົນທານຕໍ່ "ການຕິດເຊື້ອ". ພາກສ່ວນຄວາມທົນທານພຽງແຕ່ເວົ້າວ່າຖ້າຫາກວ່າບາງ node ມີ NoSchedule, ຫຼັງຈາກນັ້ນ node ຂອງພວກເຮົາແມ່ນທົນທານຕໍ່ການຕິດເຊື້ອດັ່ງກ່າວ - ແລະບໍ່ມີບັນຫາ.

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

ດ້ວຍສອງພາກນີ້ລາວຈະມາຫານາຍແບບແນ່ນອນ. ແລະລາວຈະຖືກອະນຸຍາດໃຫ້ອາໄສຢູ່ທີ່ນັ້ນ.

ແຕ່ພຽງແຕ່ມາຫາແມ່ແບບບໍ່ພຽງພໍສໍາລັບພວກເຮົາ. ນີ້ຈະບໍ່ໃຫ້ພວກເຮົາຫຍັງ. ຕໍ່ໄປ, ພວກເຮົາມີສອງຢ່າງນີ້:

hostNetwork: true 
hostPID: true 

ພວກເຮົາລະບຸວ່າຝັກຂອງພວກເຮົາ, ທີ່ພວກເຮົາເປີດຕົວ, ຈະອາໄສຢູ່ໃນ kernel namespace, ໃນ namespace ເຄືອຂ່າຍ, ແລະໃນ namespace PID. ເມື່ອ pod ຖືກເປີດຕົວໃນແມ່ບົດ, ມັນຈະສາມາດເບິ່ງການໂຕ້ຕອບທີ່ແທ້ຈິງ, ສົດໆຂອງ node ນີ້, ຟັງການເຂົ້າຊົມທັງຫມົດແລະເບິ່ງ PID ຂອງຂະບວນການທັງຫມົດ.

ຫຼັງຈາກນັ້ນ, ມັນເປັນເລື່ອງເລັກນ້ອຍ. ເອົາ etcd ແລະອ່ານສິ່ງທີ່ທ່ານຕ້ອງການ.

ສິ່ງທີ່ຫນ້າສົນໃຈທີ່ສຸດແມ່ນຄຸນນະສົມບັດ Kubernetes ນີ້, ເຊິ່ງມີຢູ່ໃນນັ້ນໂດຍຄ່າເລີ່ມຕົ້ນ.

volumeMounts:
- mountPath: /host 
  name: host 
volumes:
- hostPath: 
    path: / 
    type: Directory 
  name: host 

ແລະຄວາມສໍາຄັນຂອງມັນແມ່ນວ່າພວກເຮົາສາມາດເວົ້າໃນຝັກທີ່ພວກເຮົາເປີດຕົວ, ເຖິງແມ່ນວ່າບໍ່ມີສິດທິໃນກຸ່ມນີ້, ວ່າພວກເຮົາຕ້ອງການສ້າງປະລິມານຂອງ hostPath ປະເພດ. ນີ້ຫມາຍຄວາມວ່າການເອົາເສັ້ນທາງຈາກເຈົ້າພາບທີ່ພວກເຮົາຈະເປີດຕົວ - ແລະເອົາມັນເປັນປະລິມານ. ແລະຫຼັງຈາກນັ້ນພວກເຮົາເອີ້ນມັນວ່າ: ເຈົ້າພາບ. ພວກເຮົາຕິດຕັ້ງ hostPath ທັງໝົດນີ້ພາຍໃນຝັກ. ໃນຕົວຢ່າງນີ້, ໄປຫາ /host directory.

ຂ້ອຍຈະເຮັດຊ້ຳອີກຄັ້ງ. ພວກເຮົາບອກຝັກໃຫ້ມາຫາແມ່ບົດ, ເອົາ hostNetwork ແລະ hostPID ຢູ່ທີ່ນັ້ນ - ແລະຕິດຕັ້ງຮາກທັງໝົດຂອງແມ່ແບບພາຍໃນຝັກນີ້.

ທ່ານເຂົ້າໃຈວ່າໃນ Debian ພວກເຮົາມີ bash ແລ່ນ, ແລະ bash ນີ້ແລ່ນພາຍໃຕ້ຮາກ. ນັ້ນແມ່ນ, ພວກເຮົາພຽງແຕ່ໄດ້ຮັບຮາກໃນຕົ້ນສະບັບ, ໂດຍບໍ່ມີການມີສິດໃດໆໃນກຸ່ມ Kubernetes.

ຫຼັງຈາກນັ້ນ, ວຽກງານທັງຫມົດແມ່ນເພື່ອໄປທີ່ sub directory /host /etc/kubernetes/pki, ຖ້າຂ້ອຍບໍ່ເຂົ້າໃຈຜິດ, ເອົາໃບຢັ້ງຢືນຕົ້ນສະບັບທັງຫມົດຂອງ cluster ຢູ່ທີ່ນັ້ນແລະ, ຕາມນັ້ນ, ກາຍເປັນຜູ້ບໍລິຫານກຸ່ມ.

ຖ້າທ່ານເບິ່ງມັນດ້ວຍວິທີນີ້, ເຫຼົ່ານີ້ແມ່ນບາງສິດທິທີ່ເປັນອັນຕະລາຍທີ່ສຸດໃນຝັກ - ໂດຍບໍ່ຄໍານຶງເຖິງສິດທິທີ່ຜູ້ໃຊ້ມີ:

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

ທີ່ຂ້ອຍມັກທີ່ສຸດແມ່ນຜູ້ໃຊ້ Root. ແລະ Kubernetes ມີທາງເລືອກ Run As Non-Root. ນີ້ແມ່ນປະເພດຂອງການປົກປ້ອງຈາກແຮກເກີ. ເຈົ້າຮູ້ບໍ່ວ່າ "ໄວຣັດມອນດາວີ" ແມ່ນຫຍັງ? ຖ້າທ່ານເປັນແຮກເກີຢ່າງກະທັນຫັນແລະເຂົ້າມາຫາກຸ່ມ Kubernetes ຂອງຂ້ອຍ, ພວກເຮົາ, ຜູ້ບໍລິຫານທີ່ບໍ່ດີ, ຖາມວ່າ: "ກະລຸນາຊີ້ບອກຢູ່ໃນຝັກຂອງເຈົ້າທີ່ເຈົ້າຈະ hack ກຸ່ມຂອງຂ້ອຍ, ດໍາເນີນການທີ່ບໍ່ແມ່ນຮາກ. ຖ້າບໍ່ດັ່ງນັ້ນ, ມັນຈະເກີດຂຶ້ນທີ່ທ່ານດໍາເນີນການໃນຝັກຂອງທ່ານພາຍໃຕ້ຮາກ, ແລະມັນຈະງ່າຍຫຼາຍສໍາລັບທ່ານທີ່ຈະ hack ຂ້າພະເຈົ້າ. ກະລຸນາປົກປ້ອງຕົວທ່ານເອງຈາກຕົວທ່ານເອງ."

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

ແຕ່ສິ່ງທີ່ຕ້ອງເຮັດກັບທັງຫມົດນີ້?

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

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

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

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

ແລະທຸກສິ່ງທຸກຢ່າງເບິ່ງຄືວ່າດີກັບພວກເຮົາ. ແລະກຸ່ມ Kubernetes ຂອງພວກເຮົາບໍ່ສາມາດຖືກແຮັກພາຍໃນສອງນາທີ.

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

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

ອາດຈະເປັນທຸກຄົນໄດ້ອ່ານບົດຄວາມດຽວກັນກ່ຽວກັບ Habre, ແລະການຕິດຕາມແມ່ນຢູ່ໃນ namespace ການຕິດຕາມ. ຕາຕະລາງ Helm ແມ່ນເອີ້ນວ່າປະມານດຽວກັນສໍາລັບທຸກຄົນ. ຂ້າ​ພະ​ເຈົ້າ​ເດົາ​ວ່າ​ຖ້າ​ຫາກ​ວ່າ​ທ່ານ​ເຮັດ​ການ​ຕິດ​ຕັ້ງ helm ຫມັ້ນ​ຄົງ / prometheus, ທ່ານ​ຈະ​ສິ້ນ​ສຸດ​ລົງ​ດ້ວຍ​ປະ​ມານ​ຊື່​ດຽວ​ກັນ. ແລະສ່ວນຫຼາຍແມ່ນຂ້ອຍຈະບໍ່ຕ້ອງເດົາຊື່ DNS ໃນກຸ່ມຂອງເຈົ້າ. ເນື່ອງຈາກວ່າມັນເປັນມາດຕະຖານ.

ຕໍ່ໄປພວກເຮົາມີ ns dev ທີ່ແນ່ນອນ, ທີ່ທ່ານສາມາດດໍາເນີນການເປັນຝັກທີ່ແນ່ນອນ. ແລະຫຼັງຈາກນັ້ນຈາກຝັກນີ້ມັນງ່າຍຫຼາຍທີ່ຈະເຮັດບາງສິ່ງບາງຢ່າງເຊັ່ນນີ້:

$ curl http://prometheus-kube-state-metrics.monitoring 

prometheus-kube-state-metrics ແມ່ນຫນຶ່ງໃນຜູ້ສົ່ງອອກ Prometheus ທີ່ເກັບກໍາ metrics ຈາກ Kubernetes API ຕົວຂອງມັນເອງ. ມີຫຼາຍຂໍ້ມູນຢູ່ທີ່ນັ້ນ, ສິ່ງທີ່ກໍາລັງແລ່ນຢູ່ໃນກຸ່ມຂອງເຈົ້າ, ມັນແມ່ນຫຍັງ, ເຈົ້າມີບັນຫາຫຍັງກັບມັນ.

ເປັນຕົວຢ່າງທີ່ງ່າຍດາຍ:

kube_pod_container_info{namespace=“kube-system”,pod=”kube-apiserver-k8s- 1″,container=”kube-apiserver”,image=

"gcr.io/google-containers/kube-apiserver:v1.14.5"

,image_id=»docker-pullable://gcr.io/google-containers/kube- apiserver@sha256:e29561119a52adad9edc72bfe0e7fcab308501313b09bf99df4a96 38ee634989″,container_id=»docker://7cbe7b1fea33f811fdd8f7e0e079191110268f2 853397d7daf08e72c22d3cf8b»} 1

ໂດຍການເຮັດຄໍາຮ້ອງຂໍ curl ງ່າຍດາຍຈາກຝັກທີ່ບໍ່ມີສິດທິພິເສດ, ທ່ານສາມາດໄດ້ຮັບຂໍ້ມູນຕໍ່ໄປນີ້. ຖ້າທ່ານບໍ່ຮູ້ວ່າທ່ານກໍາລັງແລ່ນ Kubernetes ລຸ້ນໃດ, ມັນຈະບອກທ່ານໄດ້ງ່າຍ.

ແລະສິ່ງທີ່ຫນ້າສົນໃຈທີ່ສຸດແມ່ນວ່ານອກເຫນືອຈາກການເຂົ້າເຖິງ kube-state-metrics, ທ່ານສາມາດເຂົ້າຫາ Prometheus ໂດຍກົງ. ທ່ານສາມາດເກັບກໍາ metrics ຈາກບ່ອນນັ້ນ. ທ່ານສາມາດສ້າງ metrics ຈາກບ່ອນນັ້ນ. ເຖິງແມ່ນວ່າໃນທາງທິດສະດີ, ທ່ານສາມາດສ້າງແບບສອບຖາມດັ່ງກ່າວຈາກກຸ່ມໃນ Prometheus, ເຊິ່ງພຽງແຕ່ຈະປິດມັນ. ແລະການຕິດຕາມຂອງທ່ານຈະຢຸດເຮັດວຽກຈາກກຸ່ມທັງໝົດ.

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

ຄືກັນກັບ PSP, ມັນຮູ້ສຶກວ່າບັນຫາແມ່ນວ່າເຕັກໂນໂລຢີທີ່ແປກປະຫຼາດທັງຫມົດເຫຼົ່ານີ້ - Kubernetes, Prometheus - ພວກມັນບໍ່ເຮັດວຽກແລະເຕັມໄປດ້ວຍຂຸມ. ບໍ່ແມ່ນແທ້ໆ.

ມີ​ສິ່ງ​ດັ່ງ​ກ່າວ - ນະໂຍບາຍເຄືອຂ່າຍ.

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

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

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

ມີບັນຫາຫນຶ່ງຢູ່ທີ່ນີ້. ໃນຖານະຜູ້ເບິ່ງແຍງທີ່ມີໜວດທຳມະດາ, ທ່ານອາດຕັດສິນໃຈວ່ານະໂຍບາຍເຄືອຂ່າຍບໍ່ຈຳເປັນ. ແລະຫຼັງຈາກອ່ານບົດຄວາມທຸກປະເພດກ່ຽວກັບຊັບພະຍາກອນເຊັ່ນ Habr, ທ່ານໄດ້ຕັດສິນໃຈວ່າ flannel, ໂດຍສະເພາະກັບ host-gateway mode, ແມ່ນສິ່ງທີ່ດີທີ່ສຸດທີ່ທ່ານສາມາດເລືອກໄດ້.

ຂ້ອຍຄວນເຮັດແນວໃດ?

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

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

ເມື່ອທ່ານຍົກກຸ່ມໃຫມ່, ໃນເວລາດຽວກັນໃສ່ Calico ແທນ flannel.

ຈະເຮັດແນວໃດຖ້າໃບຢັ້ງຢືນຂອງເຈົ້າຖືກອອກໃຫ້ເປັນເວລາຫນຶ່ງຮ້ອຍປີແລະເຈົ້າຈະບໍ່ໃຊ້ກຸ່ມຄືນໃຫມ່? ມີສິ່ງດັ່ງກ່າວເປັນ Kube-RBAC-Proxy. ນີ້​ແມ່ນ​ການ​ພັດ​ທະ​ນາ​ທີ່​ເຢັນ​ຫຼາຍ​, ມັນ​ອະ​ນຸ​ຍາດ​ໃຫ້​ທ່ານ​ທີ່​ຈະ​ຝັງ​ຕົວ​ມັນ​ເອງ​ເປັນ sidecar container ກັບ pod ໃດ​ຫນຶ່ງ​ໃນ​ກຸ່ມ Kubernetes​. ແລະຕົວຈິງແລ້ວມັນກໍ່ເພີ່ມການອະນຸຍາດກັບຝັກນີ້ຜ່ານ RBAC ຂອງ Kubernetes ເອງ.

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

ມີບັນຫານ້ອຍໆອີກອັນໜຶ່ງ. Prometheus ບໍ່ແມ່ນຜູ້ດຽວທີ່ມອບຕົວວັດແທກຂອງມັນໃຫ້ກັບໃຜເທົ່ານັ້ນ. ອົງປະກອບຂອງກຸ່ມ Kubernetes ທັງໝົດຂອງພວກເຮົາຍັງສາມາດສົ່ງຄືນຄ່າວັດແທກຂອງຕົນເອງໄດ້.

ແຕ່ດັ່ງທີ່ຂ້ອຍເວົ້າແລ້ວ, ຖ້າທ່ານບໍ່ສາມາດເຂົ້າເຖິງກຸ່ມແລະເກັບກໍາຂໍ້ມູນ, ຢ່າງຫນ້ອຍເຈົ້າສາມາດເປັນອັນຕະລາຍໄດ້.

ສະນັ້ນຂ້ອຍຈະສະແດງສອງວິທີຢ່າງໄວວາວ່າກຸ່ມ Kubernetes ສາມາດທໍາລາຍໄດ້.

ເຈົ້າຈະຫົວເລາະເມື່ອຂ້ອຍບອກເຈົ້າເລື່ອງນີ້, ນີ້ແມ່ນສອງກໍລະນີໃນຊີວິດຈິງ.

ວິ​ທີ​ການ​ຫນຶ່ງ​. ຊັບພະຍາກອນໝົດ.

ເປີດຕົວຝັກພິເສດອີກອັນໜຶ່ງ. ມັນ​ຈະ​ມີ​ພາກ​ສ່ວນ​ເຊັ່ນ​ນີ້​.

resources: 
    requests: 
        cpu: 4 
        memory: 4Gi 

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

ຖ້າຂ້ອຍແລ່ນ pod ດັ່ງກ່າວ, ຂ້ອຍກໍ່ຈະດໍາເນີນການຄໍາສັ່ງ:

$ kubectl scale special-pod --replicas=...

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

ຖ້າພວກເຮົາເບິ່ງອີກເທື່ອຫນຶ່ງໃນເອກະສານ Kubernetes, ພວກເຮົາຈະເຫັນສິ່ງນີ້ເອີ້ນວ່າ Limit Range. ມັນກໍານົດຊັບພະຍາກອນສໍາລັບວັດຖຸກຸ່ມ. ທ່ານສາມາດຂຽນວັດຖຸຂອບເຂດຈໍາກັດໃນ yaml, ນໍາໃຊ້ມັນກັບ namespaces ທີ່ແນ່ນອນ - ແລະຫຼັງຈາກນັ້ນໃນ namespace ນີ້ທ່ານສາມາດເວົ້າວ່າທ່ານມີຊັບພະຍາກອນເລີ່ມຕົ້ນ, ສູງສຸດແລະຕໍາ່ສຸດທີ່ສໍາລັບ pods.

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

ແລະນີ້ແມ່ນວິທີການທີ່ສອງມາຈາກ. ພວກເຮົາເປີດຕົວ 11 ຝັກ. ນັ້ນແມ່ນສິບເອັດຕື້. ນີ້ບໍ່ແມ່ນຍ້ອນວ່າຂ້ອຍມາກັບຕົວເລກດັ່ງກ່າວ, ແຕ່ຍ້ອນວ່າຂ້ອຍເຫັນມັນເອງ.

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

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

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

ຕາມທໍາມະຊາດ, ຂ້າພະເຈົ້າໄດ້ພະຍາຍາມເຮັດເຊັ່ນດຽວກັນໃນ Kubernetes. Kubernetes ບໍ່ພໍໃຈກັບສິບເອັດຕື້ຝັກ, ລາວເວົ້າວ່າ: “ຂ້ອຍເຮັດບໍ່ໄດ້. ເກີນກອງປາກພາຍໃນ." ແຕ່ 1 ຝັກສາມາດເຮັດໄດ້.

ໃນການຕອບສະຫນອງຕໍ່ຫນຶ່ງຕື້, Cube ບໍ່ໄດ້ຖອນຕົວເຂົ້າໄປໃນຕົວຂອງມັນເອງ. ລາວກໍ່ເລີ່ມປັບຂະຫນາດ. ຂະບວນການຕໍ່ໄປອີກແລ້ວ, ມັນໃຊ້ເວລາຫຼາຍທີ່ຈະສ້າງຝັກໃຫມ່. ແຕ່ຂະບວນການຍັງດໍາເນີນຕໍ່ໄປ. ບັນຫາພຽງແຕ່ວ່າຖ້າຂ້ອຍສາມາດເປີດຕົວ pods ໄດ້ບໍ່ຈໍາກັດໃນ namespace ຂອງຂ້ອຍ, ເຖິງແມ່ນວ່າບໍ່ມີຄໍາຮ້ອງຂໍແລະຂໍ້ຈໍາກັດ, ຂ້ອຍສາມາດເປີດຕົວ pods ຫຼາຍດ້ວຍບາງວຽກທີ່ການຊ່ວຍເຫຼືອຂອງວຽກງານເຫຼົ່ານີ້ nodes ຈະເລີ່ມເພີ່ມໃນຫນ່ວຍຄວາມຈໍາ, ໃນ CPU. ເມື່ອຂ້ອຍເປີດຕົວຝັກຈໍານວນຫຼາຍ, ຂໍ້ມູນຈາກພວກມັນຄວນຈະເຂົ້າໄປໃນບ່ອນເກັບຮັກສາ, ນັ້ນແມ່ນ, ແລະອື່ນໆ. ແລະເມື່ອຂໍ້ມູນຫຼາຍເກີນໄປມາຮອດບ່ອນນັ້ນ, ການເກັບຮັກສາເລີ່ມຕົ້ນກັບຄືນມາຊ້າເກີນໄປ - ແລະ Kubernetes ເລີ່ມຈືດໆ.

ແລະອີກບັນຫາຫນຶ່ງ ... ດັ່ງທີ່ທ່ານຮູ້, ອົງປະກອບການຄວບຄຸມ Kubernetes ບໍ່ແມ່ນສິ່ງຫນຶ່ງທີ່ເປັນສູນກາງ, ແຕ່ອົງປະກອບຈໍານວນຫນຶ່ງ. ໂດຍສະເພາະ, ມີຜູ້ຈັດການຄວບຄຸມ, ຜູ້ກໍານົດເວລາ, ແລະອື່ນໆ. guys ທັງຫມົດເຫຼົ່ານີ້ຈະເລີ່ມຕົ້ນທີ່ຈະເຮັດວຽກທີ່ບໍ່ຈໍາເປັນ, stupid ໃນເວລາດຽວກັນ, ເຊິ່ງໃນໄລຍະເວລາຈະເລີ່ມໃຊ້ເວລາຫຼາຍແລະຫຼາຍ. ຜູ້ຈັດການຄວບຄຸມຈະສ້າງຝັກໃຫມ່. Scheduler ຈະພະຍາຍາມຊອກຫາ node ໃຫມ່ສໍາລັບພວກເຂົາ. ສ່ວນຫຼາຍເຈົ້າຈະໝົດຂໍ້ໃໝ່ໃນກຸ່ມຂອງເຈົ້າໃນໄວໆນີ້. ກຸ່ມ Kubernetes ຈະເລີ່ມເຮັດວຽກຊ້າລົງ ແລະຊ້າລົງ.

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

ສໍາລັບຕົວຢ່າງ, ຖ້າທ່ານດໍາເນີນການຫນຶ່ງພັນລ້ານ pods, ແລະຫຼັງຈາກນັ້ນໃຊ້ສະຄິບເພື່ອບັງຄັບ Kubernetis ສ້າງບໍລິການໃຫມ່:

for i in {1..1111111}; do
    kubectl expose deployment test --port 80  
        --overrides="{"apiVersion": "v1", 
           "metadata": {"name": "nginx$i"}}"; 
done 

ໃນທຸກ nodes ຂອງກຸ່ມ, ກົດ iptables ໃໝ່ໆ ຫຼາຍຂຶ້ນຈະຖືກສ້າງຂື້ນປະມານພ້ອມໆກັນ. ຍິ່ງໄປກວ່ານັ້ນ, ຫນຶ່ງຕື້ iptables ກົດລະບຽບຈະຖືກສ້າງຂຶ້ນສໍາລັບແຕ່ລະບໍລິການ.

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

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

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

ໂຄຕ້າຊັບພະຍາກອນ + ຂອບເຂດຈຳກັດ + RBAC
• ສ້າງ namespace
• ສ້າງຂອບເຂດຈໍາກັດພາຍໃນ
•ສ້າງພາຍໃນ resourcequota
•ສ້າງບັນຊີການບໍລິການສໍາລັບ CI
•ສ້າງ rolebinding ສໍາລັບ CI ແລະຜູ້ໃຊ້
• ທາງເລືອກໃນການເປີດຕົວພອດບໍລິການທີ່ຈໍາເປັນ

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

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

ນ້ອຍຫນຶ່ງ ເຮັດໃຫ້ຂະບວນການສະລັບສັບຊ້ອນທັງຫມົດນີ້ງ່າຍຂຶ້ນ.

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

ນະໂຍບາຍເຄືອຂ່າຍບໍ່ພຽງແຕ່ເປັນລັກສະນະທີ່ບໍ່ຈໍາເປັນອື່ນ. ນີ້ແມ່ນສິ່ງທີ່ຈໍາເປັນແທ້ໆໃນກຸ່ມ.

LimitRange/ResourceQuota - ມັນເຖິງເວລາທີ່ຈະໃຊ້ມັນ. ພວກເຮົາເລີ່ມໃຊ້ອັນນີ້ມາດົນນານແລ້ວ, ແລະເປັນເວລາດົນຂ້ອຍແນ່ໃຈວ່າທຸກຄົນໄດ້ໃຊ້ມັນ. ມັນໄດ້ຫັນອອກວ່ານີ້ແມ່ນຫາຍາກ.

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

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

ທີ່ນີ້ ມີຄໍາແນະນໍາກ່ຽວກັບວິທີການແຜ່ພັນທຸກສິ່ງທີ່ຂ້ອຍບອກເຈົ້າ. ມີໄຟລ໌ທີ່ມີຕົວຢ່າງການຜະລິດຂອງ ResourceQuota ແລະນະໂຍບາຍຄວາມປອດໄພ Pod ຄ້າຍຄື. ແລະທ່ານສາມາດແຕະທັງຫມົດນີ້.

ຂອບໃຈທຸກຄົນ.

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