โปรโฮสต์ > บล็อก > การบริหาร > Kubernetes 1.14: ภาพรวมของนวัตกรรมหลัก

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

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

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

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

เริ่มต้นด้วยการแนะนำที่สำคัญจากวงจรชีวิตของคลัสเตอร์ SIG: คลัสเตอร์เฟลโอเวอร์แบบไดนามิก Kubernetes (หรือเรียกอีกอย่างว่าการปรับใช้ HA ที่โฮสต์เอง) อยู่ในขณะนี้ สามารถสร้างได้ การใช้คำสั่งที่คุ้นเคย (ในบริบทของคลัสเตอร์โหนดเดียว) kubeadm (init и join). กล่าวโดยย่อสำหรับสิ่งนี้:

  • ใบรับรองที่ใช้โดยคลัสเตอร์จะถูกถ่ายโอนไปยังข้อมูลลับ
  • สำหรับความเป็นไปได้ในการใช้คลัสเตอร์ etcd ภายในคลัสเตอร์ K8s (เช่น การกำจัดการพึ่งพาภายนอกที่มีอยู่ก่อนหน้านี้) etcd-ตัวดำเนินการ;
  • บันทึกการตั้งค่าที่แนะนำสำหรับโหลดบาลานเซอร์ภายนอกที่ให้การกำหนดค่าที่ทนทานต่อข้อผิดพลาด (ในอนาคต มีการวางแผนว่าจะกำจัดการพึ่งพานี้ แต่ไม่ใช่ในขั้นตอนนี้)

Kubernetes 1.14: ภาพรวมของนวัตกรรมหลัก
สถาปัตยกรรมของคลัสเตอร์ Kubernetes HA ที่สร้างด้วย kubeadm

ดูรายละเอียดการดำเนินการได้ใน ข้อเสนอการออกแบบ. ฟีเจอร์นี้เป็นสิ่งที่รอคอยกันมานาน คาดว่าเวอร์ชันอัลฟ่าจะกลับมาใน K8s 1.9 แต่ตอนนี้ปรากฏเพียงตอนนี้เท่านั้น

API

ทีม apply และโดยทั่วไปแล้ว การจัดการวัตถุที่ประกาศ ผ่าน ของ kubectl ในเซิร์ฟเวอร์ API นักพัฒนาเองก็อธิบายการตัดสินใจสั้น ๆ โดยบอกว่า kubectl apply - ส่วนพื้นฐานของการทำงานกับการกำหนดค่าใน Kubernetes อย่างไรก็ตาม "มันเต็มไปด้วยข้อบกพร่องและแก้ไขได้ยาก" ดังนั้นฟังก์ชันนี้จึงต้องถูกนำกลับมาเป็นปกติและถ่ายโอนไปยังระนาบควบคุม ตัวอย่างปัญหาที่ง่ายและชัดเจนที่มีอยู่ในปัจจุบัน:

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

รายละเอียดการนำไปปฏิบัติอยู่ใน KEP. ความพร้อมในปัจจุบันคืออัลฟ่า (มีการวางแผนการโปรโมตเป็นเบต้าสำหรับ Kubernetes รุ่นถัดไป)

ทำให้มีอยู่ในรุ่นอัลฟ่า โอกาส โดยใช้โครงร่าง OpenAPI v3 สำหรับ การสร้างและเผยแพร่เอกสาร OpenAPI สำหรับ CustomResources (CR) ใช้เพื่อตรวจสอบ (ฝั่งเซิร์ฟเวอร์) ทรัพยากรที่ผู้ใช้กำหนดของ K8 (CustomResourceDefinition, CRD) การเผยแพร่ OpenAPI สำหรับ CRD ช่วยให้ลูกค้า (เช่น kubectl) ทำการตรวจสอบความถูกต้องจากฝั่งของคุณ (ภายใน kubectl create и kubectl apply) และออกเอกสารตามโครงการ (kubectl explain). รายละเอียด-เข้า KEP.

บันทึกที่มีอยู่แล้ว ตอนนี้กำลังเปิดอยู่ ด้วยธง O_APPEND (แต่ไม่ O_TRUNC) เพื่อหลีกเลี่ยงการสูญเสียบันทึกในบางสถานการณ์ และเพื่อความสะดวกในการตัดทอนบันทึกด้วยยูทิลิตี้ภายนอกเพื่อการหมุนเวียน

นอกจากนี้ในบริบทของ Kubernetes API ก็สามารถสังเกตได้ว่าใน PodSandbox и PodSandboxStatus เพิ่ม สนาม runtime_handler เพื่อบันทึกข้อมูลเกี่ยวกับ RuntimeClass ในพ็อด (อ่านเพิ่มเติมในข้อความเกี่ยวกับ Kubernetes 1.12 เปิดตัวโดยที่คลาสนี้ปรากฏเป็นเวอร์ชันอัลฟ่า) และใน Admission Webhooks นำไปใช้ ความสามารถในการกำหนดเวอร์ชันใด AdmissionReview พวกเขาสนับสนุน ในที่สุด กฎ Admission Webhooks ก็มาถึงแล้ว สามารถถูกจำกัดได้ ขอบเขตการใช้งานโดยเนมสเปซและเฟรมเวิร์กคลัสเตอร์

