Kubernetes 1.16: ภาพรวมของนวัตกรรมหลัก

วันนี้ วันพุธ จะเกิดขึ้น Kubernetes รุ่นถัดไป - 1.16. ตามประเพณีที่พัฒนาขึ้นสำหรับบล็อกของเรา นี่เป็นวันครบรอบปีที่ XNUMX ที่เรากำลังพูดถึงการเปลี่ยนแปลงที่สำคัญที่สุดในเวอร์ชันใหม่

ข้อมูลที่ใช้ในการเตรียมเอกสารนี้นำมาจาก ตารางการติดตามการปรับปรุง Kubernetes, บันทึกการเปลี่ยนแปลง-1.16 และปัญหาที่เกี่ยวข้อง คำขอดึง และข้อเสนอการปรับปรุง Kubernetes (KEP) งั้นไปกัน!..

โหนด

นวัตกรรมที่โดดเด่นจำนวนมาก (ในสถานะเวอร์ชันอัลฟ่า) จะถูกนำเสนอที่ด้านข้างของโหนดคลัสเตอร์ K8s (Kubelet)

ประการแรกสิ่งที่เรียกว่า «ภาชนะชั่วคราว» (คอนเทนเนอร์ชั่วคราว)ออกแบบมาเพื่อลดความซับซ้อนของกระบวนการแก้ไขจุดบกพร่องในพ็อด. กลไกใหม่นี้ช่วยให้คุณเปิดตัวคอนเทนเนอร์พิเศษที่เริ่มต้นในเนมสเปซของพ็อดที่มีอยู่และใช้งานได้ในช่วงเวลาสั้นๆ จุดประสงค์คือการโต้ตอบกับพ็อดและคอนเทนเนอร์อื่นเพื่อแก้ไขปัญหาและแก้ไขข้อบกพร่อง มีการนำคำสั่งใหม่สำหรับคุณสมบัตินี้ไปใช้ kubectl debugคล้ายกันในสาระสำคัญกับ kubectl exec: แทนที่จะรันกระบวนการในคอนเทนเนอร์เท่านั้น (เช่นใน exec) จะเปิดตัวคอนเทนเนอร์ในพ็อด ตัวอย่างเช่น คำสั่งนี้จะเชื่อมต่อคอนเทนเนอร์ใหม่เข้ากับพ็อด:

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

ดูรายละเอียดเกี่ยวกับคอนเทนเนอร์ชั่วคราว (และตัวอย่างการใช้งาน) ได้ใน KEP ที่เกี่ยวข้อง. การใช้งานปัจจุบัน (ใน K8s 1.16) เป็นเวอร์ชันอัลฟ่า และหนึ่งในเกณฑ์สำหรับการโอนย้ายไปยังเวอร์ชันเบต้าคือ “การทดสอบ Ephemeral Containers API สำหรับ [Kubernetes] อย่างน้อย 2 รุ่น”

NB: โดยสาระสำคัญและแม้แต่ชื่อ คุณลักษณะนี้คล้ายกับปลั๊กอินที่มีอยู่แล้ว kubectl-debugเกี่ยวกับที่เรา เขียนแล้ว. เป็นที่คาดว่าเมื่อมีการถือกำเนิดของคอนเทนเนอร์ชั่วคราว การพัฒนาปลั๊กอินภายนอกที่แยกจากกันจะหยุดลง

อีกหนึ่งนวัตกรรม - PodOverhead - ออกแบบมาเพื่อให้ กลไกในการคำนวณต้นทุนค่าโสหุ้ยสำหรับพ็อดซึ่งอาจแตกต่างกันอย่างมากขึ้นอยู่กับรันไทม์ที่ใช้ ยกตัวอย่างผู้เขียน KEP นี้ ส่งผลให้เกิด Kata Containers ซึ่งต้องใช้เคอร์เนลของแขก, kata agent, ระบบ init ฯลฯ เมื่อค่าใช้จ่ายมีขนาดใหญ่มาก ก็ไม่สามารถละเลยได้ ซึ่งหมายความว่าจำเป็นต้องมีวิธีในการพิจารณาโควต้า การวางแผน ฯลฯ เพิ่มเติม เพื่อนำไปปฏิบัติใน PodSpec เพิ่มฟิลด์แล้ว Overhead *ResourceList (เปรียบเทียบกับข้อมูลใน RuntimeClassถ้ามีการใช้งาน)

