Kubernetes 1.16: ຈຸດເດັ່ນຂອງສິ່ງໃໝ່

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

ຂໍ້ມູນທີ່ໃຊ້ໃນການກະກຽມເອກະສານນີ້ແມ່ນເອົາມາຈາກ Kubernetes ປັບປຸງຕາຕະລາງການຕິດຕາມ, ການປ່ຽນແປງ -1.16 ແລະບັນຫາທີ່ກ່ຽວຂ້ອງ, ດຶງຄໍາຮ້ອງຂໍ, ແລະການສະເຫນີການປັບປຸງ Kubernetes (KEP). ດັ່ງນັ້ນ, ໄປ!..

ຂໍ້

ການປະດິດສ້າງທີ່ໂດດເດັ່ນຫຼາຍແທ້ໆ (ໃນສະຖານະເວີຊັນ alpha) ໄດ້ຖືກນຳສະເໜີຢູ່ຂ້າງຂອງກຸ່ມ K8s (Kubelet).

ປະການທໍາອິດ, ອັນທີ່ເອີ້ນວ່າ «ບັນຈຸ ephemeral» (ຕູ້ຄອນເທນເນີທີ່ຊົ່ວຊ້າ), ອອກແບບມາເພື່ອງ່າຍຂະບວນການດີບັກໃນຝັກ. ກົນໄກໃຫມ່ຊ່ວຍໃຫ້ທ່ານສາມາດເປີດຕົວຖັງພິເສດທີ່ເລີ່ມຕົ້ນໃນ namespace ຂອງຝັກທີ່ມີຢູ່ແລະດໍາລົງຊີວິດໃນເວລາສັ້ນໆ. ຈຸດ​ປະ​ສົງ​ຂອງ​ເຂົາ​ເຈົ້າ​ແມ່ນ​ເພື່ອ​ພົວ​ພັນ​ກັບ​ຝັກ​ແລະ​ພາ​ຊະ​ນະ​ອື່ນໆ​ເພື່ອ​ແກ້​ໄຂ​ບັນ​ຫາ​ໃດ​ຫນຶ່ງ​ແລະ debug​. ຄໍາສັ່ງໃຫມ່ໄດ້ຖືກປະຕິບັດສໍາລັບຄຸນສົມບັດນີ້ kubectl debug, ໂດຍເນື້ອແທ້ແລ້ວຄ້າຍຄືກັນກັບ kubectl exec: ພຽງແຕ່ແທນທີ່ຈະດໍາເນີນການຂະບວນການໃນ container (ເຊັ່ນໃນ exec) ມັນເປີດຕົວບັນຈຸຢູ່ໃນຝັກ. ຕົວຢ່າງ, ຄໍາສັ່ງນີ້ຈະເຊື່ອມຕໍ່ບັນຈຸໃຫມ່ກັບ pod:

kubectl debug -c debug-shell --image=debian target-pod -- bash

ລາຍລະອຽດກ່ຽວກັບການບັນຈຸ ephemeral (ແລະຕົວຢ່າງຂອງການນໍາໃຊ້ຂອງເຂົາເຈົ້າ) ສາມາດໄດ້ຮັບການພົບເຫັນຢູ່ໃນ KEP ທີ່​ສອດ​ຄ້ອງ​ກັນ​. ການປະຕິບັດໃນປະຈຸບັນ (ໃນ K8s 1.16) ແມ່ນສະບັບ alpha, ແລະໃນບັນດາເງື່ອນໄຂສໍາລັບການໂອນມັນໄປສູ່ສະບັບເບຕ້າແມ່ນ "ການທົດສອບ Ephemeral Containers API ສໍາລັບຢ່າງຫນ້ອຍ 2 ການປ່ອຍ [Kubernetes]."

NB: ໂດຍເນື້ອແທ້ແລ້ວ ແລະເຖິງແມ່ນຊື່ຂອງມັນ, ຄຸນສົມບັດຄ້າຍຄືກັບ plugin ທີ່ມີຢູ່ແລ້ວ kubectl-debugກ່ຽວກັບການທີ່ພວກເຮົາ ຂຽນແລ້ວ. ຄາດວ່າດ້ວຍການມາເຖິງຂອງບັນຈຸ ephemeral, ການພັດທະນາຂອງ plugin ພາຍນອກແຍກຕ່າງຫາກຈະຢຸດເຊົາ.

