ขอแนะนำ Kubernetes CCM (Cloud Controller Manager) สำหรับ Yandex.Cloud

ต่อจากล่าสุดนี้ การเปิดตัวไดรเวอร์ CSI สำหรับ Yandex.Cloud เรากำลังเผยแพร่โครงการโอเพ่นซอร์สอื่นสำหรับคลาวด์นี้ - ผู้จัดการตัวควบคุมคลาวด์. CCM จำเป็นไม่เพียงแต่สำหรับคลัสเตอร์โดยรวมเท่านั้น แต่ยังรวมถึงไดรเวอร์ CSI ด้วย รายละเอียดเกี่ยวกับวัตถุประสงค์และคุณลักษณะการใช้งานบางอย่างอยู่ระหว่างการปรับปรุง

การแนะนำ

ทำไมเป็นเช่นนี้?

แรงจูงใจที่กระตุ้นให้เราพัฒนา CCM สำหรับ Yandex.Cloud ตรงกับที่อธิบายไว้แล้วอย่างสมบูรณ์ ประกาศ คนขับรถซีเอสไอ เราดูแลรักษาคลัสเตอร์ Kubernetes จำนวนมากจากผู้ให้บริการระบบคลาวด์หลายราย ซึ่งเราใช้เครื่องมือเดียว มันใช้สิ่งอำนวยความสะดวกมากมาย “เลี่ยง” โซลูชั่นที่ได้รับการจัดการของผู้ให้บริการเหล่านี้ ใช่ เรามีกรณีและความต้องการที่ค่อนข้างเฉพาะเจาะจง แต่การพัฒนาที่สร้างขึ้นเนื่องจากสิ่งเหล่านี้อาจเป็นประโยชน์กับผู้ใช้รายอื่น

CCM คืออะไรกันแน่?

โดยปกติแล้ว เราจะเตรียมสภาพแวดล้อมรอบตัวเราสำหรับคลัสเตอร์ ข้างนอก - เช่น การใช้ Terraform แต่บางครั้งก็จำเป็นต้องจัดการสภาพแวดล้อมคลาวด์รอบตัวเรา จากคลัสเตอร์. ความเป็นไปได้นี้มีให้และเป็นสิ่งที่ถูกนำไปใช้ CCM.

โดยเฉพาะอย่างยิ่ง Cloud Controller Manager มีการโต้ตอบห้าประเภทหลัก:

1. อินสแตนซ์ – ใช้ความสัมพันธ์ 1:1 ระหว่างวัตถุโหนดใน Kubernetes (Node) และเครื่องเสมือนในผู้ให้บริการคลาวด์ เพื่อสิ่งนี้ เรา:
   • กรอกข้อมูลในฟิลด์ spec.providerID ในวัตถุ Node. ตัวอย่างเช่น สำหรับ OpenStack CCM ฟิลด์นี้จะมีรูปแบบดังต่อไปนี้: openstack:///d58a78bf-21b0-4682-9dc6-2132406d2bb0. คุณสามารถดูชื่อของผู้ให้บริการคลาวด์และ UUID ที่ไม่ซ้ำกันของเซิร์ฟเวอร์ (เครื่องเสมือนใน OpenStack) ของออบเจ็กต์
   • เสริม nodeInfo ในวัตถุ Node ข้อมูลเกี่ยวกับเครื่องเสมือน ตัวอย่างเช่น เราระบุประเภทอินสแตนซ์ใน AWS;
   • เราตรวจสอบการมีอยู่ของเครื่องเสมือนในระบบคลาวด์ เช่น ถ้าเป็นวัตถุ Node เข้าสู่รัฐ NotReadyคุณสามารถตรวจสอบได้ว่ามีเครื่องเสมือนอยู่ในผู้ให้บริการคลาวด์หรือไม่โดย providerID. หากไม่มีอยู่ ให้ลบออบเจ็กต์ Nodeซึ่งถ้าไม่เช่นนั้นก็จะคงอยู่ในกระจุกตลอดไป