นวัตกรรมที่โดดเด่นอีกอย่างหนึ่งก็คือ ตัวจัดการโทโพโลยีโหนด (ผู้จัดการโทโพโลยีโหนด)ออกแบบมาเพื่อรวมแนวทางการปรับแต่งการจัดสรรทรัพยากรฮาร์ดแวร์สำหรับส่วนประกอบต่างๆ ใน ​​Kubernetes อย่างละเอียด ความคิดริเริ่มนี้ได้รับแรงผลักดันจากความต้องการที่เพิ่มขึ้นของระบบสมัยใหม่ต่างๆ (จากสาขาโทรคมนาคม การเรียนรู้ของเครื่องจักร บริการทางการเงิน ฯลฯ) สำหรับการประมวลผลแบบขนานประสิทธิภาพสูง และลดความล่าช้าในการดำเนินการซึ่งใช้ CPU ขั้นสูงและ ความสามารถในการเร่งความเร็วด้วยฮาร์ดแวร์ จนถึงขณะนี้การเพิ่มประสิทธิภาพดังกล่าวใน Kubernetes ทำได้สำเร็จด้วยส่วนประกอบที่แตกต่างกัน (ตัวจัดการ CPU, ตัวจัดการอุปกรณ์, CNI) และตอนนี้จะมีการเพิ่มอินเทอร์เฟซภายในเดียวที่รวมแนวทางเข้าด้วยกันและลดความยุ่งยากในการเชื่อมต่อของโทโพโลยีใหม่ที่คล้ายกัน - ที่เรียกว่าโทโพโลยี - ทราบ - ส่วนประกอบทางฝั่ง Kubelet รายละเอียด-เข้า KEP ที่เกี่ยวข้อง.

ไดอะแกรมส่วนประกอบตัวจัดการโทโพโลยี

คุณสมบัติถัดไป - ตรวจสอบคอนเทนเนอร์ในขณะที่กำลังทำงานอยู่ (โพรบเริ่มต้น). ดังที่คุณทราบ สำหรับคอนเทนเนอร์ที่ใช้เวลานานในการเปิดใช้งาน เป็นการยากที่จะได้รับสถานะที่ทันสมัย: คอนเทนเนอร์เหล่านั้นจะถูก "ปิดตาย" ก่อนที่จะเริ่มทำงานจริง หรือจบลงด้วยการหยุดชะงักเป็นเวลานาน เช็คใหม่ (เปิดใช้งานผ่านฟีเจอร์เกตที่เรียกว่า StartupProbeEnabled) ยกเลิก - หรือค่อนข้างจะเลื่อน - ผลกระทบของการตรวจสอบอื่น ๆ จนกระทั่งช่วงเวลาที่พ็อดทำงานเสร็จสิ้น ด้วยเหตุนี้ เดิมทีคุณลักษณะนี้จึงถูกเรียก pod-startup liveness-probe ระงับ. สำหรับพ็อดที่ใช้เวลานานในการเริ่มต้น คุณสามารถสำรวจสถานะในช่วงเวลาที่ค่อนข้างสั้นได้

