Куб-на-кубі, метакластери, стільники, розподіл ресурсів

Мал. 1. Екосистема Kubernetes у хмарі Alibaba Cloud

З 2015 року Alibaba Cloud Container Service for Kubernetes (ACK) є одним з найшвидших хмарних сервісів в Alibaba Cloud. Він обслуговує численних клієнтів, а також підтримує внутрішню інфраструктуру Alibaba та інші хмарні послуги компанії.

Як і в аналогічних контейнерних сервісах від хмарних провайдерів світового рівня, наші головні пріоритети – надійність та доступність. Тому для десятків тисяч кластерів Kubernetes створено масштабовану та глобально доступну платформу.

У цій статті ми поділимося досвідом управління великою кількістю кластерів Kubernetes на хмарній інфраструктурі та архітектурою базової платформи.

Вступ

Kubernetes став фактично стандартом для різних робочих навантажень у хмарі. Як показано на рис. 1 вгорі, все більше і більше програм Alibaba Cloud тепер працюють у кластерах Kubernetes: це програми зі збереженням стану та без (stateful/stateless), а також менеджери додатків. Управління Kubernetes завжди представляло цікаву та серйозну тему обговорення для інженерів, які займаються побудовою та обслуговуванням інфраструктури. Коли йдеться про хмарні провайдери, такі як Alibaba Cloud, на перший план виходить проблема масштабування. Як керувати кластерами Kubernetes у такому масштабі? Ми вже розповідали про найкращі практики управління величезними кластерами Kubernetes із 10 000 вузлами. Звісно, ​​це цікава проблема масштабування. Але є й інша шкала масштабу: кількість самих кластерів.

Ми обговорювали цю тему з багатьма користувачами ACK. Більшість із них вважають за краще запускати десятки, якщо не сотні, невеликих чи середніх кластерів Kubernetes. На це є розумні причини: обмеження потенційних збитків, поділ кластерів для різних команд, створення віртуальних кластерів для тестування. Якщо ACK прагне обслуговувати глобальну аудиторію за такою моделлю використання, то має надійно та ефективно керувати великою кількістю кластерів у більш ніж 20 регіонах.

Мал. 2. Проблеми управління величезною кількістю кластерів Kubernetes

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

• гетерогенність

ACK повинен підтримувати різні типи кластерів, включаючи стандартні, безсерверні, Edge, Windows та деякі інші. Різні кластери вимагають різних параметрів, компонентів та моделей хостингу. Деяким клієнтам потрібна допомога з налаштування їх специфічних випадків.

• Різний розмір кластерів

Кластери відрізняються за розміром: від пари вузлів з кількома pod'ами до десятків тисяч вузлів з тисячами pod'ів. Вимоги до ресурсів теж сильно відрізняються. Неправильне розподілення ресурсів може вплинути на продуктивність або навіть призвести до збою.

• Різні версії

Kubernetes дуже швидко розвивається. Нові версії виходять кожні кілька місяців. Клієнти завжди готові спробувати нові функції. Таким чином вони хочуть розмістити тестове навантаження на нових версіях Kubernetes, а робоче навантаження - на стабільних. Щоб задовольнити цю вимогу, ACK повинна постійно постачати клієнтам нові версії Kubernetes, одночасно підтримуючи стабільні версії.

• Відповідність вимогам безпеки

Кластери розподілені по різних регіонах. Таким чином, вони повинні відповідати різним вимогам щодо безпеки та офіційним нормам регулювання. Наприклад, кластер у Європі повинен відповідати GDPR, а фінансова хмара в Китаї має мати додаткові рівні захисту. Ці вимоги є обов'язковими до виконання, ігнорувати їх неприйнятно, оскільки це створює величезні ризики для клієнтів хмарної платформи.

Платформа ACK призначена для вирішення більшості перерахованих вище проблем. В даний час вона надійно та стабільно керує більш ніж 10 тис. кластерами Kubernetes по всьому світу. Подивимося, як вдалося цього досягти, у тому числі завдяки кільком ключовим принципам дизайну/архітектури.