ນະ​ວັດ​ຕະ​ກໍາ​ອີກ​ປະ​ການ​ຫນຶ່ງ - PodOverhead - ຖືກ​ອອກ​ແບບ​ເພື່ອ​ສະ​ຫນອງ​ການ​ ກົນໄກການຄິດໄລ່ຄ່າໃຊ້ຈ່າຍສ່ວນເກີນສຳລັບຝັກ, ຊຶ່ງສາມາດແຕກຕ່າງກັນຢ່າງຫຼວງຫຼາຍຂຶ້ນກັບ runtime ທີ່ໃຊ້. ສໍາລັບຕົວຢ່າງ, ຜູ້ຂຽນ KEP ນີ້ ຜົນໄດ້ຮັບໃນ Kata Containers, ເຊິ່ງຮຽກຮ້ອງໃຫ້ມີການເຮັດວຽກຂອງ Guest kernel, kata agent, init system, ແລະອື່ນໆ. ໃນເວລາທີ່ overhead ກາຍເປັນຂະຫນາດໃຫຍ່, ມັນບໍ່ສາມາດຖືກລະເລີຍ, ຊຶ່ງຫມາຍຄວາມວ່າຕ້ອງມີວິທີທີ່ຈະພິຈາລະນາສໍາລັບໂຄຕ້າຕື່ມອີກ, ການວາງແຜນ, ແລະອື່ນໆ. ເພື່ອປະຕິບັດມັນຢູ່ໃນ PodSpec ເພີ່ມພາກສະຫນາມ Overhead *ResourceList (ປຽບທຽບກັບຂໍ້ມູນໃນ RuntimeClass, ຖ້າຫາກວ່າຫນຶ່ງຖືກນໍາໃຊ້).

ການປະດິດສ້າງທີ່ໂດດເດັ່ນອີກອັນຫນຶ່ງແມ່ນ ຜູ້ຈັດການ topology node (ຜູ້ຈັດການ Node Topology), ອອກແບບມາເພື່ອປະສົມປະສານວິທີການປັບປ່ຽນການຈັດສັນຊັບພະຍາກອນຮາດແວສໍາລັບອົງປະກອບຕ່າງໆໃນ Kubernetes. ການລິເລີ່ມນີ້ແມ່ນຍ້ອນຄວາມຕ້ອງການທີ່ເພີ່ມຂຶ້ນຂອງລະບົບທີ່ທັນສະໄຫມຕ່າງໆ (ຈາກພາກສະຫນາມຂອງໂທລະຄົມນາຄົມ, ການຮຽນຮູ້ເຄື່ອງຈັກ, ການບໍລິການທາງດ້ານການເງິນ, ແລະອື່ນໆ) ສໍາລັບຄອມພິວເຕີ້ຂະຫນານທີ່ມີປະສິດຕິພາບສູງແລະຫຼຸດຜ່ອນຄວາມລ່າຊ້າໃນການປະຕິບັດງານ, ເຊິ່ງພວກເຂົາໃຊ້ CPU ຂັ້ນສູງແລະ. ຄວາມສາມາດເລັ່ງຮາດແວ. ການເພີ່ມປະສິດທິພາບດັ່ງກ່າວໃນ Kubernetes ມາຮອດປະຈຸບັນແມ່ນບັນລຸໄດ້ຍ້ອນອົງປະກອບທີ່ບໍ່ຊ້ໍາກັນ (ຜູ້ຈັດການ CPU, ຜູ້ຈັດການອຸປະກອນ, CNI), ແລະໃນປັດຈຸບັນພວກເຂົາຈະຖືກເພີ່ມການໂຕ້ຕອບພາຍໃນດຽວທີ່ປະສົມປະສານວິທີການແລະງ່າຍດາຍການເຊື່ອມຕໍ່ຂອງຄ້າຍຄືກັນ - ອັນທີ່ເອີ້ນວ່າ topology- aware - ອົງປະກອບໃນດ້ານ Kubelet. ລາຍລະອຽດ - ໃນ KEP ທີ່​ສອດ​ຄ້ອງ​ກັນ​.

ແຜນວາດອົງປະກອບຂອງ Topology Manager

ຄຸນ​ນະ​ສົມ​ບັດ​ຕໍ່​ໄປ - ກວດເບິ່ງຕູ້ຄອນເທນເນີໃນຂະນະທີ່ພວກເຂົາກໍາລັງແລ່ນ (ການສືບສວນການເລີ່ມຕົ້ນ). ດັ່ງທີ່ທ່ານຮູ້, ສໍາລັບຕູ້ຄອນເທນເນີທີ່ໃຊ້ເວລາດົນໃນການເປີດຕົວ, ມັນເປັນການຍາກທີ່ຈະໄດ້ຮັບສະຖານະທີ່ທັນສະໄຫມ: ພວກມັນຖືກ "ຂ້າ" ກ່ອນທີ່ມັນຈະເລີ່ມເຮັດວຽກຕົວຈິງ, ຫຼືພວກເຂົາສິ້ນສຸດລົງໃນຄວາມຕາຍໃນເວລາດົນນານ. ການກວດສອບໃໝ່ (ເປີດໃຊ້ງານຜ່ານປະຕູຄຸນສົມບັດເອີ້ນວ່າ StartupProbeEnabled) ຍົກເລີກ - ຫຼືແທນທີ່ຈະ, defers - ຜົນກະທົບຂອງການກວດສອບອື່ນໆຈົນກ່ວາປັດຈຸບັນຝັກໄດ້ສໍາເລັດການດໍາເນີນການ. ສໍາລັບເຫດຜົນນີ້, ຄຸນນະສົມບັດໄດ້ຖືກເອີ້ນໃນເບື້ອງຕົ້ນ pod-startup liveness-probe holdoff. ສໍາລັບຝັກທີ່ໃຊ້ເວລາດົນເພື່ອເລີ່ມຕົ້ນ, ທ່ານສາມາດສໍາຫຼວດລັດໃນໄລຍະເວລາທີ່ຂ້ອນຂ້າງສັ້ນ.