นอกจากนี้ การปรับปรุง RuntimeClass พร้อมใช้งานทันทีในสถานะเบต้า โดยเพิ่มการรองรับ "คลัสเตอร์ที่ต่างกัน" ค การจัดตารางเรียนรันไทม์ ตอนนี้ไม่จำเป็นเลยที่แต่ละโหนดจะต้องรองรับ RuntimeClass แต่ละรายการ: สำหรับพ็อด คุณสามารถเลือก RuntimeClass ได้โดยไม่ต้องคำนึงถึงโทโพโลยีคลัสเตอร์ ก่อนหน้านี้ เพื่อให้บรรลุเป้าหมายนี้ เพื่อให้พ็อดจบลงบนโหนดที่รองรับทุกสิ่งที่ต้องการ จึงจำเป็นต้องกำหนดกฎที่เหมาะสมให้กับ NodeSelector และค่าความคลาดเคลื่อน ใน KEP มันพูดถึงตัวอย่างการใช้งานและแน่นอนว่ารวมถึงรายละเอียดการใช้งาน

เครือข่าย

คุณสมบัติเครือข่ายที่สำคัญสองประการที่ปรากฏเป็นครั้งแรก (ในเวอร์ชันอัลฟ่า) ใน Kubernetes 1.16 ได้แก่:

• สนับสนุน สแต็กเครือข่ายคู่ - IPv4/IPv6 - และ "ความเข้าใจ" ที่สอดคล้องกันในระดับพ็อด โหนด บริการ ประกอบด้วยการทำงานร่วมกันระหว่าง IPv4-to-IPv4 และ IPv6-to-IPv6 ระหว่างพ็อด ตั้งแต่พ็อดไปจนถึงบริการภายนอก การใช้งานอ้างอิง (ภายในปลั๊กอิน Bridge CNI, PTP CNI และ Host-Local IPAM) ตลอดจน Reverse Compatible กับคลัสเตอร์ Kubernetes ที่ทำงานอยู่ IPv4 หรือ IPv6 เท่านั้น รายละเอียดการดำเนินการอยู่ใน KEP.

  ตัวอย่างการแสดงที่อยู่ 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 ใหม่สำหรับปลายทาง - EndpointSlice API. ช่วยแก้ปัญหาด้านประสิทธิภาพ/ความสามารถในการปรับขนาดของ Endpoint API ที่มีอยู่ซึ่งส่งผลต่อส่วนประกอบต่างๆ ในแผงควบคุม (apiserver, ฯลฯ , ตัวควบคุมตำแหน่งข้อมูล, kube-proxy) API ใหม่จะถูกเพิ่มในกลุ่ม Discovery API และจะสามารถให้บริการแบ็คเอนด์เอนด์พอยต์นับหมื่นในแต่ละบริการในคลัสเตอร์ที่ประกอบด้วยโหนดนับพันรายการ เมื่อต้องการทำเช่นนี้ แต่ละบริการจะถูกแมปกับออบเจ็กต์ N รายการ EndpointSliceซึ่งแต่ละจุดโดยค่าเริ่มต้นจะมีจุดปลายไม่เกิน 100 จุด (สามารถกำหนดค่าได้) EndpointSlice API ยังให้โอกาสในการพัฒนาในอนาคต: รองรับที่อยู่ IP หลายรายการสำหรับแต่ละพ็อด สถานะใหม่สำหรับจุดสิ้นสุด (ไม่เพียงแต่ Ready и NotReady) การตั้งค่าย่อยแบบไดนามิกสำหรับปลายทาง

ที่นำเสนอในรุ่นล่าสุดถึงรุ่นเบต้าแล้ว คนสุดท้ายชื่อ service.kubernetes.io/load-balancer-cleanup และแนบมากับแต่ละบริการด้วยประเภท LoadBalancer. ในขณะที่ลบบริการดังกล่าว จะป้องกันการลบทรัพยากรจริงจนกว่า "การล้างข้อมูล" ของทรัพยากรตัวปรับสมดุลที่เกี่ยวข้องทั้งหมดจะเสร็จสิ้น

เครื่องจักรเอพีไอ