พื้นที่จัดเก็บ

PersistentLocalVolumesซึ่งมีสถานะเบต้าตั้งแต่เปิดตัว K8s 1.10, ประกาศ เสถียร (GA): เกตฟีเจอร์นี้ไม่ได้ปิดใช้งานอีกต่อไป และจะถูกลบออกใน Kubernetes 1.17

โอกาส โดยใช้ตัวแปรสภาพแวดล้อมที่เรียกว่า API ลง (เช่น ชื่อพ็อด) สำหรับชื่อของไดเร็กทอรีที่เมาท์เป็น subPathได้รับการพัฒนา-ในรูปแบบสนามใหม่ subPathExprซึ่งตอนนี้ใช้เพื่อกำหนดชื่อไดเร็กทอรีที่ต้องการ คุณลักษณะนี้เริ่มปรากฏใน Kubernetes 1.11 แต่สำหรับ 1.14 คุณลักษณะดังกล่าวยังคงอยู่ในสถานะเวอร์ชันอัลฟ่า

เช่นเดียวกับ Kubernetes รุ่นก่อนหน้า มีการเปลี่ยนแปลงที่สำคัญหลายประการสำหรับ CSI (Container Storage Interface) ที่กำลังพัฒนาอย่างแข็งขัน:

CSI

พร้อมใช้งานแล้ว (เป็นส่วนหนึ่งของเวอร์ชันอัลฟ่า) สนับสนุน การปรับขนาดสำหรับปริมาณ CSI. หากต้องการใช้งานคุณจะต้องเปิดใช้งานฟีเจอร์เกตที่เรียกว่า ExpandCSIVolumesรวมถึงการรองรับการดำเนินการนี้ในไดรเวอร์ CSI เฉพาะ

คุณสมบัติอื่นสำหรับ CSI ในเวอร์ชันอัลฟ่า - โอกาส อ้างอิงโดยตรง (เช่น โดยไม่ใช้ PV/PVC) ไปยังปริมาตร CSI ภายในข้อกำหนดเฉพาะของพ็อด นี้ ยกเลิกข้อจำกัดในการใช้ CSI เป็นที่จัดเก็บข้อมูลระยะไกลโดยเฉพาะเปิดประตูสู่โลกให้กับพวกเขา ปริมาณชั่วคราวในท้องถิ่น. สำหรับการใช้งาน (ตัวอย่างจากเอกสาร) ต้องเปิดใช้งาน CSIInlineVolume ประตูคุณลักษณะ

นอกจากนี้ยังมีความคืบหน้าใน "ภายใน" ของ Kubernetes ที่เกี่ยวข้องกับ CSI ซึ่งผู้ใช้ปลายทาง (ผู้ดูแลระบบ) ไม่สามารถมองเห็นได้ ... ปัจจุบันนักพัฒนาถูกบังคับให้สนับสนุนปลั๊กอินพื้นที่เก็บข้อมูลแต่ละตัวสองเวอร์ชัน: หนึ่ง - "ใน วิธีเก่า” ภายในโค้ดเบส K8s (ใน -tree) และอันที่สอง - ซึ่งเป็นส่วนหนึ่งของ CSI ใหม่ (อ่านเพิ่มเติมเกี่ยวกับเรื่องนี้เช่นใน ที่นี่). สิ่งนี้ทำให้เกิดความไม่สะดวกที่เข้าใจได้ซึ่งจำเป็นต้องได้รับการแก้ไขในขณะที่ CSI เองก็มีเสถียรภาพ เป็นไปไม่ได้ที่จะเลิกใช้งาน API ของปลั๊กอินภายใน (ในแผนผัง) เนื่องจาก นโยบาย Kubernetes ที่เกี่ยวข้อง.

ทั้งหมดนี้นำไปสู่ความจริงที่ว่าเวอร์ชันอัลฟ่าถึงแล้ว กระบวนการโยกย้าย รหัสปลั๊กอินภายในซึ่งใช้งานแบบอินทรีในปลั๊กอิน CSI ซึ่งทำให้ความกังวลของนักพัฒนาลดลงเหลือเพียงการรองรับปลั๊กอินเวอร์ชันเดียว และความเข้ากันได้กับ API เก่าจะยังคงอยู่ และสามารถประกาศให้ล้าสมัยได้ในสถานการณ์ปกติ คาดว่าภายใน Kubernetes (1.15) รุ่นถัดไป ปลั๊กอินผู้ให้บริการคลาวด์ทั้งหมดจะถูกย้าย การใช้งานจะได้รับสถานะเบต้า และจะเปิดใช้งานในการติดตั้ง K8 ตามค่าเริ่มต้น สำหรับรายละเอียด โปรดดู ข้อเสนอการออกแบบ. การโยกย้ายนี้ยังส่งผลให้ ความล้มเหลว จากขีดจำกัดปริมาณที่กำหนดโดยผู้ให้บริการคลาวด์บางราย (AWS, Azure, GCE, Cinder)

