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

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

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

การกำหนดเส้นทางที่รับรู้โทโพโลยี

ชุมชน Kubernetes รอคอยฟีเจอร์นี้มานานแล้ว - การกำหนดเส้นทางบริการที่รับรู้โทโพโลยี. ถ้า KEP มีต้นกำเนิดในเดือนตุลาคม 2018 และอย่างเป็นทางการ หัตถการด้านการเสริมความงาม — 2 ปีที่แล้ว ปัญหาปกติ (ชอบ มัน) - และแก่ขึ้นอีกสองสามปี...

แนวคิดทั่วไปคือการจัดเตรียมความสามารถในการใช้การกำหนดเส้นทาง "ท้องถิ่น" สำหรับบริการที่อยู่ใน Kubernetes “ท้องถิ่น” ในกรณีนี้หมายถึง “ระดับทอพอโลยีเดียวกัน” (ระดับโทโพโลยี)ซึ่งอาจจะเป็น:

โหนดเหมือนกันสำหรับบริการ
ชั้นวางเซิร์ฟเวอร์เดียวกัน
ภูมิภาคเดียวกัน
ผู้ให้บริการคลาวด์รายเดียวกัน
...

ตัวอย่างการใช้คุณสมบัตินี้:

ประหยัดปริมาณการรับส่งข้อมูลในการติดตั้งบนคลาวด์ที่มีโซนความพร้อมใช้งานหลายโซน (หลาย AZ) - ดู ภาพประกอบสด ใช้ตัวอย่างการรับส่งข้อมูลจากภูมิภาคเดียวกัน แต่ AZ ต่างกันใน AWS
เวลาแฝงด้านประสิทธิภาพที่ต่ำกว่า/ปริมาณงานที่ดีขึ้น
บริการแบ่งส่วนที่มีข้อมูลท้องถิ่นเกี่ยวกับโหนดในแต่ละส่วน
การวางตำแหน่งของ fluentd (หรือแอนะล็อก) บนโหนดเดียวกันกับแอปพลิเคชันที่มีการรวบรวมบันทึก
...

การกำหนดเส้นทางดังกล่าวซึ่ง "รู้" เกี่ยวกับโทโพโลยีนั้นเรียกอีกอย่างว่าความสัมพันธ์ของเครือข่าย - โดยการเปรียบเทียบกับ ความสัมพันธ์ของโหนด, สัมพรรคภาพพ็อด/การต่อต้านสัมพรรคภาพ หรือปรากฏขึ้น ไม่นานที่ผ่านมา การจัดกำหนดการปริมาณโทโพโลยี-Aware (และ การจัดสรรปริมาณ). ระดับของการนำไปปฏิบัติในปัจจุบัน ServiceTopology ใน Kubernetes - เวอร์ชันอัลฟ่า

หากต้องการรายละเอียดเกี่ยวกับวิธีการทำงานของฟีเจอร์นี้และวิธีใช้งาน โปรดอ่าน บทความนี้ จากผู้เขียนคนหนึ่ง

รองรับ IPv4/IPv6 สแต็กคู่

ความก้าวหน้าที่สำคัญ ที่ตายตัว ในคุณสมบัติเครือข่ายอื่น: รองรับ IP สแต็กสองชุดพร้อมกันซึ่งเปิดตัวครั้งแรก K8s 1.16. โดยเฉพาะอย่างยิ่งรุ่นใหม่นำมาซึ่งการเปลี่ยนแปลงดังต่อไปนี้:

ใน kube-proxy นำไปใช้ ความเป็นไปได้ของการทำงานพร้อมกันในทั้งสองโหมด (IPv4 และ IPv6)
в Pod.Status.PodIPs ปรากฏ รองรับ downward API (ในเวลาเดียวกันกับ in /etc/hosts ตอนนี้พวกเขาต้องการให้โฮสต์เพิ่มที่อยู่ IPv6);
รองรับสแต็คคู่ ชนิด (Kubernetes ในนักเทียบท่า) และ คูบีด;
อัปเดตการทดสอบ e2e

ภาพประกอบ ใช้ dual stack IPV4/IPv6 ใน KIND

ความคืบหน้าของซีเอสไอ

ประกาศมั่นคงแล้ว การสนับสนุนโทโพโลยี สำหรับการจัดเก็บข้อมูลแบบ CSI เปิดตัวครั้งแรกใน K8s 1.12.

