Top 10 Tricks Kubernetes ແລະເຄັດລັບ

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

ຄໍາສັ່ງທີ່ງ່າຍທີ່ສຸດທີ່ຈະເຮັດວຽກກັບ Kubernetes

ເພື່ອເລີ່ມຕົ້ນດ້ວຍ, ບາງທີການກະ ທຳ ທີ່ງ່າຍທີ່ສຸດແລະເປັນປະໂຫຍດທີ່ສຸດໃນການເຮັດວຽກກັບ Kubernetes. ຄໍາສັ່ງຕໍ່ໄປນີ້ເຮັດໃຫ້ຄໍາສັ່ງສໍາເລັດ kubectl ໃນ bash shell:

echo "source <(kubectl completion bash)" >> ~/.bashrc

ອັດຕະໂນມັດ kubectl ຈະຖືກຂຽນໃສ່ໄຟລ໌ .bashrc ແລະຈະຖືກເປີດໃຊ້ໂດຍອັດຕະໂນມັດທຸກຄັ້ງທີ່ແກະເລີ່ມຕົ້ນ. ນີ້ເລັ່ງການພິມຄໍາສັ່ງຍາວແລະຕົວກໍານົດການເຊັ່ນ: all-namespaces. ອ່ານເພີ່ມເຕີມໃນ Kubernetes ຊ່ວຍເຫຼືອ bash.

ຄວາມຈຳເລີ່ມຕົ້ນ ແລະ CPU ຈຳກັດຢູ່ໃນ namespace

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

ເພື່ອປ້ອງກັນສິ່ງດັ່ງກ່າວ, Kubernetes ອະນຸຍາດໃຫ້ທ່ານຕັ້ງຂໍ້ຈຳກັດໄວ້ໃນຕອນຕົ້ນບົນພື້ນຖານແຕ່ລະ namespace. ພວກມັນຖືກຂຽນໄວ້ໃນໄຟລ໌ yaml ສໍາລັບ namespace ສະເພາະ. ນີ້ແມ່ນຕົວຢ່າງຂອງໄຟລ໌ດັ່ງກ່າວ:

apiVersion: v1
kind: LimitRange
metadata:
  name: mem-limit-range
spec:
  limits:
  - default:
      memory: 512Mi
    defaultRequest:
      memory: 256Mi
    type: Container

ສ້າງ yaml ດັ່ງກ່າວແລະນໍາໃຊ້ກັບ namespace ໃດ. ຕົວຢ່າງ, ໄປຫາ namespace limit-example. ດຽວນີ້ຕູ້ຄອນເທນເນີໃດນຶ່ງທີ່ນຳໃຊ້ຢູ່ໃນ namespace ນີ້ຈະມີຂີດຈຳກັດ 512Mi, ເວັ້ນເສຍແຕ່ຈະກຳນົດຂີດຈຳກັດຂອງບຸກຄົນອື່ນສຳລັບບັນຈຸນີ້.

ການເກັບຂີ້ເຫຍື້ອໃນ Kubernetes ລຸ້ນເກົ່າ

Kubelet ໂດຍຄ່າເລີ່ມຕົ້ນເລີ່ມຕົ້ນການເກັບຂີ້ເຫຍື້ອເມື່ອ var/lib/docker ຄອບຄອງ 90% ຂອງພື້ນທີ່ດິດທີ່ມີຢູ່. ນີ້ແມ່ນດີ, ຢ່າງໃດກໍຕາມ, ຈົນກ່ວາ Kubernetes 1.7 ບໍ່ມີກໍານົດໄວ້ໃນຕອນຕົ້ນກ່ຽວກັບຈໍານວນຂອງ inodes ທີ່ໃຊ້, ເຊິ່ງກົງກັບຈໍານວນຂອງໄຟລ໌ໃນລະບົບໄຟລ໌.

ທ່າແຮງທີ່ບັນຈຸຂອງທ່ານ var/lib/docker ອາດຈະໃຊ້ພຽງແຕ່ 50% ຂອງພື້ນທີ່ດິດ, ແຕ່ອາດຈະຫມົດ inodes, ເຊິ່ງຈະເຮັດໃຫ້ເກີດບັນຫາສໍາລັບຄົນງານ.

ໃນ kubelet ຮຸ່ນເກົ່າຈາກ 1.4 ຫາ 1.6 ທ່ານຈະຕ້ອງເພີ່ມທຸງນີ້:

--eviction-hard
=memory.available<100Mi,nodefs.available<10%,nodefs.inodesFree<5%

ໃນລຸ້ນ 1.7 ແລະຕໍ່ມາ ທຸງນີ້ຖືກຕັ້ງເປັນຄ່າເລີ່ມຕົ້ນ. ຢ່າງໃດກໍຕາມ, ສະບັບທີ່ຜ່ານມາບໍ່ໄດ້ຕິດຕາມກວດກາຂອບເຂດຈໍາກັດ inode.