นอกจากนี้ ยังรองรับอุปกรณ์บล็อคด้วย CSI (CSIBlockVolume) โอนแล้ว เป็นเวอร์ชันเบต้า

โหนด/คูเบเล็ต

นำเสนอเวอร์ชันอัลฟ่า ปลายทางใหม่ ใน Kubelet ออกแบบมาสำหรับ ส่งคืนตัวชี้วัดในทรัพยากรหลัก. โดยทั่วไปแล้ว หากก่อนหน้านี้ Kubelet ได้รับสถิติเกี่ยวกับการใช้งานคอนเทนเนอร์จาก cAdvisor ตอนนี้ข้อมูลนี้มาจากสภาพแวดล้อมรันไทม์ของคอนเทนเนอร์ผ่าน CRI (Container Runtime Interface) แต่ความเข้ากันได้สำหรับการทำงานกับ Docker เวอร์ชันเก่าก็ยังคงอยู่เช่นกัน ก่อนหน้านี้ สถิติที่รวบรวมใน Kubelet ถูกส่งผ่าน REST API แต่ตอนนี้ปลายทางอยู่ที่ /metrics/resource/v1alpha1. กลยุทธ์ระยะยาวของนักพัฒนา เป็น คือการลดชุดเมตริกที่ Kubelet ให้มาน้อยที่สุด อย่างไรก็ตาม ตัวชี้วัดเหล่านี้เอง ตอนนี้พวกเขาโทรมา ไม่ใช่ "ตัวชี้วัดหลัก" แต่เป็น "ตัวชี้วัดทรัพยากร" และได้รับการอธิบายว่าเป็น "ทรัพยากรชั้นหนึ่ง เช่น cpu และหน่วยความจำ"

ความแตกต่างที่น่าสนใจมาก: แม้จะมีข้อได้เปรียบด้านประสิทธิภาพที่ชัดเจนของจุดสิ้นสุด gRPC เมื่อเปรียบเทียบกับกรณีต่างๆ ของการใช้รูปแบบ Prometheus (ดูผลลัพธ์ของการวัดประสิทธิภาพด้านล่าง)ผู้เขียนชอบรูปแบบข้อความของ Prometheus เนื่องจากความเป็นผู้นำที่ชัดเจนของระบบติดตามนี้ในชุมชน

“gRPC เข้ากันไม่ได้กับไปป์ไลน์การตรวจสอบหลักๆ ตำแหน่งข้อมูลจะมีประโยชน์สำหรับการส่งตัววัดไปยังเซิร์ฟเวอร์ตัววัดหรือส่วนประกอบการตรวจสอบที่รวมเข้ากับตัววัดโดยตรงเท่านั้น ประสิทธิภาพรูปแบบข้อความ Prometheus เมื่อใช้การแคชในเซิร์ฟเวอร์เมตริก ดีพอแล้ว เพื่อให้เราชอบ Prometheus มากกว่า gRPC เนื่องจากมีการใช้ Prometheus อย่างแพร่หลายในชุมชน เมื่อรูปแบบ OpenMetrics มีเสถียรภาพมากขึ้น เราจะสามารถเข้าถึงประสิทธิภาพของ gRPC ด้วยรูปแบบที่ใช้โปรโตได้"

Kubernetes 1.14: ภาพรวมของนวัตกรรมหลัก
หนึ่งในการทดสอบประสิทธิภาพเชิงเปรียบเทียบของการใช้รูปแบบ gRPC และ Prometheus ในตำแหน่งข้อมูล Kubelet ใหม่สำหรับตัววัด สามารถดูกราฟและรายละเอียดอื่นๆ เพิ่มเติมได้ใน KEP.

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

  • Kubelet ตอนนี้ (ครั้งเดียว) พยายามที่จะหยุด คอนเทนเนอร์อยู่ในสถานะที่ไม่รู้จักก่อนที่จะรีสตาร์ทและลบการดำเนินการ
  • เมื่อใช้งาน PodPresets ตอนนี้ไปที่คอนเทนเนอร์เริ่มต้น ถูกเพิ่ม ข้อมูลเดียวกับคอนเทนเนอร์ปกติ
  • คูเบเลต เริ่มใช้ usageNanoCores จากผู้ให้บริการสถิติ CRI และสำหรับโหนดและคอนเทนเนอร์บน Windows เพิ่ม สถิติเครือข่าย
  • ข้อมูลระบบปฏิบัติการและสถาปัตยกรรมได้รับการบันทึกไว้ในฉลากแล้ว kubernetes.io/os и kubernetes.io/arch วัตถุโหนด (ถ่ายโอนจากเบต้าเป็น GA)
  • ความสามารถในการระบุกลุ่มผู้ใช้ระบบเฉพาะสำหรับคอนเทนเนอร์ในพ็อด (RunAsGroup, ปรากฏตัวใน K8s 1.11) ขั้นสูง ก่อนเบต้า (เปิดใช้งานโดยค่าเริ่มต้น)
  • du และค้นหาใช้ใน cAdvisor ซาเมนเนนีส ในการใช้งาน Go