Дизайн

Куб-на-кубі та стільники

На відміну від централізованої ієрархії, стільникова архітектура (cell-based architecture) зазвичай використовується для масштабування платформи межі одного дата-центру чи розширення області аварійного відновлення.

Кожен регіон у хмарі Alibaba Cloud складається з кількох зон (AZ) і зазвичай відповідає даному центру. У великому регіоні (наприклад, Хуанчжоу) часто зустрічаються тисячі клієнтських кластерів Kubernetes під керівництвом ACK.

ACK керує цими кластерами Kubernetes за допомогою самого Kubernetes, тобто у нас працює метакластер Kubernetes для управління клієнтськими кластерами Kubernetes. Така архітектура також називається "куб-на-кубі" (kube-on-kube, KoK). Архітектура KoK спрощує управління клієнтськими кластерами, оскільки розгортання кластера стає простим та детермінованим. Що ще важливіше, ми можемо повторно використовувати функції нативного Kubernetes. Наприклад, керування API-серверами через деплой, використання оператора etcd для керування кількома etcd. Така рекурсія завжди приносить особливе задоволення.

У межах одного регіону розгортається кілька метакластерів Kubernetes, залежно від кількості клієнтів. Ці метакластери ми називаємо сотами (cell). Щоб захиститись від збою цілої зони, ACK підтримує мультиактивні розгортання в одному регіоні: метакластер розподіляє компоненти майстра клієнтських кластерів Kubernetes по кількох зонах і запускає їх одночасно, тобто в мультиактивному режимі. Щоб забезпечити надійність та ефективність майстра, ACK оптимізує розміщення компонентів та гарантує, що сервер API та etcd стоять близько один до одного.

Така модель дозволяє ефективно, гнучко та надійно керувати Kubernetes.

Планування ресурсів метакластера

Як ми вже згадували, кількість метакластерів у кожному регіоні залежить від кількості клієнтів. Але коли додати новий метакластер? Це типова проблема планування ресурсів. Як правило, прийнято створювати новий, коли наявні метакластери вичерпали всі свої ресурси.

Візьмемо, наприклад, мережеві ресурси. В архітектурі KoK компоненти Kubernetes із клієнтських кластерів деплояться як pod'и у метакластері. Ми використовуємо Terway (Мал. 3) - високопродуктивний плагін, розроблений Alibaba Cloud для управління контейнерною мережею. Він надає багатий набір політик безпеки та дозволяє підключатися до віртуальних приватних хмар (VPC) клієнтів через інтерфейс Alibaba Cloud Elastic Networking Interface (ENI). Щоб ефективно розподіляти мережеві ресурси по вузлах, pod'ах та сервісах у метакластері, ми повинні ретельно відстежувати їх використання всередині метакластера з віртуальних приватних хмар. Коли мережні ресурси добігають кінця, створюється нова стільника.

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

Мал. 3. Мережева архітектура Terway

Масштабування компонентів майстра у клієнтських кластерах

У компонентів майстра різні потреби у ресурсах. Вони залежать від числа вузлів та pod'ів у кластері, кількості нестандартних контролерів/операторів, що взаємодіють з APIServer.

У ACK кожен клієнтський кластер Kubernetes відрізняється за розміром та вимогами до середовища виконання. Немає універсальної конфігурації для розміщення компонентів майстра. Якщо ми помилково встановимо низький ліміт ресурсів великому клієнту, його кластер не впорається з навантаженням. Якщо встановити консервативно високий ліміт всім кластерів, то ресурси витратяться марно.

Щоб знайти тонкий компроміс між надійністю та вартістю, ACK використовує систему типів. А саме, ми визначаємо три типи кластерів: малий, середній та великий. Кожен тип має окремий профіль розподілу ресурсів. Тип визначається на основі завантаження компонентів майстра, кількості вузлів та інших факторів. Тип кластера може змінюватися з часом. ACK постійно відстежує ці чинники і може відповідним чином підвищувати/знижувати тип. Після зміни типу кластера розподіл ресурсів оновлюється автоматично за мінімального втручання користувача.