Minikube... Kubernetes ທ້ອງຖິ່ນຂະຫນາດນ້ອຍແຕ່ມີອໍານາດ

Minikube ແມ່ນວິທີທີ່ງ່າຍທີ່ສຸດທີ່ຈະແລ່ນກຸ່ມ Kubernetes ທ້ອງຖິ່ນ. ມັນຖືກເປີດຕົວດ້ວຍຄໍາສັ່ງງ່າຍໆ:

minikube start

ການແລ່ນຄຳສັ່ງນີ້ສົ່ງຜົນໃຫ້ມີກຸ່ມ Kubernetes ທີ່ແທ້ຈິງທີ່ແລ່ນຢູ່ໃນເຄື່ອງຂອງເຈົ້າ.

ແຫຼ່ງຮູບປະກອບ

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

ເພື່ອບັງຄັບ Docker ຍູ້ຮູບພາບໄປຫາກຸ່ມ Kubernetes ທ້ອງຖິ່ນ, ເຄື່ອງ docker ແມ່ນໄດ້ຮັບຄໍາສັ່ງຕໍ່ໄປນີ້:

eval $(minikube docker-env)

ຕອນນີ້ພວກເຮົາສາມາດສ້າງແອັບພລິເຄຊັນຢູ່ໃນກຸ່ມ Kubernetes ທ້ອງຖິ່ນໄດ້.

ບໍ່ໃຫ້ kubectl ເຂົ້າເຖິງທຸກຄົນ

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

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

ຈັດການງົບປະມານ Pod

ເຮັດແນວໃດເພື່ອໃຫ້ແນ່ໃຈວ່າບໍ່ມີເວລາຢຸດສໍາລັບແອັບພລິເຄຊັນໃນກຸ່ມ Kubernetes? PodDisruptionBudget ແລະອີກເທື່ອຫນຶ່ງ PodDisruptionBudget.

ກຸ່ມໄດ້ຖືກປັບປຸງເປັນແຕ່ລະໄລຍະ ແລະ nodes ຫວ່າງເປົ່າ. ບໍ່ມີຫຍັງຢືນຢູ່, ນັ້ນແມ່ນຄວາມຈິງ. ທຸກໆການນຳໃຊ້ທີ່ມີຫຼາຍກວ່າໜຶ່ງຕົວຢ່າງຄວນປະກອບມີ PDB (PodDisruptionBudget). ມັນຖືກສ້າງຂຶ້ນໃນໄຟລ໌ yaml ງ່າຍດາຍທີ່ຖືກນໍາໃຊ້ກັບກຸ່ມ. ພື້ນທີ່ການຄຸ້ມຄອງຂອງ PDB ສະເພາະແມ່ນຖືກກໍານົດໂດຍຕົວເລືອກປ້າຍ.

ຫມາຍເຫດ: ງົບປະມານ PDB ຖືກພິຈາລະນາພຽງແຕ່ເມື່ອການລະເມີດງົບປະມານສາມາດປີ້ນກັບກັນໄດ້ (ການຂັດຂວາງການສະຫມັກໃຈ). ໃນສະຖານະການເຊັ່ນຮາດແວລົ້ມເຫລວ, PDB ຈະບໍ່ເຮັດວຽກ.

ຕົວຢ່າງ PDB:

apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
  name: app-a-pdb
spec:
  minAvailable: 2
  selector:
      matchLabels:
        app: app-a

ສອງຕົວກໍານົດການຕົ້ນຕໍແມ່ນ matchLabels и minAvailable. ພາລາມິເຕີທໍາອິດກໍານົດວ່າຄໍາຮ້ອງສະຫມັກງົບປະມານໃດໃຊ້ກັບ. ຕົວຢ່າງ, ຖ້າຂ້ອຍມີການຕິດຕັ້ງທີ່ມີປ້າຍຊື່ app: app-a и app: app-b, ຫຼັງຈາກນັ້ນ PDB ນີ້ຈະໃຊ້ກັບຕົວທໍາອິດເທົ່ານັ້ນ.

Parameter minAvailable ຄໍານຶງເຖິງໃນເວລາທີ່ emptying (ທໍາຄວາມສະອາດ) node ໄດ້. ຕົວຢ່າງ, ໃນຕົວຢ່າງຂອງພວກເຮົາ, ໃນລະຫວ່າງການເປົ່າຫວ່າງ, ຕົວຢ່າງທັງຫມົດຖືກຂັບໄລ່ app: app-a, ຍົກເວັ້ນສອງ.

ນີ້ອະນຸຍາດໃຫ້ທ່ານສາມາດຄວບຄຸມຈໍານວນຕົວຢ່າງຂອງຄໍາຮ້ອງສະຫມັກຄວນຈະຖືກແລ່ນໃນເວລາໃດຫນຶ່ງ.