ນອກຈາກນັ້ນ, ການປັບປຸງສໍາລັບ RuntimeClass ແມ່ນມີຢູ່ໃນສະຖານະເບຕ້າທັນທີ, ເພີ່ມການສະຫນັບສະຫນູນສໍາລັບ "ກຸ່ມທີ່ແຕກຕ່າງກັນ". ຄ ການຈັດຕາຕະລາງ RuntimeClass ໃນປັດຈຸບັນມັນບໍ່ຈໍາເປັນສໍາລັບແຕ່ລະ node ທີ່ຈະສະຫນັບສະຫນູນແຕ່ລະ RuntimeClass: ສໍາລັບ pods ທ່ານສາມາດເລືອກ RuntimeClass ໂດຍບໍ່ຕ້ອງຄິດກ່ຽວກັບ topology ຂອງກຸ່ມ. ກ່ອນຫນ້ານີ້, ເພື່ອບັນລຸເປົ້າຫມາຍນີ້ - ດັ່ງນັ້ນ pods ສິ້ນສຸດລົງໃນ nodes ສະຫນັບສະຫນູນສໍາລັບທຸກສິ່ງທີ່ເຂົາເຈົ້າຕ້ອງການ - ມັນຈໍາເປັນຕ້ອງໄດ້ກໍານົດກົດລະບຽບທີ່ເຫມາະສົມກັບ NodeSelector ແລະຄວາມທົນທານ. IN ເຄສ ມັນເວົ້າກ່ຽວກັບຕົວຢ່າງຂອງການນໍາໃຊ້ແລະ, ແນ່ນອນ, ລາຍລະອຽດການປະຕິບັດ.

ເຄືອຂ່າຍ

ລັກສະນະເຄືອຂ່າຍທີ່ສໍາຄັນສອງຢ່າງທີ່ປາກົດເປັນຄັ້ງທໍາອິດ (ໃນເວີຊັ່ນ alpha) ໃນ Kubernetes 1.16 ແມ່ນ:

• ສະຫນັບສະຫນູນ stack ເຄືອຂ່າຍຄູ່ - IPv4/IPv6 - ແລະ "ຄວາມເຂົ້າໃຈ" ທີ່ສອດຄ້ອງກັນໃນລະດັບຂອງຝັກ, ຂໍ້, ການບໍລິການ. ມັນປະກອບມີການຕິດຕໍ່ພົວພັນ IPv4-to-IPv4 ແລະ IPv6-to-IPv6 ລະຫວ່າງຝັກ, ຈາກພອດກັບການບໍລິການພາຍນອກ, ການປະຕິບັດການອ້າງອີງ (ພາຍໃນ Bridge CNI, PTP CNI ແລະ plugins Host-Local IPAM), ເຊັ່ນດຽວກັນກັບການປີ້ນກັບກັນກັບກຸ່ມ Kubernetes ທີ່ເຮັດວຽກຢູ່. IPv4 ຫຼື IPv6 ເທົ່ານັ້ນ. ລາຍລະອຽດການຈັດຕັ້ງປະຕິບັດແມ່ນຢູ່ໃນ ເຄສ.

  ຕົວຢ່າງຂອງການສະແດງທີ່ຢູ່ IP ຂອງສອງປະເພດ (IPv4 ແລະ IPv6) ໃນບັນຊີລາຍຊື່ຂອງຝັກ:

  kube-master# kubectl get pods -o wide
  NAME               READY     STATUS    RESTARTS   AGE       IP                          NODE
  nginx-controller   1/1       Running   0          20m       fd00:db8:1::2,192.168.1.3   kube-minion-1
  kube-master#

