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

Рис. 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