2. โซน – ตั้งค่าโดเมนความล้มเหลวสำหรับออบเจ็กต์ Nodeเพื่อให้ผู้กำหนดเวลาสามารถเลือกโหนดสำหรับ Pod ตามภูมิภาคและโซนในผู้ให้บริการคลาวด์
3. โหลดบาลานเซอร์ – เมื่อสร้างวัตถุ Service มีประเภท LoadBalancer สร้างบาลานเซอร์ชนิดหนึ่งที่จะกำหนดเส้นทางการรับส่งข้อมูลจากภายนอกไปยังโหนดคลัสเตอร์ ตัวอย่างเช่นใน Yandex.Cloud คุณสามารถใช้ได้ NetworkLoadBalancer и TargetGroup เพื่อวัตถุประสงค์เหล่านี้
4. เส้นทาง – สร้างเครือข่ายระหว่างโหนดเพราะว่า ตามข้อกำหนดของ Kubernetes แต่ละพ็อดต้องมีที่อยู่ IP ของตัวเองและสามารถเข้าถึงพ็อดอื่นได้ เพื่อวัตถุประสงค์เหล่านี้ คุณสามารถใช้เครือข่ายซ้อนทับ (VXLAN, GENEVE) หรือตั้งค่าตารางเส้นทางโดยตรงในเครือข่ายเสมือนของผู้ให้บริการคลาวด์:

   

5. ปริมาณ – อนุญาตการเรียงลำดับ PV แบบไดนามิกโดยใช้ PVC และ SC ในตอนแรก ฟังก์ชันนี้เป็นส่วนหนึ่งของ CCM แต่เนื่องจากความซับซ้อนอย่างมาก จึงถูกย้ายไปยังโปรเจ็กต์ที่แยกต่างหาก นั่นคือ Container Storage Interface (CSI) เราได้พูดคุยเกี่ยวกับ CSI มากกว่าหนึ่งครั้ง เขียน และดังที่กล่าวไปแล้วด้วยซ้ำ การเผยแพร่ คนขับรถซีเอสไอ

ก่อนหน้านี้ โค้ดทั้งหมดที่โต้ตอบกับคลาวด์จะอยู่ในที่เก็บ Git หลักของโปรเจ็กต์ Kubernetes ที่ k8s.io/kubernetes/pkg/cloudprovider/providersแต่พวกเขาตัดสินใจละทิ้งสิ่งนี้เนื่องจากความไม่สะดวกในการทำงานกับฐานโค้ดขนาดใหญ่ การใช้งานเก่าทั้งหมดได้ถูกย้ายไปที่ พื้นที่เก็บข้อมูลแยกต่างหาก. เพื่อความสะดวกในการสนับสนุนและการพัฒนาเพิ่มเติม ส่วนประกอบทั่วไปทั้งหมดก็ถูกย้ายไปที่ พื้นที่เก็บข้อมูลแยกต่างหาก.

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

หากต้องการเขียนการใช้งาน CCM ของคุณเอง ก็เพียงพอที่จะนำไปใช้ อินเทอร์เฟซ Go ที่จำเป็น.

И นี่คือสิ่งที่เราได้.

การดำเนินงาน

มาถึงเรื่องนี้ได้ยังไง.

เราเริ่มพัฒนา (หรือค่อนข้างจะใช้) ด้วย พร้อม(!) CCM สำหรับ Yandex.Cloud เมื่อปีที่แล้ว

อย่างไรก็ตาม ในการนำไปใช้งานนี้ เราขาดหายไป:

• การรับรองความถูกต้องผ่านโทเค็น JWT IAM
• การสนับสนุนตัวควบคุมบริการ

ตามข้อตกลงกับผู้เขียน (ดีลิซิน) ใน Telegram เราได้แยก yandex-cloud-controller-manager และเพิ่มฟังก์ชันที่ขาดหายไป

คุณสมบัติหลัก

ปัจจุบัน CCM รองรับอินเทอร์เฟซต่อไปนี้:

• อินสแตนซ์;
• โซน;
• โหลดบาลานเซอร์.

ในอนาคต เมื่อ Yandex.Cloud เริ่มทำงานด้วยความสามารถ VPC ขั้นสูง เราจะเพิ่มอินเทอร์เฟซ เส้นทาง.

