Cube-on-cube, metaclusters, honeycombs, การกระจายทรัพยากร

ข้าว. 1. ระบบนิเวศ Kubernetes บน Alibaba Cloud

С 2015 года Alibaba Cloud Container Service for Kubernetes (ACK) является одним из самых быстрорастущих облачных сервисов в Alibaba Cloud. Он обслуживает многочисленных клиентов, а также поддерживает внутреннюю инфраструктуру Alibaba и другие облачные сервисы компании.

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

ในบทความนี้ เราจะแบ่งปันประสบการณ์ของเราในการจัดการคลัสเตอร์ Kubernetes จำนวนมากบนโครงสร้างพื้นฐานระบบคลาวด์ รวมถึงสถาปัตยกรรมของแพลตฟอร์มพื้นฐาน

การเข้า

Kubernetes ได้กลายเป็นมาตรฐานที่แท้จริงสำหรับปริมาณงานที่หลากหลายในระบบคลาวด์ ดังแสดงในรูป ตามข้อ 1 ข้างต้น ขณะนี้แอปพลิเคชันของ Alibaba Cloud ทำงานบนคลัสเตอร์ Kubernetes มากขึ้นเรื่อยๆ: แอปพลิเคชันแบบเก็บสถานะและไร้สถานะ รวมถึงตัวจัดการแอปพลิเคชัน การจัดการ Kubernetes เป็นหัวข้อสนทนาที่น่าสนใจและจริงจังสำหรับวิศวกรที่สร้างและบำรุงรักษาโครงสร้างพื้นฐานมาโดยตลอด เมื่อพูดถึงผู้ให้บริการคลาวด์อย่าง Alibaba Cloud ปัญหาเรื่องการปรับขนาดจะต้องมาก่อน จะจัดการคลัสเตอร์ Kubernetes ในระดับนี้ได้อย่างไร เราได้ครอบคลุมแนวทางปฏิบัติที่ดีที่สุดในการจัดการคลัสเตอร์ Kubernetes ขนาดใหญ่ 10 โหนดแล้ว แน่นอนว่านี่เป็นปัญหาการปรับขนาดที่น่าสนใจ แต่มีอีกระดับหนึ่ง: ปริมาณ самих кластеров.

เราได้หารือเกี่ยวกับหัวข้อนี้กับผู้ใช้ ACK จำนวนมาก ส่วนใหญ่เลือกที่จะใช้งานคลัสเตอร์ Kubernetes ขนาดเล็กหรือขนาดกลางหลายสิบหรือหลายร้อยคลัสเตอร์ มีเหตุผลที่ดีสำหรับสิ่งนี้: การจำกัดความเสียหายที่อาจเกิดขึ้น การแยกคลัสเตอร์สำหรับทีมต่างๆ การสร้างคลัสเตอร์เสมือนสำหรับการทดสอบ หาก ACK ตั้งเป้าที่จะให้บริการผู้ชมทั่วโลกด้วยรูปแบบการใช้งานนี้ ACK จะต้องจัดการคลัสเตอร์จำนวนมากได้อย่างน่าเชื่อถือและมีประสิทธิภาพในมากกว่า 20 ภูมิภาค

ข้าว. 2. ปัญหาในการจัดการคลัสเตอร์ Kubernetes จำนวนมาก

Каковы основные проблемы управления кластерами в таком масштабе? Как показано на рисунке, необходимо разобраться с четырьмя проблемами:

• ความหลากหลาย

ACK ควรสนับสนุนคลัสเตอร์ประเภทต่างๆ รวมถึงคลัสเตอร์มาตรฐาน ไร้เซิร์ฟเวอร์ Edge Windows และอื่นๆ อีกมากมาย คลัสเตอร์ที่ต่างกันต้องการตัวเลือก ส่วนประกอบ และโมเดลการโฮสต์ที่แตกต่างกัน ลูกค้าบางรายต้องการความช่วยเหลือในการปรับแต่งสำหรับกรณีเฉพาะของตน

• ขนาดคลัสเตอร์ต่างๆ

คลัสเตอร์มีขนาดแตกต่างกันไป: จากโหนดสองสามโหนดที่มีหลายพ็อดไปจนถึงโหนดนับหมื่นที่มีพ็อดนับพัน ความต้องการทรัพยากรก็แตกต่างกันมากเช่นกัน การจัดสรรทรัพยากรที่ไม่เหมาะสมอาจส่งผลต่อประสิทธิภาพการทำงานหรือแม้กระทั่งทำให้เกิดความล้มเหลวได้

• Разные версии

