ทีมพัฒนา Kubernetes เพิ่งเปิดตัว ผ่านการประกาศการเปิดตัว เวอร์ชันใหม่ "Kubernetes 1.18" ซึ่งทีมพัฒนาระบุว่าเป็นเวอร์ชัน 'พอดีและเสร็จสิ้น'
ในเวอร์ชันใหม่นี้ มีการดำเนินการที่สำคัญเพื่อปรับปรุงฟังก์ชันเบต้าและฟังก์ชันที่เสถียร เพื่อรับประกัน ประสบการณ์ผู้ใช้ที่ดีขึ้น มีความพยายามอย่างเท่าเทียมกันในการเพิ่มการพัฒนาใหม่ ๆ และคุณสมบัติใหม่ที่น่าตื่นเต้นซึ่งสัญญาว่าจะปรับปรุงประสบการณ์ของผู้ใช้ให้ดียิ่งขึ้น
สำหรับคนที่ไม่รู้จัก Kubernetes พวกเขาควรจะรู้ว่า เป็นระบบโอเพ่นซอร์สที่จะทำให้เป็นอัตโนมัติ การปรับใช้การปรับขนาดและการจัดการ แอพพลิเคชั่นคอนเทนเนอร์
มันเป็น ออกแบบโดย Google แม้ว่าการพัฒนาจะได้รับความไว้วางใจให้เข้าร่วม Open Source Cloud Computing Foundation (CNCF) ในเวลาต่อมาซึ่งในปัจจุบันได้อนุญาตให้เทคโนโลยีการจัดเรียงคอนเทนเนอร์เติบโตอย่างรวดเร็วเนื่องจากการมีส่วนร่วมของยักษ์ใหญ่ด้านเทคโนโลยี
มีอะไรใหม่ใน Kubernetes 1.18
เวอร์ชันใหม่นี้โดดเด่นในเรื่องการมีไฟล์ ความสามารถในการใช้โทเค็นบัญชีบริการ เป็นวิธีการรับรองความถูกต้องทั่วไป ตัวอย่างเช่นหากคุณต้องการให้พ็อดจัดการทรัพยากร Kubernetes อื่น ๆ เช่นการทำให้ใช้งานได้หรือบริการสามารถเชื่อมโยงกับบัญชีบริการและสร้างบทบาทที่จำเป็นและการเชื่อมโยงบทบาท
บัญชีบริการ Kubernetes (KSAs) ส่งโทเค็นเว็บ JSON (JWT) ไปยังเซิร์ฟเวอร์ API เพื่อตรวจสอบสิทธิ์ สิ่งนี้ทำให้เซิร์ฟเวอร์ API เป็นแหล่งเดียวของการพิสูจน์ตัวตน สำหรับบัญชีบริการ
Kubernetes 1.18 หน้าให้ฟังก์ชันการทำงาน นี้ อนุญาตให้เซิร์ฟเวอร์ API จัดเตรียมเอกสารการค้นพบ OpenID Connect ที่มีคีย์สาธารณะของโทเค็นนอกเหนือจากข้อมูลเมตาอื่น ๆ
การเปลี่ยนแปลงอีกอย่างที่โดดเด่นจาก Kubernetes 1.81 คือ ความสามารถในการกำหนดค่า HPA Velocity สำหรับพ็อดเฉพาะ. มีการใช้ Horizontal Pod Autoscaler (HPA)ก. เพื่อให้คลัสเตอร์ Kubernetes ตอบสนองต่อการรับส่งข้อมูลสูง / ต่ำโดยอัตโนมัติ. ด้วย HPA ผู้ใช้สามารถขอให้คอนโทรลเลอร์สร้างโมดูลเพิ่มเติมเพื่อตอบสนองต่อการเพิ่มขึ้นอย่างรวดเร็วของ CPU การวัดอื่น ๆ หรือการวัดที่แอปพลิเคชันมีให้
Kubernetes 1.18 มีภาพรวมของโปรไฟล์เพื่อเรียกใช้การกำหนดค่าต่างๆ ของผู้วางแผน โดยทั่วไปภาระงานใน Kubernetes มี XNUMX ประเภท ได้แก่ บริการระยะยาว (เช่นเว็บเซิร์ฟเวอร์ API ฯลฯ ) และงานที่ดำเนินการจนเสร็จสมบูรณ์ (รู้จักกันดีในชื่องาน)
เนื่องจากความแตกต่างที่ชัดเจนระหว่างประเภทภาระงานผู้ใช้บางรายจึงหันไปสร้างคลัสเตอร์แบบเต็มสำหรับความต้องการที่แตกต่างกัน ตัวอย่างเช่นคลัสเตอร์หนึ่งเพื่อจัดการการขุดข้อมูลและอีกคลัสเตอร์เพื่อให้บริการ API ของแอปพลิเคชัน
เหตุผลก็คือพวกเขาต้องการกระบวนการตัดสินใจที่แตกต่างกัน ตัวอย่างเช่นการตั้งค่าตัวกำหนดตารางเวลาเริ่มต้นส่งเสริมความพร้อมใช้งานสูง
ในทางกลับกันเรายังสามารถค้นหาไฟล์ ความสามารถในการกำหนดกฎการออกอากาศพ็อดในระดับคลัสเตอร์ Que แท้จริง ทำให้มั่นใจได้ว่าพ็อดจะถูกกำหนดเวลาไว้ใน Availability Zone (หากคุณใช้คลัสเตอร์แบบหลายโซน) เพื่อให้แน่ใจว่ามีความพร้อมใช้งานและการใช้ทรัพยากรสูงสุด
ฟังก์ชันนี้เปิดใช้งานข้อกำหนด topologySpreadConstraints ซึ่งระบุพื้นที่โดยการค้นหาโหนดที่มีแท็ก topologyKey เดียวกัน โหนดที่มีแท็ก TopologyKey เดียวกันอยู่ในพื้นที่เดียวกัน การกำหนดค่าคือการกระจายพ็อดอย่างเท่าเทียมกันในพื้นที่ต่างๆ อย่างไรก็ตามข้อเสียคือต้องใช้การตั้งค่านี้ที่ระดับพ็อด พ็อดที่ไม่มีการกำหนดค่าจะไม่กระจายอย่างเท่าเทียมกันในโดเมนความผิดพลาด
สุดท้าย แต่ไม่ท้ายสุด, นอกจากนี้เรายังสามารถค้นหาความสามารถในการเพิกเฉยต่อการเปลี่ยนแปลงคุณสมบัติระดับเสียง ตามค่าเริ่มต้นเมื่อติดตั้งโวลุ่มในคอนเทนเนอร์บนคลัสเตอร์ Kubernetes ไฟล์และไดเร็กทอรีทั้งหมดภายในโวลุ่มนี้จะมีคุณสมบัติเปลี่ยนเป็นค่าที่ระบุผ่าน fsGroup
ทั้งหมดนี้เพื่อให้ fsGroup อ่านและเขียนไดรฟ์ข้อมูล อย่างไรก็ตามพฤติกรรมนี้แสดงให้เห็นว่าไม่เป็นที่พึงปรารถนาในบางกรณี
เวอร์ชันใหม่ของ Kubernetes มาพร้อมกับการเปลี่ยนแปลงมากมายและเราได้กล่าวถึงสิ่งที่สำคัญที่สุดเพียงไม่กี่อย่างเท่านั้น หากคุณต้องการทราบรายการทั้งหมดคุณสามารถทำได้โดยไปที่ไฟล์ ลิงค์ต่อไปนี้