• API ໃຫມ່ສໍາລັບ Endpoint - EndpointSlice API. ມັນແກ້ໄຂບັນຫາການປະຕິບັດ / ຂະຫນາດຂອງ Endpoint API ທີ່ມີຢູ່ແລ້ວທີ່ມີຜົນກະທົບຕໍ່ອົງປະກອບຕ່າງໆໃນຍົນຄວບຄຸມ (apiserver, etcd, endpoints-controller, kube-proxy). API ໃຫມ່ຈະຖືກເພີ່ມເຂົ້າໄປໃນກຸ່ມ Discovery API ແລະຈະສາມາດໃຫ້ບໍລິການຫລາຍສິບພັນຈຸດສິ້ນສຸດຂອງ backend ໃນແຕ່ລະບໍລິການໃນກຸ່ມທີ່ປະກອບດ້ວຍຫລາຍພັນໂຫນດ. ເພື່ອ​ເຮັດ​ສິ່ງ​ນີ້, ແຕ່​ລະ​ການ​ບໍ​ລິ​ການ​ແມ່ນ​ໄດ້​ສ້າງ​ແຜນ​ທີ່​ກັບ N ວັດ​ຖຸ​ EndpointSlice, ແຕ່ລະອັນໂດຍຄ່າເລີ່ມຕົ້ນມີຈຸດສິ້ນສຸດບໍ່ເກີນ 100 ຈຸດ (ຄ່າສາມາດຕັ້ງຄ່າໄດ້). EndpointSlice API ຍັງຈະສະຫນອງໂອກາດສໍາລັບການພັດທະນາໃນອະນາຄົດຂອງຕົນ: ສະຫນັບສະຫນູນສໍາລັບທີ່ຢູ່ IP ຫຼາຍສໍາລັບແຕ່ລະ pod, ລັດໃຫມ່ສໍາລັບ endpoints (ບໍ່ພຽງແຕ່. Ready и NotReady), ການຕັ້ງຄ່າຍ່ອຍແບບເຄື່ອນໄຫວສໍາລັບຈຸດສິ້ນສຸດ.

ອັນທີ່ນຳສະເໜີໃນລຸ້ນຫຼ້າສຸດໄດ້ຮອດລຸ້ນເບຕ້າແລ້ວ ຮອບສຸດທ້າຍ, ຊື່ service.kubernetes.io/load-balancer-cleanup ແລະຕິດກັບແຕ່ລະບໍລິການທີ່ມີປະເພດ LoadBalancer. ໃນເວລາທີ່ການລຶບການບໍລິການດັ່ງກ່າວ, ມັນປ້ອງກັນການລຶບຊັບພະຍາກອນທີ່ແທ້ຈິງຈົນກ່ວາ "ການເຮັດຄວາມສະອາດ" ຂອງຊັບພະຍາກອນທີ່ສົມດຸນທີ່ກ່ຽວຂ້ອງທັງຫມົດສໍາເລັດ.

ເຄື່ອງຈັກ API

"ເຫດການສະຖຽນລະພາບ" ທີ່ແທ້ຈິງແມ່ນຢູ່ໃນພື້ນທີ່ຂອງເຄື່ອງແມ່ຂ່າຍ Kubernetes API ແລະການພົວພັນກັບມັນ. ນີ້ເກີດຂຶ້ນໂດຍສ່ວນໃຫຍ່ຂໍຂອບໃຈກັບ ການໂອນໄປສູ່ສະຖານະພາບທີ່ຫມັ້ນຄົງຜູ້ທີ່ບໍ່ຕ້ອງການການແນະນໍາພິເສດ CustomResourceDefinitions (CRD), ເຊິ່ງມີສະຖານະເບຕ້າຕັ້ງແຕ່ມື້ທີ່ຫ່າງໄກຂອງ Kubernetes 1.7 (ແລະນີ້ແມ່ນເດືອນມິຖຸນາ 2017!). ສະຖຽນລະພາບດຽວກັນມາກັບລັກສະນະທີ່ກ່ຽວຂ້ອງ:

• "ຊັບພະຍາກອນຍ່ອຍ" ຈາກ /status и /scale ສໍາລັບ CustomResources;
• ປ່ຽນໃຈເຫລື້ອມໃສ ຮຸ່ນສໍາລັບ CRD, ອີງໃສ່ webhook ພາຍນອກ;
• ນຳສະເໜີເມື່ອບໍ່ດົນມານີ້ (ໃນ K8s 1.15) ຄ່າເລີ່ມຕົ້ນ (ຄ່າເລີ່ມຕົ້ນ) ແລະການໂຍກຍ້າຍອັດຕະໂນມັດພາກສະຫນາມ (ການຕັດແຕ່ງ) ສໍາລັບ CustomResources;
• ໂອກາດ ໂດຍໃຊ້ OpenAPI v3 schema ເພື່ອສ້າງ ແລະເຜີຍແຜ່ເອກະສານ OpenAPI ທີ່ໃຊ້ເພື່ອກວດສອບຊັບພະຍາກອນ CRD ຢູ່ຂ້າງເຊີບເວີ.

ກົນໄກອື່ນທີ່ຄຸ້ນເຄີຍກັບຜູ້ບໍລິຫານ Kubernetes ມາເປັນເວລາດົນນານແລ້ວ: webhook ເຂົ້າ - ຍັງຢູ່ໃນສະຖານະເບຕ້າເປັນເວລາດົນນານ (ຕັ້ງແຕ່ K8s 1.9) ແລະຕອນນີ້ໄດ້ຖືກປະກາດວ່າມີຄວາມໝັ້ນຄົງແລ້ວ.