Kubernetes มีการพัฒนาอย่างรวดเร็ว เวอร์ชันใหม่จะออกทุกๆ สองสามเดือน ลูกค้ายินดีลองใช้คุณสมบัติใหม่ๆ อยู่เสมอ ดังนั้นพวกเขาต้องการวางโหลดทดสอบบน Kubernetes เวอร์ชันใหม่และโหลดจริงบนเวอร์ชันเสถียร เพื่อให้เป็นไปตามข้อกำหนดนี้ ACK จะต้องส่งมอบ Kubernetes เวอร์ชันใหม่ให้กับลูกค้าอย่างต่อเนื่องโดยยังคงรักษาเวอร์ชันที่เสถียรไว้

• การปฏิบัติตามข้อกำหนดด้านความปลอดภัย

Кластеры распределены по разным регионам. Таким образом, они должны соответствовать различным требованиям к безопасности и официальным нормам регулирования. Например, кластер в Европе должен соответствовать GDPR, а у финансового облака в Китае должны быть дополнительные уровни защиты. Эти требования обязательны к выполнению, игнорировать их неприемлемо, поскольку это создаёт огромные риски для клиентов облачной платформы.

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

ออกแบบ

Куб-на-кубе и соты

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

แต่ละภูมิภาคใน Alibaba Cloud ประกอบด้วยหลายโซน (AZ) และมักจะสอดคล้องกับศูนย์ข้อมูลเฉพาะ ในภูมิภาคขนาดใหญ่ (เช่น หวงโจว) มักจะมีคลัสเตอร์ไคลเอนต์ Kubernetes นับพันที่ใช้ ACK

ACK จัดการคลัสเตอร์ Kubernetes เหล่านี้โดยใช้ Kubernetes เอง ซึ่งหมายความว่าเรามี Metacluster ของ Kubernetes ที่ทำงานอยู่เพื่อจัดการคลัสเตอร์ Kubernetes ของไคลเอ็นต์ สถาปัตยกรรมนี้เรียกอีกอย่างว่า "kube-on-kube" (KoK) สถาปัตยกรรม KoK ทำให้การจัดการคลัสเตอร์ไคลเอนต์ง่ายขึ้นเนื่องจากการปรับใช้คลัสเตอร์นั้นง่ายและกำหนดได้ ที่สำคัญกว่านั้นคือเราสามารถนำคุณลักษณะดั้งเดิมของ Kubernetes มาใช้ซ้ำได้ ตัวอย่างเช่น การจัดการเซิร์ฟเวอร์ API ผ่านการปรับใช้ โดยใช้ตัวดำเนินการ ฯลฯ เพื่อจัดการ ฯลฯ หลายรายการ การเรียกซ้ำดังกล่าวนำมาซึ่งความสุขเป็นพิเศษเสมอ

Metaclusters ของ Kubernetes หลายตัวถูกปรับใช้ภายในภูมิภาคเดียว ขึ้นอยู่กับจำนวนไคลเอ็นต์ เราเรียกเซลล์เมตาคลัสเตอร์เหล่านี้ เพื่อป้องกันความล้มเหลวของทั้งโซน ACK รองรับการปรับใช้แบบหลายแอ็คทีฟในภูมิภาคเดียว: metacluster จะกระจายส่วนประกอบหลักของคลัสเตอร์ไคลเอ็นต์ Kubernetes ไปยังหลายโซนและรันพร้อมกัน กล่าวคือ ในโหมดมัลติแอ็กทีฟ เพื่อให้มั่นใจในความน่าเชื่อถือและประสิทธิภาพของต้นแบบ ACK จะปรับตำแหน่งของส่วนประกอบให้เหมาะสมและรับรองว่าเซิร์ฟเวอร์ API และอื่นๆ อยู่ใกล้กัน

Такая модель позволяет эффективно, гибко и надёжно управлять Kubernetes.

การวางแผนทรัพยากร Metacluster

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

ลองใช้ทรัพยากรเครือข่ายกัน ในสถาปัตยกรรม KoK คอมโพเนนต์ Kubernetes จากคลัสเตอร์ไคลเอ็นต์จะถูกปรับใช้เป็นพ็อดในเมตาคลัสเตอร์ เราใช้ เทอร์เวย์ (рис. 3) — высокопроизводительный плагин, разработанный Alibaba Cloud для управления контейнерной сетью. Он предоставляет богатый набор политик безопасности и позволяет подключаться к виртуальным частным облакам (VPC) клиентов через интерфейс Alibaba Cloud Elastic Networking Interface (ENI). Чтобы эффективно распределять сетевые ресурсы по узлам, pod’ам и сервисам в метакластере, мы должны тщательно отслеживать их использование внутри метакластера из виртуальных частных облаков. Когда сетевые ресурсы подходят к концу, создаётся новая сота.