Ми працюємо над покращенням цієї системи в частині більш дрібнозернистого масштабування та більш точного оновлення типів, щоб ці зміни відбувалися плавніше і мали більший економічний сенс.

Мал. 4. Інтелектуальне багатоступеневе перемикання типів

Еволюція клієнтських кластерів у масштабі

У попередніх розділах описано деякі аспекти керування великою кількістю кластерів Kubernetes. Однак є ще одна проблема, яку потрібно вирішити: еволюція кластерів.

Kubernetes - це "Linux" у світі хмар. Він безперервно оновлюється і стає модульнішим. Ми повинні постійно постачати нашим клієнтам нові версії, виправляти вразливості та оновлювати існуючі кластери, а також керувати великою кількістю зв'язаних компонентів (CSI, CNI, Device Plugin, Scheduler Plugin та багато інших).

Як приклад візьмемо керування компонентами Kubernetes. Для початку ми розробили централізовану систему реєстрації та управління всіма цими компонентами, що підключаються.

Мал. 5. Гнучкі та підключені компоненти

Перед тим, як рухатися далі, потрібно переконатися в успішності оновлення. І тому ми розробили систему перевірки працездатності компонентів. Перевірка виконується до та після оновлення.

Мал. 6. Попередня перевірка компонентів кластера

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

Наприклад, контролер BroadcastJob призначений для оновлення компонентів на кожній робочій машині або для перевірки вузлів на кожній машині. Завдання Broadcast запускає pod на кожному вузлі кластера, як DaemonSet. Однак DaemonSet завжди підтримує тривалу роботу pod'a, тоді як BroadcastJob згортає його. Контролер Broadcast також запускає pod'и на знову приєднаних вузлах та ініціалізує вузли з необхідними компонентами. У червні 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.
• Метрики etcd, такі як час запису диск, розмір БД, пропускна здатність зв'язків між вузлами тощо.

Збір глобальної статистики ведеться за типовою багатошаровою моделлю агрегації. Дані моніторингу кожного метакластера спочатку агрегуються в кожному регіоні, а потім відправляються на центральний сервер, який показує загальну картину. Все працює через механізм федерації. Сервер Prometheus у кожному дата-центрі збирає метрики дата-центру, а центральний сервер Prometheus відповідає за агрегування даних моніторингу. AlertManager підключається до центрального Prometheus і в разі потреби розсилає оповіщення через DingTalk, електронну пошту, SMS тощо. Візуалізація — за допомогою Grafana.

На малюнку 10 система моніторингу може бути поділена на три рівні:

• Граничний рівень

Найдальший від центру шар. Граничний сервер Prometheus працює у кожному метакластері, збираючи метрики мета- і клієнтських кластерів у межах мережного домену.

• Каскадний рівень

Функція каскадного шару Prometheus полягає у збиранні даних моніторингу з кількох регіонів. Ці сервери працюють на рівні більших географічних одиниць, таких як Китай, Азія, Європа та Америка. У міру зростання кластерів регіон він може бути розділений, і тоді сервер Prometheus каскадного рівня з'явиться у кожному новому великому регіоні. З такою стратегією можна плавно масштабуватися за необхідності.

• Центральний рівень

Центральний сервер Prometheus підключається до всіх каскадних серверів та виконує остаточну агрегацію даних. Для надійності в різних зонах піднято два центральні інстанси Prometheus, підключені до тих самих каскадних серверів.

Мал. 10. Глобальна багаторівнева архітектура моніторингу з урахуванням механізму федерації Prometheus

Резюме

Хмарні рішення на основі Kubernetes продовжують трансформувати нашу індустрію. Контейнер-сервіс Alibaba Cloud забезпечує захищений, надійний та високопродуктивний хостинг – це один із найкращих хмарних хостингів Kubernetes. Команда Alibaba Cloud твердо вірить у принципи Open Source та опенсорсної спільноти. Ми обов'язково продовжимо ділитися своїми знаннями в галузі експлуатації та управління хмарними технологіями.

Джерело: habr.com