ຄຸນສົມບັດອີກສອງອັນໄດ້ຮອດເບຕ້າແລ້ວ: ດ້ານເຊີບເວີນຳໃຊ້ и ເບິ່ງ bookmarks.

ແລະການປະດິດສ້າງທີ່ສໍາຄັນພຽງແຕ່ໃນສະບັບ alpha ແມ່ນ ຄວາມລົ້ມເຫຼວ ຈາກ SelfLink — URI ພິເສດທີ່ເປັນຕົວແທນຂອງວັດຖຸທີ່ລະບຸໄວ້ ແລະເປັນສ່ວນຫນຶ່ງຂອງ ObjectMeta и ListMeta (ເຊັ່ນ: ສ່ວນຫນຶ່ງຂອງວັດຖຸໃດນຶ່ງໃນ Kubernetes). ເປັນຫຍັງເຂົາເຈົ້າຈຶ່ງປະຖິ້ມມັນ? ການກະຕຸ້ນດ້ວຍວິທີງ່າຍໆ ສຽງ ຍ້ອນວ່າບໍ່ມີເຫດຜົນທີ່ແທ້ຈິງ (ທີ່ລົ້ນເຫຼືອ) ສໍາລັບພາກສະຫນາມນີ້ຍັງຄົງມີຢູ່. ເຫດຜົນຢ່າງເປັນທາງການເພີ່ມເຕີມແມ່ນເພື່ອເພີ່ມປະສິດທິພາບການປະຕິບັດ (ໂດຍການຖອນພາກສະຫນາມທີ່ບໍ່ຈໍາເປັນ) ແລະເພື່ອເຮັດໃຫ້ການເຮັດວຽກຂອງ generic-apiserver ງ່າຍດາຍ, ເຊິ່ງຖືກບັງຄັບໃຫ້ຈັດການພາກສະຫນາມດັ່ງກ່າວໃນລັກສະນະພິເສດ (ນີ້ແມ່ນພາກສະຫນາມດຽວທີ່ຖືກກໍານົດໄວ້ກ່ອນວັດຖຸ. ແມ່ນ serialized). ຄວາມລ້າສະໄໝແທ້ (ພາຍໃນເບຕ້າ) SelfLink ຈະເກີດຂຶ້ນໂດຍ Kubernetes ຮຸ່ນ 1.20, ແລະສຸດທ້າຍ - 1.21.

ການເກັບຂໍ້ມູນ

ວຽກງານຕົ້ນຕໍໃນພື້ນທີ່ເກັບຮັກສາ, ເຊັ່ນດຽວກັນກັບການປ່ອຍອອກມາກ່ອນຫນ້ານີ້, ແມ່ນສັງເກດເຫັນຢູ່ໃນພື້ນທີ່ ສະຫນັບສະຫນູນ CSI. ການປ່ຽນແປງຕົ້ນຕໍຢູ່ທີ່ນີ້ແມ່ນ:

• ເປັນ​ຄັ້ງ​ທໍາ​ອິດ (ໃນ​ສະ​ບັບ alpha​) ປາກົດວ່າ ສະຫນັບສະຫນູນ plugin CSI ສໍາລັບ Windows worker nodes: ວິທີການເຮັດວຽກກັບບ່ອນເກັບຂໍ້ມູນໃນປັດຈຸບັນຍັງຈະປ່ຽນແທນ plugins in-tree ໃນຫຼັກ Kubernetes ແລະ plugins FlexVolume ຈາກ Microsoft ໂດຍອີງໃສ່ Powershell;

  
  ຮູບແບບການຈັດຕັ້ງປະຕິບັດ plugins CSI ໃນ Kubernetes ສໍາລັບ Windows

• ໂອກາດ ປັບຂະໜາດປະລິມານ CSI, ນໍາສະເຫນີກັບຄືນໄປບ່ອນໃນ K8s 1.12, ໄດ້ເຕີບໂຕເປັນສະບັບເບຕ້າ;
• "ການສົ່ງເສີມ" ທີ່ຄ້າຍຄືກັນ (ຈາກອັນຟາຫາເບຕ້າ) ແມ່ນບັນລຸໄດ້ໂດຍຄວາມສາມາດໃນການໃຊ້ CSI ເພື່ອສ້າງປະລິມານ ephemeral ທ້ອງຖິ່ນ (ຮອງຮັບປະລິມານໃນແຖວ CSI).

ແນະນຳໃນ Kubernetes ລຸ້ນກ່ອນ ຟັງຊັນ cloning ປະລິມານ (ໃຊ້ PVC ທີ່ມີຢູ່ແລ້ວເປັນ DataSource ເພື່ອສ້າງ PVC ໃໝ່) ດຽວນີ້ຍັງໄດ້ຮັບສະຖານະພາບເບຕ້າ.

ຜູ້ຈັດຕາຕະລາງ