ความคิดริเริ่มสำหรับ การโยกย้ายปลั๊กอินวอลุ่มไปยัง CSI - การโยกย้ายของ CSI - ถึงรุ่นเบต้าแล้ว คุณลักษณะนี้มีความสำคัญอย่างยิ่งในการแปลปลั๊กอินการจัดเก็บข้อมูลที่มีอยู่ (ในต้นไม้) สู่อินเทอร์เฟซที่ทันสมัย (CSI นอกแผนผัง) มองไม่เห็นสำหรับผู้ใช้ปลายทาง Kubernetes ผู้ดูแลระบบคลัสเตอร์จะต้องเปิดใช้งาน CSI Migration เท่านั้น หลังจากนั้นทรัพยากรและปริมาณงานแบบมีสถานะที่มีอยู่จะยังคง “ใช้งานได้”... แต่ใช้ไดรเวอร์ CSI ล่าสุดแทนไดรเวอร์ที่ล้าสมัยซึ่งรวมอยู่ในคอร์ Kubernetes

ในขณะนี้ การโยกย้ายสำหรับไดรเวอร์ AWS EBS พร้อมแล้วในเวอร์ชันเบต้า (kubernetes.io/aws-ebs) และ GCE PD (kubernetes.io/gce-pd). การคาดการณ์สำหรับสถานที่จัดเก็บอื่น ๆ มีดังนี้:

เราได้พูดคุยกันว่าการสนับสนุนพื้นที่เก็บข้อมูล "แบบดั้งเดิม" ใน K8 เข้ามาสู่ CSI ได้อย่างไร บทความนี้. และการเปลี่ยนการโยกย้าย CSI ไปสู่สถานะเบต้านั้นมีไว้เพื่อโดยเฉพาะ สิ่งพิมพ์แยกต่างหาก ในบล็อกของโครงการ

นอกจากนี้ ฟังก์ชันการทำงานที่สำคัญอีกประการหนึ่งในบริบทของ CSI ซึ่งมีต้นกำเนิด (การใช้งานอัลฟ่า) ใน K1.17s 8 ถึงสถานะเบต้า (เช่น เปิดใช้งานโดยค่าเริ่มต้น) ในรุ่น Kubernetes 1.12 - การสร้างภาพรวม และการฟื้นตัวจากพวกเขา. การเปลี่ยนแปลงที่เกิดขึ้นกับ Kubernetes Volume Snapshot ในเวอร์ชันเบต้า:

การแยกรถเทียมข้างรถจักรยานยนต์ Snapshotter ภายนอกของ CSI ออกเป็นตัวควบคุมสองตัว
เพิ่มความลับในการลบ (ความลับในการลบ) เป็นคำอธิบายประกอบเนื้อหาของ Volume Snapshot
เข้ารอบสุดท้ายใหม่ (เข้ารอบสุดท้าย) เพื่อป้องกันไม่ให้วัตถุ Snapshot API ถูกลบหากมีการเชื่อมต่อที่เหลืออยู่

ณ เวลาที่เปิดตัว 1.17 คุณลักษณะนี้ได้รับการสนับสนุนโดยไดรเวอร์ CSI สามตัว: ไดรเวอร์ GCE Persistent Disk CSI, ไดรเวอร์ Portworx CSI และไดรเวอร์ NetApp Trident CSI รายละเอียดเพิ่มเติมเกี่ยวกับการนำไปใช้และการใช้งานสามารถพบได้ใน สิ่งพิมพ์นี้ บนบล็อก

ป้ายกำกับผู้ให้บริการระบบคลาวด์

ป้ายกำกับนั้นโดยอัตโนมัติ กำหนดให้กับโหนดและวอลุ่มที่สร้างขึ้นขึ้นอยู่กับผู้ให้บริการคลาวด์ที่ใช้มีให้ใช้งานใน Kubernetes เป็นเวอร์ชันเบต้ามาเป็นเวลานานแล้ว - นับตั้งแต่เปิดตัว K8s 1.2 (เมษายน 2016!). เนื่องจากมีการใช้อย่างแพร่หลายมาอย่างยาวนานผู้พัฒนา ตัดสินใจแล้วถึงเวลาประกาศฟีเจอร์เสถียร (GA)

ดังนั้นพวกเขาทั้งหมดจึงถูกเปลี่ยนชื่อตาม (ตามโทโพโลยี):

beta.kubernetes.io/instance-type → node.kubernetes.io/instance-type
failure-domain.beta.kubernetes.io/zone → topology.kubernetes.io/zone
failure-domain.beta.kubernetes.io/region → topology.kubernetes.io/region

