ชุมชน Kubernetes กำลังคึกคักไปด้วยการอภิปรายเกี่ยวกับสิ่งที่เวอร์ชัน 2.0 ในอนาคตควรจะเป็นอย่างไร โดยมีนักพัฒนาและวิศวกรแบ่งปันความผิดหวังและรายการความต้องการสำหรับแพลตฟอร์มจัดการคอนเทนเนอร์ยอดนิยมนี้ แม้ว่าบทความต้นฉบับที่เสนอการเปลี่ยนแปลงจะได้รับปฏิกิริยาที่หลากหลายเนื่องจากการนำเสนอที่ไม่ชัดเจน แต่การตอบสนองของชุมชนได้จุดประกายการสนทนาที่มีความหมายเกี่ยวกับข้อจำกัดปัจจุบันและทิศทางอนาคตของ Kubernetes
สงครามภาษาการกำหนดค่า: YAML vs HCL vs อื่นๆ
หนึ่งในการถกเถียงที่ร้อนแรงที่สุดมุ่งเน้นไปที่การแทนที่ YAML ด้วย HashiCorp Configuration Language (HCL) นักพัฒนาบางคนตื่นเต้นกับความเป็นไปได้นี้ โดยเฉพาะผู้ที่ใช้ Terraform อยู่แล้วและชื่นชมความปลอดภัยของประเภทข้อมูลและโครงสร้างของ HCL อย่างไรก็ตาม ชุมชนแบ่งแยกอย่างลึกซึ้งในประเด็นนี้ นักพัฒนาหลายคนพบว่า HCL สับสนและอ่านยาก พร้อมกับความกังวลเกี่ยวกับการแก้ไขข้อผิดพลาดและการสนับสนุนการนำเข้า ข้อเสนอแนะทางเลือกรวมถึงการใช้ Protocol Buffers หรือภาษาคำจำกัดความอินเทอร์เฟซอื่นๆ ที่จะให้ผู้ใช้สามารถระบุการกำหนดค่าในภาษาโปรแกรมที่พวกเขาต้องการ
การอภิปรายเผยให้เห็นความผิดหวังที่กว้างขึ้นเกี่ยวกับการจัดการการกำหนดค่าใน Kubernetes ผู้ใช้หลายคนกำลังหาทางแก้ไขข้อจำกัดของ YAML โดยใช้เครื่องมืออย่าง Terraform เพื่อจัดการโครงสร้างพื้นฐาน Kubernetes ทั้งหมด โดยถือว่า YAML เป็นการแสดงผลระดับกลางมากกว่าสิ่งที่พวกเขาเขียนโดยตรง
คุณสมบัติที่เสนอสำหรับ Kubernetes 2.0 จากการอภิปรายของชุมชน:
- เปลี่ยนจาก YAML เป็น HCL ( HashiCorp Configuration Language ) สำหรับการกำหนดค่า
- ใช้งาน API ที่ใช้ gRPC/Protocol Buffer เพื่อการสนับสนุนหลายภาษาที่ดีขึ้น
- เปลี่ยนจาก etcd เป็น PostgreSQL หรือระบบจัดเก็บข้อมูลแบบปลั๊กอินอื่นๆ
- เพิ่มการสนับสนุน IPv6 แบบเนทีฟทั่วทั้งแพลตฟอร์ม
- รวม "ค่าเริ่มต้นที่สมเหตุสมผล" สำหรับเครือข่าย การจัดเก็บข้อมูล และการกระจายโหลด
- ปรับปรุงการจัดการแพ็กเกจเพื่อทดแทนระบบ Go templating ของ Helm
- เพิ่มการสนับสนุน WebAssembly ( WASM ) สำหรับ workload
- ใช้งานการสนับสนุน user namespace ( userns ) ที่ดีขึ้นโดยค่าเริ่มต้น
การจัดเก็บข้อมูลและความเรียบง่าย: จุดเจ็บปวดที่ยืนยาว
ธีมที่เกิดขึ้นซ้ำๆ ในการอภิปรายของชุมชนคือความซับซ้อนของ Kubernetes โดยเฉพาะในด้านการจัดเก็บข้อมูลและเครือข่าย วิศวกรหลายคนรายงานว่าแม้ว่า Kubernetes จะทำงานได้ดีสำหรับแอปพลิเคชันที่ไม่มีสถานะ แต่การจัดการการจัดเก็บข้อมูลแบบถาวรยังคงเป็นปัญหา ชุมชนแนะนำว่า Kubernetes 2.0 ควรรวมค่าเริ่มต้นที่สมเหตุสมผลสำหรับตัวจัดสมดุลโหลด เครือข่าย และการจัดเก็บข้อมูล แทนที่จะบังคับให้ผู้ใช้ต้องประกอบโซลูชันจากผู้ให้บริการต่างๆ
ตอนนี้การรัน K8S บนสิ่งอื่นนอกเหนือจากผู้ให้บริการคลาวด์และของเล่นเป็นภัยพิบัติที่รอเกิดขึ้น เว้นแต่คุณจะเป็นวิศวกรโครงสร้างพื้นฐานที่มีประสบการณ์มาก
ปัญหาความซับซ้อนนี้ขยายไปเกินกว่าการจัดเก็บข้อมูล สมาชิกชุมชนหลายคนโต้แย้งว่า Kubernetes กลายเป็นระบบที่มีฟีเจอร์มากเกินไป พยายามสนับสนุนความต้องการและความปรารถนาของทุกคนภายในแพลตฟอร์มหลัก ทำให้เกิดความซับซ้อนที่ไม่จำเป็นสำหรับผู้ใช้ส่วนใหญ่
ปัญหาที่ชุมชนพบกับ Kubernetes ปัจจุบัน:
- การจัดการพื้นที่เก็บข้อมูล: การจัดเก็บข้อมูลแบบถาวรยังคงซับซ้อนและมีปัญหา โดยเฉพาะสำหรับการติดตั้งใน on-premises
- ความซับซ้อนของการกำหนดค่า: การสร้างเทมเพลต YAML ด้วย Helm ทำให้การดีบักและการบำรุงรักษายากลำบาก
- การตั้งค่าเครือข่าย: การออกแบบเครือข่ายที่เน้น IPv4 ไม่ได้ใช้ประโยชน์จากข้อดีของ IPv6
- การจัดการแพ็กเกจ: เทมเพลต Go ของ Helm สร้างสถานการณ์ข้อผิดพลาดที่สับสน
- ความยากในการเรียนรู้: ต้องการทีมวิศวกรรมเฉพาะทาง (ประมาณ 3+ วิศวกรในราคา 1 ล้าน USD ต่อปี) สำหรับการติดตั้งใช้งานจริง
- การผูกมัดกับผู้ให้บริการคลาวด์: แนวทาง "Batteries not included" ผลักดันผู้ใช้ไปสู่บริการของผู้ให้บริการคลาวด์ที่มีราคาแพง
การปรับปรุงโครงสร้างพื้นฐานทางเทคนิค
ชุมชนได้ระบุการปรับปรุงทางเทคนิคหลายประการสำหรับ Kubernetes 2.0 ที่เป็นไปได้ ซึ่งรวมถึงการแทนที่ etcd ด้วย PostgreSQL หรือแบ็กเอนด์การจัดเก็บข้อมูลแบบปลั๊กอินอื่นๆ การใช้งาน API ที่ใช้ gRPC เพื่อการสนับสนุนหลายภาษาที่ดีขึ้น และการเพิ่มการสนับสนุน IPv6 ที่เหมาะสมตั้งแต่เริ่มต้น ผู้ใช้หลายคนยังต้องการระบบจัดการแพ็กเกจที่ดีกว่าเพื่อแทนที่ Helm ซึ่งถูกวิพากษ์วิจารณ์อย่างกว้างขวางสำหรับระบบเทมเพลต Go และความยากลำบากในการแก้ไขข้อผิดพลาด
น่าสนใจที่สมาชิกชุมชนบางคนแนะนำว่าโซลูชันไม่จำเป็นต้องเป็นการเขียนใหม่ทั้งหมด แต่เป็นเครื่องมือและการแยกส่วนที่ดีกว่าที่สร้างขึ้นบนพื้นฐาน Kubernetes ที่มีอยู่
 |