ການປ່ຽນແປງທີ່ໂດດເດັ່ນສອງອັນຕໍ່ກັບການກຳນົດເວລາ (ທັງໃນອັນຟາ):

• EvenPodsSpreading - ໂອກາດ ໃຊ້ pods ແທນທີ່ຈະເປັນຫນ່ວຍງານຄໍາຮ້ອງສະຫມັກທີ່ມີເຫດຜົນສໍາລັບ "ການແຈກຢາຍຢ່າງຍຸດຕິທໍາ" ຂອງການໂຫຼດ (ເຊັ່ນ: Deployment and ReplicaSet) ແລະປັບການແຈກຢາຍນີ້ (ຕາມຄວາມຕ້ອງການຍາກ ຫຼືເປັນເງື່ອນໄຂອ່ອນໆ, i.e. ບູລິມະສິດ). ຄຸນນະສົມບັດຈະຂະຫຍາຍຄວາມສາມາດໃນການແຈກຢາຍທີ່ມີຢູ່ແລ້ວຂອງຝັກທີ່ວາງແຜນໄວ້, ປະຈຸບັນຈໍາກັດໂດຍທາງເລືອກ PodAffinity и PodAntiAffinity, ໃຫ້ຜູ້ບໍລິຫານຄວບຄຸມລະອຽດໃນເລື່ອງນີ້, ຊຶ່ງຫມາຍຄວາມວ່າການມີທີ່ດີຂຶ້ນແລະການບໍລິໂພກຊັບພະຍາກອນທີ່ເຫມາະສົມ. ລາຍລະອຽດ - ໃນ ເຄສ.
• ການນໍາໃຊ້ ນະໂຍບາຍທີ່ດີທີ່ສຸດ в RequestedToCapacityRatio ຟັງຊັນບູລິມະສິດ ໃນລະຫວ່າງການວາງແຜນຝັກ, ເຊິ່ງຈະອະນຸຍາດໃຫ້ ການນໍາໃຊ້ ຖັງບັນຈຸ ("ການຫຸ້ມຫໍ່ໃນຖັງ") ສໍາລັບຊັບພະຍາກອນພື້ນຖານ (ໂປເຊດເຊີ, ຫນ່ວຍຄວາມຈໍາ) ແລະອຸປະກອນຂະຫຍາຍ (ເຊັ່ນ GPU). ສໍາລັບລາຍລະອຽດເພີ່ມເຕີມ, ເບິ່ງ ເຄສ.

  
  ການຈັດຕາຕະລາງເວລາ: ກ່ອນທີ່ຈະໃຊ້ນະໂຍບາຍທີ່ເຫມາະສົມທີ່ສຸດ (ໂດຍກົງຜ່ານຕົວກໍານົດເວລາເລີ່ມຕົ້ນ) ແລະການນໍາໃຊ້ຂອງມັນ (ຜ່ານຕົວຂະຫຍາຍຕາຕະລາງ)

ຍິ່ງ​ໄປ​ກວ່າ​ນັ້ນ​, ນຳ ສະ ເໜີ ຄວາມສາມາດໃນການສ້າງ plugins ກໍານົດເວລາຂອງທ່ານເອງຢູ່ນອກຕົ້ນໄມ້ພັດທະນາ Kubernetes ຕົ້ນຕໍ (ອອກຈາກຕົ້ນໄມ້).

ການປ່ຽນແປງອື່ນ

ນອກຈາກນີ້ໃນການປ່ອຍ Kubernetes 1.16 ມັນສາມາດສັງເກດເຫັນໄດ້ ການລິເລີ່ມສໍາລັບ ນໍາເອົາ metrics ທີ່ມີຢູ່ໃນຄໍາສັ່ງເຕັມ, ຫຼືຫຼາຍກວ່າທີ່ຊັດເຈນ, ສອດຄ່ອງກັບ ລະ​ບຽບ​ການ​ຢ່າງ​ເປັນ​ທາງ​ການ​ ກັບເຄື່ອງມື K8s. ພວກເຂົາເຈົ້າສ່ວນໃຫຍ່ແມ່ນອີງໃສ່ການທີ່ສອດຄ້ອງກັນ ເອກະສານ Prometheus. ຄວາມບໍ່ສອດຄ່ອງເກີດຂື້ນຍ້ອນເຫດຜົນຕ່າງໆ (ຕົວຢ່າງ, ບາງຕົວຊີ້ບອກພຽງແຕ່ຖືກສ້າງຂື້ນກ່ອນທີ່ຄໍາແນະນໍາໃນປະຈຸບັນຈະປາກົດ), ແລະຜູ້ພັດທະນາໄດ້ຕັດສິນໃຈວ່າມັນເຖິງເວລາທີ່ຈະນໍາທຸກສິ່ງທຸກຢ່າງໄປສູ່ມາດຕະຖານດຽວ, "ສອດຄ່ອງກັບລະບົບນິເວດ Prometheus ສ່ວນທີ່ເຫຼືອ." ການຈັດຕັ້ງປະຕິບັດຂໍ້ລິເລີ່ມນີ້ໃນປັດຈຸບັນຢູ່ໃນສະຖານະອັນຟາ, ເຊິ່ງຈະຖືກສົ່ງເສີມຢ່າງເປັນກ້າວໆໃນ Kubernetes ລຸ້ນຕໍ່ໄປເປັນເບຕ້າ (1.17) ແລະໝັ້ນຄົງ (1.18).