CLI

ใน cli-runtime และ kubectl เพิ่ม -k ตั้งค่าสถานะสำหรับการรวมเข้ากับ ปรับแต่ง (โดยวิธีการตอนนี้การพัฒนาได้ดำเนินการในพื้นที่เก็บข้อมูลแยกต่างหาก) เช่น เพื่อประมวลผลไฟล์ YAML เพิ่มเติมจากไดเร็กทอรีการปรับแต่งพิเศษ (สำหรับรายละเอียดเกี่ยวกับการใช้งาน โปรดดู KEP):

Kubernetes 1.14: ภาพรวมของนวัตกรรมหลัก
ตัวอย่างการใช้งานไฟล์อย่างง่าย การปรับแต่ง (แอปพลิเคชัน kustomize ที่ซับซ้อนยิ่งขึ้นเป็นไปได้ภายใน ซ้อนทับ)

นอกจากนี้:

  • เพิ่ม ทีมใหม่ kubectl create cronjobซึ่งมีชื่อพูดเพื่อตัวเอง
  • В kubectl logs ตอนนี้คุณสามารถ รวมกัน ธง -f (--follow สำหรับบันทึกการสตรีม) และ -l (--selector สำหรับการสืบค้นฉลาก)
  • Kubectl สอน คัดลอกไฟล์ที่เลือกโดยไวด์การ์ด
  • ให้กับทีมงาน kubectl wait เพิ่ม ธง --all เพื่อเลือกทรัพยากรทั้งหมดในเนมสเปซของประเภททรัพยากรที่ระบุ

คนอื่น ๆ

ความสามารถต่อไปนี้ได้รับสถานะเสถียร (GA):

การเปลี่ยนแปลงอื่นๆ ที่นำมาใช้ใน Kubernetes 1.14:

  • นโยบาย RBAC เริ่มต้นไม่อนุญาตการเข้าถึง API อีกต่อไป discovery и access-review ผู้ใช้ที่ไม่มีการตรวจสอบสิทธิ์ (ไม่ผ่านการรับรองความถูกต้อง).
  • การสนับสนุน CoreDNS อย่างเป็นทางการ มั่นใจ Linux เท่านั้น ดังนั้นเมื่อใช้ kubeadm เพื่อปรับใช้ (CoreDNS) ในคลัสเตอร์ โหนดจะต้องทำงานบน Linux เท่านั้น (nodeSelectors ใช้สำหรับข้อจำกัดนี้)
  • การกำหนดค่าเริ่มต้นของ CoreDNS คือตอนนี้ ใช้ ปลั๊กอินไปข้างหน้า แทนการมอบฉันทะ นอกจากนี้ใน CoreDNS เพิ่ม readinessProbe ซึ่งป้องกันการโหลดบาลานซ์บนพ็อดที่เหมาะสม (ไม่พร้อมสำหรับการบริการ)
  • ใน kubeadm บนเฟส init หรือ upload-certs, เป็นไปได้ โหลดใบรับรองที่จำเป็นในการเชื่อมต่อระนาบควบคุมใหม่กับความลับ kubeadm-certs (ใช้ flag --experimental-upload-certs).
  • มีเวอร์ชันอัลฟ่าสำหรับการติดตั้ง Windows สนับสนุน gMSA (บัญชีบริการที่จัดการกลุ่ม) - บัญชีพิเศษใน Active Directory ที่คอนเทนเนอร์สามารถใช้ได้เช่นกัน
  • สำหรับ G.C.E. เปิดใช้งาน การเข้ารหัส mTLS ระหว่าง etcd และ kube-apiserver
  • การอัปเดตในซอฟต์แวร์ที่ใช้/ขึ้นอยู่กับ: ไป 1.12.1, CSI 1.1, CoreDNS 1.3.1, รองรับ Docker 18.09 ใน kubeadm และเวอร์ชัน Docker API ที่รองรับขั้นต่ำคือ 1.26

PS

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

ที่มา: will.com

เพิ่มความคิดเห็น