🥇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

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

ที่มา: will.com