ນອກຈາກນັ້ນ, ການປ່ຽນແປງຕໍ່ໄປນີ້ສາມາດສັງເກດໄດ້:

• Windows ສະຫນັບສະຫນູນການພັດທະນາ с ຮູບລັກສະນະ Utilities Kubeadm ສໍາລັບ OS ນີ້ (ເວີຊັ່ນອັນຟາ), ໂອກາດ RunAsUserName ສໍາ​ລັບ Windows containers (ເວີ​ຊັນ​ອັນ​ຟາ​)​, ການປັບປຸງ Group Managed Service Account (gMSA) ຮອງຮັບເຖິງເວີຊັນເບຕ້າ, ສະຫນັບສະຫນູນ mount/attach ສໍາລັບປະລິມານ vSphere.
• ລີໄຊເຄີນ ກົນໄກການບີບອັດຂໍ້ມູນໃນການຕອບສະໜອງ API. ກ່ອນຫນ້ານີ້, ຕົວກອງ HTTP ໄດ້ຖືກນໍາໃຊ້ເພື່ອຈຸດປະສົງເຫຼົ່ານີ້, ເຊິ່ງກໍານົດຂໍ້ຈໍາກັດຈໍານວນຫນຶ່ງທີ່ປ້ອງກັນບໍ່ໃຫ້ມັນຖືກເປີດໃຊ້ໂດຍຄ່າເລີ່ມຕົ້ນ. "ການບີບອັດການຮ້ອງຂໍໂປ່ງໃສ" ໃນປັດຈຸບັນເຮັດວຽກ: ລູກຄ້າສົ່ງ Accept-Encoding: gzip ໃນສ່ວນຫົວ, ພວກເຂົາໄດ້ຮັບການຕອບຮັບທີ່ບີບອັດ GZIP ຖ້າຂະຫນາດຂອງມັນເກີນ 128 KB. ລູກຄ້າ Go ສະຫນັບສະຫນູນການບີບອັດອັດຕະໂນມັດ (ສົ່ງສ່ວນຫົວທີ່ຕ້ອງການ), ດັ່ງນັ້ນພວກເຂົາຈະສັງເກດເຫັນການຫຼຸດຜ່ອນການຈະລາຈອນທັນທີ. (ການ​ດັດ​ແກ້​ເລັກ​ນ້ອຍ​ອາດ​ຈະ​ຈໍາ​ເປັນ​ສໍາ​ລັບ​ພາ​ສາ​ອື່ນ​.)
• ກາຍເປັນຄວາມເປັນໄປໄດ້ ການຂະຫຍາຍ HPA ຈາກ/ຫາສູນຝັກ ໂດຍອີງຕາມການວັດແທກພາຍນອກ. ຖ້າ​ຫາກ​ວ່າ​ທ່ານ​ຂະ​ຫນາດ​ໂດຍ​ອີງ​ໃສ່​ວັດ​ຖຸ / ການ​ວັດ​ແທກ​ພາຍ​ນອກ​, ຫຼັງ​ຈາກ​ນັ້ນ​, ໃນ​ເວ​ລາ​ທີ່​ການ​ເຮັດ​ວຽກ​ບໍ່​ໄດ້​ເຮັດ​ວຽກ​, ທ່ານ​ສາ​ມາດ​ປັບ​ຂະ​ຫນາດ​ອັດ​ຕະ​ໂນ​ມັດ​ເປັນ 0 replicas ເພື່ອ​ປະ​ຢັດ​ຊັບ​ພະ​ຍາ​ກອນ​. ຄຸນນະສົມບັດນີ້ຄວນຈະເປັນປະໂຫຍດໂດຍສະເພາະສໍາລັບກໍລະນີທີ່ຄົນງານຮ້ອງຂໍຊັບພະຍາກອນ GPU, ແລະຈໍານວນຂອງປະເພດທີ່ແຕກຕ່າງກັນຂອງພະນັກງານບໍ່ເຮັດວຽກເກີນຈໍານວນ GPU ທີ່ມີຢູ່.
• ລູກ​ຄ້າ​ໃຫມ່ - k8s.io/client-go/metadata.Client — ສໍາ​ລັບ​ການ "ທົ່ວ​ໄປ​" ການ​ເຂົ້າ​ເຖິງ​ວັດ​ຖຸ​. ມັນໄດ້ຖືກອອກແບບເພື່ອດຶງຂໍ້ມູນ metadata ໄດ້ຢ່າງງ່າຍດາຍ (ເຊັ່ນ: ພາກສ່ວນຍ່ອຍ metadata) ຈາກຊັບພະຍາກອນຂອງກຸ່ມແລະປະຕິບັດການເກັບຂີ້ເຫຍື້ອແລະການດໍາເນີນງານໂຄຕ້າກັບພວກເຂົາ.
• ສ້າງ Kubernetes ໃນປັດຈຸບັນທ່ານສາມາດເຮັດໄດ້ ໂດຍບໍ່ມີມໍລະດົກ ("ໃນຕົວ" ຢູ່ໃນຕົ້ນໄມ້) ຜູ້ໃຫ້ບໍລິການຄລາວ (ເວີຊັນອັນຟາ).
• ກັບຜົນປະໂຫຍດ kubeadm ເພີ່ມ ຄວາມສາມາດໃນການທົດລອງ (ອັນຟາ) ເພື່ອນຳໃຊ້ການປັບແຕ່ງ patches ໃນລະຫວ່າງການປະຕິບັດງານ init, join и upgrade. ຮຽນຮູ້ເພີ່ມເຕີມກ່ຽວກັບວິທີການນໍາໃຊ້ທຸງ --experimental-kustomize, ເບິ່ງໃນ ເຄສ.
• ຈຸດສິ້ນສຸດໃຫມ່ສໍາລັບ apiserver - readyz, - ອະນຸຍາດໃຫ້ທ່ານສາມາດສົ່ງອອກຂໍ້ມູນກ່ຽວກັບຄວາມພ້ອມຂອງມັນ. ຕອນນີ້ເຊີບເວີ API ຍັງມີທຸງ --maximum-startup-sequence-duration, ຊ່ວຍໃຫ້ທ່ານສາມາດຄວບຄຸມການເລີ່ມຕົ້ນໃຫມ່ຂອງມັນ.
• ສອງ ຄຸນນະສົມບັດສໍາລັບ Azure ປະກາດຄວາມຫມັ້ນຄົງ: ສະຫນັບສະຫນູນ ເຂດທີ່ມີໃຫ້ (ເຂດທີ່ມີໃຫ້) ແລະ ກຸ່ມຊັບພະຍາກອນຂ້າມ (RG). ນອກຈາກນັ້ນ, Azure ຍັງໄດ້ເພີ່ມ:
  • ສະຫນັບສະຫນູນການຢັ້ງຢືນ AAD ແລະ ADFS;
  • ຄໍາບັນຍາຍ service.beta.kubernetes.io/azure-pip-name ເພື່ອລະບຸ IP ສາທາລະນະຂອງຕົວດຸ່ນດ່ຽງການໂຫຼດ;
  • ໂອກາດ settings LoadBalancerName и LoadBalancerResourceGroup.