LoadBalancer เป็นความท้าทายหลัก

ในตอนแรก เราได้พยายามเช่นเดียวกับการใช้งาน CCM อื่นๆ เพื่อสร้างคู่ของ LoadBalancer и TargetGroup แต่ละ Service มีประเภท LoadBalancer. อย่างไรก็ตาม Yandex.Cloud ค้นพบข้อจำกัดที่น่าสนใจประการหนึ่ง นั่นคือ คุณไม่สามารถใช้งานได้ TargetGroups ด้วยการตัดกัน Targets (คู่ SubnetID - IpAddress).

ดังนั้นภายใน CCM ที่สร้างขึ้น ตัวควบคุมจึงถูกเปิดใช้งาน ซึ่งเมื่อวัตถุเปลี่ยนแปลง Node รวบรวมข้อมูลเกี่ยวกับอินเทอร์เฟซทั้งหมดบนเครื่องเสมือนแต่ละเครื่อง จัดกลุ่มตามที่เป็นของบางเครื่อง NetworkID, สร้างสรรค์โดย TargetGroup บน NetworkIDและยังติดตามความเกี่ยวข้องอีกด้วย ต่อมาเมื่อมีการสร้างวัตถุ Service มีประเภท LoadBalanacer เราเพียงแค่แนบไฟล์ที่สร้างไว้ล่วงหน้า TargetGroup ใหม่ NetworkLoadBalanacer'เช้า.

จะเริ่มใช้งานได้อย่างไร?

CCM รองรับ Kubernetes เวอร์ชัน 1.15 ขึ้นไป ในคลัสเตอร์ เพื่อให้ทำงานได้ จำเป็นต้องมีแฟล็ก --cloud-provider=external ถูกตั้งค่าเป็น true สำหรับ kube-apiserver, kube-controller-manager, kube-scheduler และ kubelets ทั้งหมด

ขั้นตอนที่จำเป็นทั้งหมดสำหรับการติดตั้งนั้นมีอธิบายไว้ใน README. การติดตั้งเริ่มต้นที่การสร้างอ็อบเจ็กต์ใน Kubernetes จากไฟล์ Manifest

หากต้องการใช้ CCM คุณจะต้องมี:

• ระบุ ในรายการตัวระบุไดเรกทอรี (folder-id) ยานเดกซ์.คลาวด์;
• บัญชีบริการสำหรับการโต้ตอบกับ Yandex.Cloud API ในแถลงการณ์ Secret จำเป็น โอนคีย์ที่ได้รับอนุญาต จากบัญชีบริการ ในเอกสารประกอบ อธิบายไว้, วิธีสร้างบัญชีบริการและรับกุญแจ

เรายินดีที่จะรับข้อเสนอแนะของคุณและ ปัญหาใหม่หากคุณพบปัญหาใดๆ!

ผลของการ

เราใช้ CCM ที่นำไปใช้แล้วในคลัสเตอร์ Kubernetes ห้าคลัสเตอร์ในช่วงสองสัปดาห์ที่ผ่านมา และวางแผนที่จะขยายจำนวนเป็น 20 คลัสเตอร์ในเดือนหน้า ขณะนี้เราไม่แนะนำให้ใช้ CCM สำหรับการติดตั้ง K8 ขนาดใหญ่และสำคัญ

เช่นเดียวกับในกรณีของ CSI เรายินดีหากนักพัฒนา Yandex พัฒนาและสนับสนุนโครงการนี้ - เราพร้อมที่จะถ่ายโอนพื้นที่เก็บข้อมูลตามคำขอของพวกเขาเพื่อจัดการกับงานที่เกี่ยวข้องกับเรามากขึ้น

PS

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

• «ประสบการณ์ของเราในการพัฒนาไดรเวอร์ CSI ใน Kubernetes สำหรับ Yandex.Cloud";
• «การเตรียมคลัสเตอร์ Kubernetes ง่ายและสะดวกหรือไม่ ประกาศตัวดำเนินการ addon";
• «การขยายและการเสริม Kubernetes (ตรวจสอบและรายงานวิดีโอ)'

ที่มา: will.com