... แต่ยังคงใช้งานได้ภายใต้ชื่อเก่า (สำหรับความเข้ากันได้แบบย้อนหลัง) อย่างไรก็ตาม ขอแนะนำให้ผู้ดูแลระบบทุกคนเปลี่ยนไปใช้ป้ายกำกับปัจจุบัน เอกสารที่เกี่ยวข้อง K8s ได้รับการอัพเดตแล้ว

เอาต์พุตที่มีโครงสร้างของ kubeadm

นำเสนอในเวอร์ชันอัลฟ่าเป็นครั้งแรก เอาต์พุตที่มีโครงสร้างสำหรับยูทิลิตี้ kubeadm. รูปแบบที่รองรับ: JSON, YAML, Go template

แรงจูงใจในการใช้คุณลักษณะนี้ (ตาม KEP) เป็น:

แม้ว่า Kubernetes จะสามารถปรับใช้ด้วยตนเองได้ แต่มาตรฐานโดยพฤตินัย (หากไม่ใช่โดยนิตินัย) สำหรับการดำเนินการนี้คือการใช้ kubeadm เครื่องมือการจัดการระบบยอดนิยม เช่น Terraform อาศัย kubeadm สำหรับการปรับใช้ Kubernetes การปรับปรุงที่วางแผนไว้สำหรับ Cluster API รวมถึงแพ็คเกจที่ประกอบได้สำหรับการบูต Kubernetes ด้วย kubeadm และ cloud-init

หากไม่มีเอาต์พุตที่มีโครงสร้าง แม้แต่การเปลี่ยนแปลงที่ไม่อันตรายที่สุดเมื่อมองแวบแรกก็สามารถทำลาย Terraform, Cluster API และซอฟต์แวร์อื่นๆ ที่ใช้ผลลัพธ์ของ kubeadm ได้

แผนเร่งด่วนของเรารวมการสนับสนุน (ในรูปแบบของเอาต์พุตที่มีโครงสร้าง) สำหรับคำสั่ง kubeadm ต่อไปนี้:

alpha certs
config images list
init
token create
token list
upgrade plan
version

ภาพประกอบการตอบสนอง JSON ต่อคำสั่ง kubeadm init -o json:

{
  "node0": "192.168.20.51:443",
  "caCrt": "sha256:1f40ff4bd1b854fb4a5cf5d2f38267a5ce5f89e34d34b0f62bf335d74eef91a3",
  "token": {
    "id":          "5ndzuu.ngie1sxkgielfpb1",
    "ttl":         "23h",
    "expires":     "2019-05-08T18:58:07Z",
    "usages":      [
      "authentication",
      "signing"
    ],
    "description": "The default bootstrap token generated by 'kubeadm init'.",
    "extraGroups": [
      "system:bootstrappers:kubeadm:default-node-token"
    ]
  },
  "raw": "Rm9yIHRoZSBhY3R1YWwgb3V0cHV0IG9mIHRoZSAia3ViZWFkbSBpbml0IiBjb21tYW5kLCBwbGVhc2Ugc2VlIGh0dHBzOi8vZ2lzdC5naXRodWIuY29tL2FrdXR6LzdhNjg2ZGU1N2JmNDMzZjkyZjcxYjZmYjc3ZDRkOWJhI2ZpbGUta3ViZWFkbS1pbml0LW91dHB1dC1sb2c="
}

ความเสถียรของนวัตกรรมอื่นๆ

โดยทั่วไปการเปิดตัว Kubernetes 1.17 เกิดขึ้นภายใต้คำขวัญ “ความมั่นคง" สิ่งนี้อำนวยความสะดวกด้วยความจริงที่ว่ามีคุณสมบัติมากมายในนั้น (จำนวนทั้งหมดคือ 14) ได้รับสถานะ GA ในหมู่พวกเขา:

“การทำเครื่องหมาย” โหนดตามเงื่อนไขบางประการ (TaintNodesByCondition) ปรากฏใน K8s 1.8;
ดูบุ๊กมาร์ก - กิจกรรมรูปแบบใหม่ที่มีป้ายกำกับว่าออบเจ็กต์ทั้งหมดขึ้นอยู่กับเวอร์ชันที่กำหนด (resourceVersion) ได้รับการประมวลผลโดยนาฬิกาแล้ว
ค่าเริ่มต้น (ค่าเริ่มต้น) สำหรับทรัพยากรที่กำหนดเอง
ที่ใช้ร่วมกันระหว่างภาชนะ ในเนมสเปซกระบวนการพ็อด
ScheduleDaemonSetPods - การตั้งเวลาพ็อดใน DaemonSet ใช้ kube-scheduler (แทนตัวควบคุม DaemonSet);
ขีดจำกัดแบบไดนามิก ตามจำนวนวอลุ่มขึ้นอยู่กับประเภทของโหนด
การสนับสนุนตัวแปรสภาพแวดล้อม สำหรับชื่อไดเร็กทอรีที่ติดตั้งเป็น subPath;
การถ่ายโอนการเต้นของหัวใจ Kubelet ไปยัง Lease API เฉพาะทาง
"การป้องกันขั้นสุดท้าย" (การป้องกันขั้นสุดท้าย) สำหรับโหลดบาลานเซอร์ (ตรวจสอบทรัพยากรบริการที่เกี่ยวข้องก่อนที่จะลบทรัพยากร LoadBalancer)
การเพิ่มประสิทธิภาพ kube-apiserver ในประสิทธิภาพการทำงานเมื่อใช้งานร่วมกับนาฬิกาหลายเรือนที่ตรวจสอบชุดของวัตถุที่เหมือนกัน - ทำได้โดยการหลีกเลี่ยงการทำให้วัตถุเดียวกันเป็นอนุกรมซ้ำสำหรับนาฬิกาแต่ละเรือน

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

รายการนวัตกรรมทั้งหมดใน Kubernetes 1.17 ไม่ได้จำกัดอยู่เพียงรายการข้างต้นเท่านั้น นี่คือบางส่วนอื่นๆ (และสำหรับรายการที่สมบูรณ์ยิ่งขึ้น โปรดดู การเปลี่ยนแปลง):

คุณลักษณะที่นำเสนอในรุ่นล่าสุดได้มาถึงเวอร์ชันเบต้าแล้ว RunAsUserName สำหรับ windows;
การเปลี่ยนแปลงที่คล้ายกัน เกิดขึ้น EndpointSlice API (รวมถึงจาก K8s 1.16) อย่างไรก็ตาม ในตอนนี้โซลูชันเพื่อปรับปรุงประสิทธิภาพ/ความสามารถในการปรับขนาดของ Endpoint API ไม่ได้เปิดใช้งานตามค่าเริ่มต้น
ขณะนี้พ็อดมีความสำคัญอย่างยิ่งต่อการทำงานของคลัสเตอร์ สามารถสร้างได้ ไม่เพียงแต่ในเนมสเปซเท่านั้น kube-system (สำหรับรายละเอียด โปรดดูเอกสารประกอบสำหรับ จำกัดการใช้ระดับความสำคัญ);
ทางเลือกใหม่สำหรับ kubelet - --reserved-cpus — ช่วยให้คุณกำหนดรายการ CPU ที่สงวนไว้สำหรับระบบได้อย่างชัดเจน
สำหรับ kubectl logs นำเสนอ ธงใหม่ --prefixโดยเพิ่มชื่อของพ็อดและคอนเทนเนอร์ต้นทางลงในแต่ละบรรทัดของบันทึก
в label.Selector เพิ่ม RequiresExactMatch;
คอนเทนเนอร์ทั้งหมดใน kube-dns ตอนนี้กำลังทำงานอยู่ มีสิทธิพิเศษน้อยกว่า
ไฮเปอร์คิวบ์ แยกออกเป็นพื้นที่เก็บข้อมูล GitHub แยกต่างหาก และจะไม่รวมอยู่ในรุ่น Kubernetes อีกต่อไป
มาก ปรับปรุงประสิทธิภาพ kube-proxy สำหรับพอร์ตที่ไม่ใช่ UDP

การเปลี่ยนแปลงการพึ่งพา:

เวอร์ชัน CoreDNS ที่รวมอยู่ใน kubeadm คือ 1.6.5;
เวอร์ชัน crictl อัปเดตเป็น v1.16.1;
ซีเอสไอ 1.2.0;
ฯลฯ 3.4.3;
เวอร์ชัน Docker ที่ทดสอบล่าสุดอัปเกรดเป็น 19.03;
เวอร์ชัน Go ขั้นต่ำที่จำเป็นสำหรับการสร้าง Kubernetes 1.17 คือ 1.13.4

PS

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

ที่มา: will.com

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