Для определения оптимального количества клиентских кластеров в каждом метакластере мы также учитываем свои затраты, требования к плотности, квоту ресурсов, требования к надёжности и статистические данные. Решение о создании нового метакластера принимается на основании всей этой информации. Обратите внимание, что маленькие кластеры в будущем могут сильно расшириться, поэтому расход ресурсов растёт даже при неизменном количестве кластеров. Обычно мы оставляем достаточно свободного пространства для роста каждого кластера.

ข้าว. 3. สถาปัตยกรรมเครือข่ายเทอร์เวย์

การปรับขนาดส่วนประกอบของวิซาร์ดทั่วทั้งคลัสเตอร์ไคลเอ็นต์

ส่วนประกอบตัวช่วยสร้างมีความต้องการทรัพยากรที่แตกต่างกัน ขึ้นอยู่กับจำนวนโหนดและพ็อดในคลัสเตอร์ จำนวนตัวควบคุม/ตัวดำเนินการที่ไม่ได้มาตรฐานที่โต้ตอบกับ APIServer

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

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

เรากำลังดำเนินการปรับปรุงระบบนี้ด้วยการปรับขนาดที่ละเอียดยิ่งขึ้นและการอัปเดตประเภทที่แม่นยำยิ่งขึ้น เพื่อให้การเปลี่ยนแปลงเหล่านี้เกิดขึ้นได้อย่างราบรื่นยิ่งขึ้น และสมเหตุสมผลมากขึ้น

Рис. 4. Интеллектуальное многоступенчатое переключение типов

วิวัฒนาการของกลุ่มลูกค้าในวงกว้าง

ส่วนก่อนหน้านี้ครอบคลุมบางแง่มุมของการจัดการคลัสเตอร์ Kubernetes จำนวนมาก อย่างไรก็ตาม ยังมีอีกปัญหาหนึ่งที่ต้องแก้ไข นั่นก็คือ วิวัฒนาการของกลุ่ม

Kubernetes — это «Linux» в мире облаков. Он непрерывно обновляется и становится более модульным. Мы должны постоянно поставлять нашим клиентам новые версии, исправлять уязвимости и обновлять существующие кластеры, а также управлять большим количеством связанных компонентов (CSI, CNI, Device Plugin, Scheduler Plugin и многие другие).

В качестве примера возьмём управление компонентами Kubernetes. Для начала мы разработали централизованную систему регистрации и управления всеми этими подключаемыми компонентами.

ข้าว. 5. ส่วนประกอบที่ยืดหยุ่นและเสียบได้

ก่อนที่จะดำเนินการต่อ คุณต้องตรวจสอบให้แน่ใจว่าการอัปเดตสำเร็จแล้ว ในการทำเช่นนี้ เราได้พัฒนาระบบสำหรับตรวจสอบการทำงานของส่วนประกอบต่างๆ การตรวจสอบจะดำเนินการก่อนและหลังการอัพเดต

Рис. 6. Предварительная проверка компонентов кластера

Для быстрого и надёжного обновления этих компонентов работает система непрерывного развёртывания с поддержкой частичного продвижения (grayscale), пауз и других функций. Стандартные контроллеры Kubernetes недостаточно хорошо подходят для такого использования. Поэтому для управления компонентами кластера мы разработали набор специализированных контроллеров, включая плагин и вспомогательный модуль управления (sidecar management).

ตัวอย่างเช่น ตัวควบคุม BroadcastJob ได้รับการออกแบบมาเพื่ออัปเดตส่วนประกอบในเครื่องของผู้ปฏิบัติงานแต่ละเครื่องหรือตรวจสอบโหนดในแต่ละเครื่อง งาน Broadcast จะรันพ็อดบนแต่ละโหนดในคลัสเตอร์ เช่นเดียวกับ DaemonSet อย่างไรก็ตาม DaemonSet จะทำให้พ็อดทำงานเป็นเวลานานเสมอ ในขณะที่ BroadcastJob จะยุบพ็อดลง ตัวควบคุมการออกอากาศยังเปิดตัวพ็อดบนโหนดที่เพิ่งเข้าร่วมและเริ่มต้นโหนดด้วยส่วนประกอบที่จำเป็น ในเดือนมิถุนายน 2019 เราได้เปิดซอร์สโค้ดของกลไกอัตโนมัติ OpenKruise ซึ่งเราใช้เองภายในบริษัท

ข้าว. 7. OpenKurise จัดระเบียบการดำเนินการของงาน Broadcast บนโหนดทั้งหมด

Чтобы помочь клиентам в выборе правильных конфигураций кластеров, мы также предоставляем набор предопределённых профилей, включая профили Serverless, Edge, Windows и Bare Metal. Поскольку ландшафт расширяется, а потребности наших клиентов растут, мы добавим больше профилей, чтобы упростить утомительный процесс настройки.