“เหตุการณ์สำคัญด้านความเสถียร” ที่แท้จริงนั้นอยู่ในขอบเขตของเซิร์ฟเวอร์ Kubernetes API และการโต้ตอบกับมัน สิ่งนี้เกิดขึ้นอย่างมากต้องขอบคุณ โอนไปสู่สถานะที่มั่นคงผู้ที่ไม่ต้องการการแนะนำเป็นพิเศษ CustomResourceDefinitions (ซีอาร์ดี)ซึ่งมีสถานะเบต้ามาตั้งแต่สมัย Kubernetes 1.7 อันห่างไกล (และนี่คือเดือนมิถุนายน 2017!) ความเสถียรแบบเดียวกันนี้มาพร้อมกับคุณสมบัติที่เกี่ยวข้อง:

• "ทรัพยากรย่อย" ด้วย /status и /scale สำหรับ CustomResources;
• การแปลง เวอร์ชันสำหรับ CRD โดยอิงจาก webhook ภายนอก
• นำเสนอเมื่อเร็ว ๆ นี้ (ใน K8s 1.15) ค่าเริ่มต้น (ค่าเริ่มต้น) และการลบฟิลด์อัตโนมัติ (การตัดแต่งกิ่ง) สำหรับ CustomResources;
• โอกาส ใช้สคีมา OpenAPI v3 เพื่อสร้างและเผยแพร่เอกสาร OpenAPI ที่ใช้ในการตรวจสอบทรัพยากร CRD บนฝั่งเซิร์ฟเวอร์

กลไกอื่นที่ผู้ดูแลระบบ Kubernetes คุ้นเคยมานานแล้ว: เว็บฮุครับสมัคร - ยังคงอยู่ในสถานะเบต้าเป็นเวลานาน (ตั้งแต่ K8s 1.9) และตอนนี้ก็ประกาศว่าเสถียรแล้ว

คุณสมบัติอื่นอีกสองประการถึงรุ่นเบต้าแล้ว: ใช้ฝั่งเซิร์ฟเวอร์ и ดูบุ๊กมาร์ก.

และนวัตกรรมที่สำคัญเพียงอย่างเดียวในเวอร์ชันอัลฟ่าก็คือ ความล้มเหลว จาก SelfLink — URI พิเศษที่แสดงถึงวัตถุที่ระบุและเป็นส่วนหนึ่งของ ObjectMeta и ListMeta (เช่น ส่วนหนึ่งของออบเจ็กต์ใดๆ ใน Kubernetes) ทำไมพวกเขาถึงละทิ้งมัน? แรงจูงใจด้วยวิธีง่ายๆ เสียง เนื่องจากไม่มีเหตุผลที่แท้จริง (ล้นหลาม) ที่ทำให้ฟิลด์นี้ยังคงมีอยู่ เหตุผลที่เป็นทางการเพิ่มเติมคือการเพิ่มประสิทธิภาพการทำงาน (โดยการลบฟิลด์ที่ไม่จำเป็นออก) และเพื่อลดความซับซ้อนของการทำงานของ generic-apiserver ซึ่งถูกบังคับให้จัดการฟิลด์ดังกล่าวด้วยวิธีพิเศษ (นี่เป็นฟิลด์เดียวที่ตั้งค่าไว้ตรงหน้าวัตถุ เป็นอนุกรม) ความล้าสมัยที่แท้จริง (ภายในเบต้า) SelfLink จะเกิดขึ้นโดย Kubernetes เวอร์ชัน 1.20 และสุดท้าย - 1.21

การจัดเก็บข้อมูล

งานหลักในพื้นที่จัดเก็บเช่นเดียวกับในรุ่นก่อนหน้านั้นถูกสังเกตในพื้นที่ การสนับสนุนของซีเอสไอ. การเปลี่ยนแปลงหลักที่นี่คือ:

• เป็นครั้งแรก (ในเวอร์ชันอัลฟ่า) ปรากฏ รองรับปลั๊กอิน CSI สำหรับโหนดผู้ปฏิบัติงาน Windows: วิธีการทำงานกับพื้นที่จัดเก็บข้อมูลในปัจจุบันจะแทนที่ปลั๊กอินในแผนผังในคอร์ Kubernetes และปลั๊กอิน FlexVolume จาก Microsoft ที่ใช้ Powershell

  
  โครงการติดตั้งปลั๊กอิน CSI ใน Kubernetes สำหรับ Windows

• โอกาส การปรับขนาดปริมาณ CSIซึ่งเปิดตัวใน K8s 1.12 และได้ขยายเป็นเวอร์ชันเบต้าแล้ว
• "การโปรโมต" ที่คล้ายกัน (จากอัลฟ่าถึงเบต้า) เกิดขึ้นได้จากความสามารถในการใช้ CSI เพื่อสร้างปริมาณชั่วคราวในท้องถิ่น (การสนับสนุนปริมาณอินไลน์ CSI).

เปิดตัวใน Kubernetes เวอร์ชันก่อนหน้า ฟังก์ชั่นการโคลนโวลุ่ม (ใช้พีวีซีที่มีอยู่เป็น DataSource เพื่อสร้าง PVC ใหม่) ตอนนี้ได้รับสถานะเบต้าแล้วเช่นกัน

กำหนดการ

การเปลี่ยนแปลงกำหนดการที่โดดเด่นสองประการ (ทั้งในรุ่นอัลฟ่า):

• EvenPodsSpreading - โอกาส ใช้พ็อดแทนหน่วยแอปพลิเคชันแบบลอจิคัลสำหรับ "การกระจายที่ยุติธรรม" ของโหลด (เช่น Deployment และ ReplicaSet) และการปรับการกระจายนี้ (เป็นข้อกำหนดที่ยากหรือเป็นเงื่อนไขที่อ่อนนุ่ม เช่น ลำดับความสำคัญ) คุณลักษณะนี้จะขยายความสามารถในการกระจายที่มีอยู่ของพ็อดที่วางแผนไว้ ซึ่งปัจจุบันถูกจำกัดด้วยตัวเลือกต่างๆ PodAffinity и PodAntiAffinityทำให้ผู้ดูแลระบบสามารถควบคุมได้ดีขึ้นในเรื่องนี้ ซึ่งหมายถึงความพร้อมใช้งานสูงและการใช้ทรัพยากรที่ปรับให้เหมาะสมยิ่งขึ้น รายละเอียด-เข้า KEP.
• ใช้ นโยบาย BestFit в ฟังก์ชันลำดับความสำคัญ RequestedToCapacityRatio ในระหว่างการวางแผนพ็อดซึ่งจะช่วยให้ เพื่อสมัคร บรรจุถัง (“การบรรจุในคอนเทนเนอร์”) สำหรับทั้งทรัพยากรพื้นฐาน (โปรเซสเซอร์ หน่วยความจำ) และทรัพยากรเพิ่มเติม (เช่น GPU) สำหรับรายละเอียดเพิ่มเติม โปรดดู KEP.

  
  พ็อดการกำหนดเวลา: ก่อนที่จะใช้นโยบายที่เหมาะสมที่สุด (โดยตรงผ่านตัวกำหนดตารางเวลาเริ่มต้น) และการใช้งาน (ผ่านตัวขยายกำหนดการ)

นอกจากนี้ แสดงโดย ความสามารถในการสร้างปลั๊กอินของคุณเองสำหรับตัวกำหนดเวลาภายนอกแผนผังการพัฒนา Kubernetes หลัก (นอกแผนผัง)

การเปลี่ยนแปลงอื่นๆ