|---|
| ภาพหน้าจอจาก Artifact Hub นี้แสดงทรัพยากรที่เกี่ยวข้องกับการจัดการแพ็กเกจ เน้นย้ำถึงความจำเป็นในการมีเครื่องมือที่ดีขึ้นในการอภิปรายเรื่อง Kubernetes 20 |
ความท้าทายของความเข้ากันได้แบบย้อนหลัง
บางทีข้อมูลเชิงลึกที่เข้มงวดที่สุดจากการอภิปรายของชุมชนคือความท้าทายของความเข้ากันได้แบบย้อนหลัง ดังที่วิศวกรคนหนึ่งกล่าวไว้ การสร้างเวอร์ชัน 2.0 ที่มีความเข้ากันได้แบบย้อนหลังเพียงพอสำหรับการใช้งานแบบค่อยเป็นค่อยไป ในขณะที่ทำให้ระบบง่ายขึ้นนั้นยากมาก ความเข้ากันได้แบบย้อนหลังมักจะเพิ่มความซับซ้อนเนื่องจากระบบใหม่ต้องจัดการทั้งแนวทางเก่าและใหม่
สิ่งนี้ทำให้สมาชิกชุมชนบางคนโต้แย้งว่าสิ่งที่ Kubernetes ต้องการจริงๆ ไม่ใช่การเปลี่ยนแปลงแบบปฏิวัติ แต่เป็นประวัติการณ์ความเสถียรและความเรียบง่ายที่ยาวนานสิบปี ควรเน้นไปที่การลดความเป็นไปได้ที่ผู้ใช้จะสร้างการกำหนดค่าที่ซับซ้อนและยากต่อการบำรุงรักษา แทนที่จะเพิ่มฟีเจอร์ใหม่
ฉันทามติของชุมชนดูเหมือนจะเป็นว่าแม้ว่า Kubernetes จะมีที่ว่างสำหรับการปรับปรุง แต่การเปลี่ยนแปลงครั้งใหญ่ใดๆ ต้องสร้างสมดุลระหว่างนวัตกรรมกับความต้องการเชิงปฏิบัติของผู้ใช้ที่มีอยู่ซึ่งได้สร้างโครงสร้างพื้นฐานของพวกเขารอบระบบปัจจุบันอย่างรอบคอบ