• ດຽວນີ້ AWS ມີ ສະຫນັບສະຫນູນ ສໍາລັບ EBS ໃນ Windows ແລະ ປັບໃຫ້ເໝາະສົມ EC2 API ໂທ DescribeInstances.
• Kubeadm ໃນປັດຈຸບັນເປັນເອກະລາດ ເຄື່ອນຍ້າຍ ການຕັ້ງຄ່າ CoreDNS ເມື່ອອັບເກຣດເວີຊັນ CoreDNS.
• ຄູ່ ແລະອື່ນ ໃນຮູບພາບ Docker ທີ່ສອດຄ້ອງກັນ ເຮັດ world-executable, ເຊິ່ງອະນຸຍາດໃຫ້ທ່ານສາມາດດໍາເນີນການຮູບພາບນີ້ໂດຍບໍ່ຈໍາເປັນຕ້ອງມີສິດທິຂອງຮາກ. ນອກຈາກນີ້, etcd ຮູບພາບການເຄື່ອນຍ້າຍ ຢຸດ ສະຫນັບສະຫນູນສະບັບ etcd2.
• В Cluster Autoscaler 1.16.0 ປ່ຽນໄປໃຊ້ distroless ເປັນຮູບພາບພື້ນຖານ, ປັບປຸງປະສິດທິພາບ, ເພີ່ມຜູ້ໃຫ້ບໍລິການຟັງໃຫມ່ (DigitalOcean, Magnum, Packet).
• ອັບເດດໃນຊອບແວທີ່ໃຊ້ແລ້ວ/ຂຶ້ນກັບ: Go 1.12.9, etcd 3.3.15, CoreDNS 1.6.2.

PS

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

• «Kubernetes 1.15: ຈຸດເດັ່ນຂອງສິ່ງໃໝ່"
• «Kubernetes 1.14: ຈຸດເດັ່ນຂອງສິ່ງໃໝ່"
• «Kubernetes 1.13: ຈຸດເດັ່ນຂອງສິ່ງໃໝ່"
• «Kubernetes 1.12: ຈຸດເດັ່ນຂອງສິ່ງໃໝ່".

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