ຄໍາຮ້ອງສະຫມັກການຕິດຕາມສຸຂະພາບ

ການກວດສອບດັ່ງກ່າວແມ່ນເປັນໄປໄດ້ໃນສອງວິທີ: ການນໍາໃຊ້ການທົດສອບຄວາມພ້ອມຫຼືຊີວິດ.

ການສືບສວນຄັ້ງທໍາອິດ (ຄວາມພ້ອມ) ກໍານົດຄວາມພ້ອມຂອງຖັງທີ່ຈະຮັບການຈະລາຈອນ.

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

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

ປ້າຍກຳກັບຢູ່ທົ່ວທຸກແຫ່ງ

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

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

ໃຫ້ເວົ້າວ່າທ່ານໃຊ້ກຸ່ມດຽວກັນສໍາລັບ dev и qa. ນີ້ຫມາຍຄວາມວ່າທ່ານສາມາດມີຄໍາຮ້ອງສະຫມັກ app-a, ເຮັດວຽກພ້ອມກັນໃນສະພາບແວດລ້ອມທັງສອງ qa и dev. ໃນກໍລະນີນີ້, ພວກເຮົາແຍກຕ່າງຫາກສາມາດເຂົ້າຫາຕົວຢ່າງຂອງແອັບພລິເຄຊັນໃນສະພາບແວດລ້ອມສະເພາະໃດຫນຶ່ງໂດຍການກໍານົດພາລາມິເຕີທີ່ເຫມາະສົມ environment. ຕົວຢ່າງ app: app-a и environment: dev ສໍາລັບສະພາບແວດລ້ອມຫນຶ່ງ, ແລະ app: app-a и environment: qa ສໍາລັບອັນທີສອງ.

ນີ້ອະນຸຍາດໃຫ້ທ່ານເຂົ້າເຖິງທັງສອງຕົວຢ່າງຂອງຄໍາຮ້ອງສະຫມັກ, ສໍາລັບການຍົກຕົວຢ່າງ, ດໍາເນີນການທົດສອບພ້ອມໆກັນ.

ຈັດລະບຽບ

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

ແນ່ນອນ, ການບໍລິການເດັກກໍາພ້າຫນຶ່ງຈະບໍ່ເຮັດໃຫ້ລະບົບຊ້າລົງ, ແລະ Kubernetes ຖືກອອກແບບມາເພື່ອຂະຫນາດຈາກພື້ນຖານ. ແຕ່ຖ້າຫາກວ່າແທນທີ່ຈະເປັນການບໍລິການຫນຶ່ງລ້ານປະກົດ, kubelet ເລີ່ມ choke.

ຖ້າ​ຫາກ​ວ່າ​ສໍາ​ລັບ​ເຫດ​ຜົນ​ບາງ​ຢ່າງ​ທີ່​ທ່ານ​ລຶບ​ການ​ນໍາ​ໃຊ້ (container​, ຮູບ​ພາບ​, ໃດ​ກໍ່​ຕາມ​)​, ພຽງ​ແຕ່​ເຮັດ​ໃຫ້​ແນ່​ໃຈວ່​າ​ການ​ເຮັດ​ຄວາມ​ສະ​ອາດ​ສໍາ​ເລັດ​ສົມ​ບູນ​.

ພົບກັບ Go

ພວກເຮົາໄດ້ບັນທຶກຄໍາແນະນໍາຕົ້ນຕໍສໍາລັບການສຸດທ້າຍ. ຮຽນຮູ້ພາສາການຂຽນໂປລແກລມ Go.

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

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

ການຮຽນຮູ້ພາສາການຂຽນໂປລແກລມ Go ແລະ mastering client-go ແມ່ນບາງທີຄໍາແນະນໍາທີ່ສໍາຄັນທີ່ສຸດທີ່ທ່ານສາມາດໃຫ້ກັບຜູ້ໃຊ້ Kubernetes ໃຫມ່.

ແປດ້ວຍການສະຫນັບສະຫນູນຂອງ Mail.ru Cloud Solutions

ມີຫຍັງອີກແດ່ທີ່ຈະອ່ານ:

1. ສາມລະດັບການຂະຫຍາຍອັດຕະໂນມັດໃນ Kubernetes ແລະວິທີການນໍາໃຊ້ພວກມັນຢ່າງມີປະສິດທິພາບ.
2. ໂນດພະນັກງານ Kubernetes: ຫຼາຍອັນນ້ອຍ ຫຼືອັນໃຫຍ່ໜ້ອຍໜຶ່ງ?
3. 25 ເຄື່ອງ​ມື​ທີ່​ເປັນ​ປະ​ໂຫຍດ​ສໍາ​ລັບ​ການ​ນໍາ​ໃຊ້​ແລະ​ການ​ຄຸ້ມ​ຄອງ Kubernetes​.

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