ข้าว. 8. โปรไฟล์คลัสเตอร์ขั้นสูงและยืดหยุ่นสำหรับสถานการณ์ต่างๆ

ความสามารถในการสังเกตการณ์ทั่วโลกทั่วทั้งศูนย์ข้อมูล

Как показано ниже на рис. 9, облачная служба Alibaba Cloud Container развёрнута в двадцати регионах мира. Учитывая такой масштаб, одна из ключевых задач ACK заключается в том, чтобы легко отслеживать состояние запущенных кластеров: если клиентский кластер столкнётся с проблемой, мы сможем быстро отреагировать на ситуацию. Другими словами, нужно придумать решение, которое позволит эффективно и безопасно собирать статистику в реальном времени с клиентских кластеров во всех регионах — и визуально представлять результаты.

Рис. 9. Глобальное развёртывание службы Alibaba Cloud Container в двадцати регионах

Как и во многих системах мониторинга Kubernetes, у нас в качестве основного инструмента работает Prometheus. Для каждого метакластера агенты Prometheus собирают следующие показатели:

• Метрики ОС, такие как ресурсы узла (процессор, память, диск и т. д.) и пропускная способность сети.
• Метрики для системы управления метакластерами и клиентскими кластерами, такие как kube-apiserver, kube-controller-manager и kube-scheduler.
• เมตริกจาก kubernetes-state-metrics และ cadvisor
• ตัวชี้วัด ฯลฯ เช่น เวลาในการเขียนดิสก์ ขนาดฐานข้อมูล ปริมาณงานของการเชื่อมโยงระหว่างโหนด ฯลฯ

สถิติทั่วโลกจะถูกรวบรวมโดยใช้แบบจำลองการรวมหลายชั้นทั่วไป การตรวจสอบข้อมูลจากแต่ละเมตาคลัสเตอร์จะถูกรวบรวมในแต่ละภูมิภาคก่อน จากนั้นจึงส่งไปยังเซิร์ฟเวอร์กลางที่แสดงภาพรวม ทุกอย่างทำงานผ่านกลไกสหพันธ์ เซิร์ฟเวอร์ Prometheus ในศูนย์ข้อมูลแต่ละแห่งจะรวบรวมตัวชี้วัดจากศูนย์ข้อมูลนั้น และเซิร์ฟเวอร์ Prometheus ส่วนกลางจะรับผิดชอบในการรวบรวมข้อมูลการตรวจสอบ AlertManager เชื่อมต่อกับ Prometheus ส่วนกลาง และส่งการแจ้งเตือนตามต้องการผ่าน DingTalk, อีเมล, SMS ฯลฯ การแสดงภาพ - การใช้ Grafana

ในรูปที่ 10 ระบบติดตามสามารถแบ่งออกได้เป็น XNUMX ระดับ:

• ระดับขอบเขต

ชั้นที่อยู่ไกลจากศูนย์กลางมากที่สุด Prometheus Edge Server ทำงานในแต่ละเมตาคลัสเตอร์ โดยรวบรวมตัวชี้วัดจากเมตาและคลัสเตอร์ไคลเอนต์ภายในโดเมนเครือข่ายเดียวกัน

• ระดับน้ำตก

หน้าที่ของเลเยอร์ Prometheus cascade คือการรวบรวมข้อมูลการตรวจสอบจากหลายภูมิภาค เซิร์ฟเวอร์เหล่านี้ทำงานในระดับหน่วยทางภูมิศาสตร์ที่ใหญ่กว่า เช่น จีน เอเชีย ยุโรป และอเมริกา เมื่อคลัสเตอร์เติบโตขึ้น ภูมิภาคก็สามารถแบ่งออกได้ จากนั้นเซิร์ฟเวอร์ Prometheus ระดับเรียงซ้อนจะปรากฏขึ้นในแต่ละภูมิภาคขนาดใหญ่ใหม่ ด้วยกลยุทธ์นี้ คุณสามารถปรับขนาดได้อย่างราบรื่นตามต้องการ

• ระดับกลาง

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

ข้าว. 10. สถาปัตยกรรมการตรวจสอบหลายระดับทั่วโลกตามกลไกสหพันธรัฐ Prometheus

สรุป

Облачные решения на основе Kubernetes продолжают трансформировать нашу индустрию. Контейнер-сервис Alibaba Cloud обеспечивает защищённый, надёжный и высокопроизводительный хостинг — это один из лучших облачных хостингов Kubernetes. Команда Alibaba Cloud твёрдо верит в принципы Open Source и опенсорсного сообщества. Мы обязательно продолжим делиться своими знаниями в области эксплуатации и управления облачными технологиями.

ที่มา: will.com