นอกจากนี้ใน Kubernetes 1.16 ยังสามารถสังเกตได้ ความคิดริเริ่มสำหรับ การนำ เมตริกที่มีอยู่ตามลำดับทั้งหมดหรือเจาะจงมากขึ้นตาม กฎระเบียบอย่างเป็นทางการ ไปจนถึงเครื่องมือของ K8 พวกเขาพึ่งพาสิ่งที่เกี่ยวข้องเป็นส่วนใหญ่ เอกสารของโพรมีธีอุส. ความไม่สอดคล้องกันเกิดขึ้นจากหลายสาเหตุ (เช่น ตัววัดบางตัวถูกสร้างขึ้นก่อนที่คำแนะนำปัจจุบันจะปรากฏขึ้น) และนักพัฒนาตัดสินใจว่าถึงเวลาแล้วที่จะต้องนำทุกอย่างไปสู่มาตรฐานเดียว "ซึ่งสอดคล้องกับส่วนที่เหลือของระบบนิเวศของ Prometheus" การดำเนินการตามความคิดริเริ่มนี้ในปัจจุบันอยู่ในสถานะอัลฟ่า ซึ่งจะได้รับการส่งเสริมอย่างต่อเนื่องใน Kubernetes เวอร์ชันต่อๆ ไปเป็นเบต้า (1.17) และเสถียร (1.18)

นอกจากนี้ ยังสามารถสังเกตการเปลี่ยนแปลงต่อไปนี้:

• การพัฒนาการสนับสนุน Windows с รูปร่าง ยูทิลิตี้ Kubeadm สำหรับระบบปฏิบัติการนี้ (เวอร์ชันอัลฟ่า) โอกาส RunAsUserName สำหรับคอนเทนเนอร์ Windows (เวอร์ชันอัลฟ่า) การปรับปรุง บัญชีบริการที่มีการจัดการกลุ่ม (gMSA) รองรับเวอร์ชันเบต้า สนับสนุน เมานต์/แนบสำหรับโวลุ่ม vSphere
• รีไซเคิล กลไกการบีบอัดข้อมูลในการตอบสนองของ API. ก่อนหน้านี้ ตัวกรอง HTTP ถูกใช้เพื่อวัตถุประสงค์เหล่านี้ ซึ่งกำหนดข้อจำกัดหลายประการที่ทำให้ไม่สามารถเปิดใช้งานได้ตามค่าเริ่มต้น ตอนนี้ "การบีบอัดคำขอแบบโปร่งใส" ใช้งานได้แล้ว: การส่งไคลเอ็นต์ Accept-Encoding: gzip ในส่วนหัว พวกเขาจะได้รับการตอบสนองที่บีบอัด GZIP หากขนาดเกิน 128 KB ลูกค้า Go รองรับการบีบอัดโดยอัตโนมัติ (ส่งส่วนหัวที่จำเป็น) ดังนั้นพวกเขาจะสังเกตเห็นปริมาณการรับส่งข้อมูลที่ลดลงทันที (อาจต้องมีการปรับเปลี่ยนเล็กน้อยสำหรับภาษาอื่น)
• กลายเป็นไปได้ ปรับขนาด HPA จาก/เป็นศูนย์พ็อดตามตัวชี้วัดภายนอก. หากคุณปรับขนาดตามออบเจ็กต์/ตัววัดภายนอก เมื่อปริมาณงานไม่ได้ใช้งาน คุณสามารถปรับขนาดแบบจำลองเป็น 0 ได้โดยอัตโนมัติเพื่อประหยัดทรัพยากร คุณลักษณะนี้ควรมีประโยชน์อย่างยิ่งสำหรับกรณีที่ผู้ปฏิบัติงานร้องขอทรัพยากร GPU และจำนวนผู้ปฏิบัติงานที่ไม่ได้ใช้งานประเภทต่างๆ เกินจำนวน GPU ที่มีอยู่
• ลูกค้าใหม่ - k8s.io/client-go/metadata.Client — สำหรับการเข้าถึงวัตถุแบบ "ทั่วไป" ได้รับการออกแบบมาเพื่อดึงข้อมูลเมตาได้อย่างง่ายดาย (เช่น ส่วนย่อย metadata) จากทรัพยากรคลัสเตอร์และดำเนินการรวบรวมขยะและโควต้าร่วมกับทรัพยากรเหล่านั้น
• สร้าง Kubernetes ตอนนี้คุณสามารถ โดยไม่มีผู้ให้บริการระบบคลาวด์แบบเดิม ("ในตัว" ในแผนผัง) (เวอร์ชันอัลฟ่า)
• ไปยังยูทิลิตี้ kubeadm เพิ่ม ความสามารถทดลอง (เวอร์ชันอัลฟ่า) เพื่อใช้แพตช์ปรับแต่งระหว่างการดำเนินการ init, join и upgrade. เรียนรู้เพิ่มเติมเกี่ยวกับวิธีใช้แฟล็ก --experimental-kustomize, ดูใน KEP.
• จุดสิ้นสุดใหม่สำหรับ apiserver - readyz, - ช่วยให้คุณสามารถส่งออกข้อมูลเกี่ยวกับความพร้อมได้ ขณะนี้เซิร์ฟเวอร์ API มีการตั้งค่าสถานะแล้ว --maximum-startup-sequence-durationช่วยให้คุณสามารถควบคุมการรีสตาร์ทได้
• สอง คุณสมบัติสำหรับ Azure ประกาศมีเสถียรภาพ: การสนับสนุน โซนความพร้อมใช้งาน (โซนที่มีจำหน่าย) และ กลุ่มข้ามทรัพยากร (อาร์จี). นอกจากนี้ Azure ยังเพิ่ม:
  • การสนับสนุนการตรวจสอบสิทธิ์ AAD และ ADFS;
  • คำอธิบายประกอบ service.beta.kubernetes.io/azure-pip-name เพื่อระบุ IP สาธารณะของโหลดบาลานเซอร์
  • โอกาส การตั้งค่า LoadBalancerName и LoadBalancerResourceGroup.
• ตอนนี้ AWS ได้แล้ว สนับสนุน สำหรับ EBS บน Windows และ ปรับให้เหมาะสม การเรียก EC2 API DescribeInstances.
• ตอนนี้ Kubeadm เป็นอิสระแล้ว อพยพ การกำหนดค่า CoreDNS เมื่ออัปเกรดเวอร์ชัน CoreDNS
• ไบนารี ฯลฯ ในอิมเมจ Docker ที่เกี่ยวข้อง ได้ทำ ปฏิบัติการได้ทั่วโลกซึ่งช่วยให้คุณเรียกใช้อิมเมจนี้โดยไม่จำเป็นต้องใช้สิทธิ์รูท นอกจากนี้ รูปภาพการโยกย้าย ฯลฯ หยุด รองรับเวอร์ชัน etcd2
• В ตัวปรับขนาดคลัสเตอร์อัตโนมัติ 1.16.0 เปลี่ยนไปใช้ distroless เป็นอิมเมจพื้นฐาน ปรับปรุงประสิทธิภาพ เพิ่มผู้ให้บริการคลาวด์รายใหม่ (DigitalOcean, Magnum, Packet)
• อัปเดตในซอฟต์แวร์ที่ใช้/ขึ้นอยู่กับ: ไป 1.12.9, ฯลฯ 3.3.15, CoreDNS 1.6.2

PS

อ่านเพิ่มเติมในบล็อกของเรา:

• «Kubernetes 1.15: ภาพรวมของนวัตกรรมหลัก";
• «Kubernetes 1.14: ภาพรวมของนวัตกรรมหลัก";
• «Kubernetes 1.13: ภาพรวมของนวัตกรรมหลัก";
• «Kubernetes 1.12: ภาพรวมของนวัตกรรมหลัก'

ที่มา: will.com