Куб на кубе, метакластеры, соты, распределение ресурсов 
Рис.
1. Косистема Kubernetes в облаке Alibaba С 2015 года сервис Alibaba Cloud Container Service для Kubernetes (ACK) является одним из самых быстрорастущих облачных сервисов в Alibaba Cloud. Он обслуживает многочисленных клиентов, а также поддерживает внутреннюю инфраструктуру Alibaba и другие облачные сервисы компании.
Как и в случае с аналогичными контейнерными услугами от облачных провайдеров мирового класса, нашими главными приоритетами являются надежность и доступность.
Таким образом, создана масштабируемая и глобально доступная платформа для десятков тысяч кластеров Kubernetes. В этой статье мы поделимся опытом управления большим количеством кластеров Kubernetes в облачной инфраструктуре, а также архитектурой базовой платформы.
Введение Kubernetes стал фактическим стандартом для различных рабочих нагрузок в облаке.
Как показано на рис.
1 выше, все больше и больше приложений Alibaba Cloud теперь работают в кластерах Kubernetes: приложения с сохранением и без сохранения состояния, а также менеджеры приложений.
Управление Kubernetes всегда было интересной и серьезной темой для обсуждения инженеров, создающих и обслуживающих инфраструктуру.
Когда речь идет о таких облачных провайдерах, как Alibaba Cloud, вопрос масштабирования выходит на первый план.
Как управлять кластерами Kubernetes в таком масштабе? Мы уже рассмотрели лучшие практики управления огромными кластерами Kubernetes из 10 000 узлов.
Конечно, это интересная проблема масштабирования.
Но есть и другой масштаб: количество сами кластеры .
Мы обсуждали эту тему со многими пользователями ACK. Большинство из них предпочитают запускать десятки, если не сотни, небольших или средних кластеров Kubernetes. Для этого есть веские причины: ограничение потенциального ущерба, разделение кластеров для разных команд, создание виртуальных кластеров для тестирования.
Если ACK стремится обслуживать глобальную аудиторию с помощью этой модели использования, она должна надежно и эффективно управлять большим количеством кластеров в более чем 20 регионах.
Рис.
2. Проблемы управления огромным количеством кластеров Kubernetes Каковы основные проблемы управления кластерами такого масштаба? Как показано на рисунке, необходимо решить четыре проблемы:
- Неоднородность
Разным кластерам требуются разные опции, компоненты и модели хостинга.
Некоторым клиентам требуется помощь в настройке для их конкретных случаев.
- Различные размеры кластеров
Требования к ресурсам также сильно различаются.
Неправильное распределение ресурсов может повлиять на производительность или даже вызвать сбой.
- Различные версии
Новые версии выходят каждые несколько месяцев.
Клиенты всегда готовы попробовать новые функции.
Поэтому они хотят разместить тестовую нагрузку на новых версиях Kubernetes, а производственную нагрузку — на стабильных.
Чтобы соответствовать этому требованию, ACK должна постоянно предоставлять клиентам новые версии Kubernetes, сохраняя при этом стабильные версии.
- Соответствие требованиям безопасности
Таким образом, они должны соответствовать различным требованиям безопасности и официальным нормам.
Например, кластер в Европе должен соответствовать требованиям GDPR, а финансовое облако в Китае должно иметь дополнительные уровни защиты.
Эти требования являются обязательными и игнорировать их недопустимо, так как это создает огромные риски для клиентов облачной платформы.
Платформа ACK предназначена для решения большинства вышеперечисленных проблем.
На данный момент он надежно и стабильно управляет более чем 10 тысячами кластеров Kubernetes по всему миру.
Давайте посмотрим, как этого удалось добиться, в том числе с помощью нескольких ключевых принципов проектирования/архитектуры.
Дизайн
Куб на кубе и соты
В отличие от централизованной иерархии, ячеистая архитектура обычно используется для масштабирования платформы за пределы одного центра обработки данных или для расширения объема аварийного восстановления.Каждый регион в Alibaba Cloud состоит из нескольких зон (AZ) и обычно соответствует определенному дата-центру.
В большом регионе (например, Хуанчжоу) часто существуют тысячи клиентских кластеров Kubernetes, использующих ACK. ACK управляет этими кластерами Kubernetes, используя сам Kubernetes. Это означает, что у нас есть метакластер Kubernetes, работающий для управления клиентскими кластерами Kubernetes. Эту архитектуру еще называют «кубе-на-кубе» (КоК).
Архитектура KoK упрощает управление клиентскими кластерами, поскольку развертывание кластера является простым и детерминированным.
Что еще более важно, мы можем повторно использовать собственные функции Kubernetes. Например, управление серверами API посредством развертывания, использование оператора etcd для управления несколькими файлами etcd. Такая рекурсия всегда приносит особое удовольствие.
В пределах одного региона разворачивается несколько метакластеров Kubernetes в зависимости от количества клиентов.
Мы называем эти метакластеры клетками.
Для защиты от сбоя всей зоны ACK поддерживает мультиактивные развертывания в одном регионе: метакластер распределяет главные компоненты клиентского кластера Kubernetes по нескольким зонам и запускает их одновременно, то есть в мультиактивном режиме.
Чтобы обеспечить надежность и эффективность мастера, ACK оптимизирует размещение компонентов и обеспечивает близкое расположение API-сервера и etcd друг к другу.
Эта модель позволяет эффективно, гибко и надежно управлять Kubernetes.
Планирование ресурсов метакластера
Как мы уже упоминали, количество метакластеров в каждом регионе зависит от количества клиентов.Но в какой момент добавлять новый метакластер? Это типичная проблема планирования ресурсов.
Как правило, новый принято создавать тогда, когда существующие метакластеры исчерпали все свои ресурсы.
Возьмем, к примеру, сетевые ресурсы.
В архитектуре KoK компоненты Kubernetes из клиентских кластеров развертываются как модули в метакластере.
Мы используем Тервей (рис.
3) — высокопроизводительный плагин, разработанный Alibaba Cloud для управления контейнерной сетью.
Он предоставляет богатый набор политик безопасности и позволяет подключаться к виртуальным частным облакам (VPC) клиентов через интерфейс Alibaba Cloud Elastic Networking (ENI).
Чтобы эффективно распределять сетевые ресурсы между узлами, модулями и сервисами в метакластере, мы должны тщательно отслеживать их использование внутри метакластера виртуальных частных облаков.
Когда сетевые ресурсы подходят к концу, создается новая ячейка.
Для определения оптимального количества клиентских кластеров в каждом метакластере мы также учитываем наши затраты, требования к плотности, квоту ресурсов, требования к надежности и статистику.
На основании всей этой информации принимается решение о создании нового метакластера.
Обратите внимание, что небольшие кластеры могут сильно расширяться в будущем, поэтому потребление ресурсов увеличивается, даже если количество кластеров останется неизменным.
Обычно мы оставляем достаточно свободного места для роста каждого кластера.
Рис.
3. Архитектура сети Terway
Масштабирование компонентов мастера в клиентских кластерах
Компоненты мастера имеют разные потребности в ресурсах.Они зависят от количества нод и подов в кластере, количества нестандартных контроллеров/операторов, взаимодействующих с APIServer. В ACK каждый клиентский кластер Kubernetes отличается размером и требованиями к времени выполнения.
Универсальной конфигурации для размещения компонентов мастера не существует. Если мы по ошибке установим низкий лимит ресурсов для крупного клиента, то его кластер не сможет справиться с нагрузкой.
Если вы установите консервативно высокий предел для всех кластеров, ресурсы будут потрачены впустую.
Чтобы найти тонкий компромисс между надежностью и стоимостью, ACK использует систему типов.
А именно, мы определяем три типа кластеров: малые, средние и большие.
Каждый тип имеет отдельный профиль распределения ресурсов.
Тип определяется исходя из загрузки компонентов мастера, количества узлов и других факторов.
Тип кластера может меняться со временем.
ACK постоянно отслеживает эти факторы и может соответственно увеличивать или уменьшать тип.
После изменения типа кластера распределение ресурсов обновляется автоматически с минимальным вмешательством пользователя.
Мы работаем над улучшением этой системы за счет более детального масштабирования и более точного обновления типов, чтобы эти изменения происходили более плавно и имели больший экономический смысл.
Рис.
4. Интеллектуальное многоступенчатое переключение типа.
?Эволюция клиентских кластеров в масштабе
В предыдущих разделах были рассмотрены некоторые аспекты управления большим количеством кластеров Kubernetes. Однако есть еще одна проблема, которую необходимо решить: эволюция кластеров.Kubernetes — это «Linux» облачного мира.
Он постоянно обновляется и становится более модульным.
Мы должны постоянно доставлять нашим клиентам новые версии, исправлять уязвимости и обновлять существующие кластеры, а также управлять большим количеством сопутствующих компонентов (CSI, CNI, Device Plugin, Scheduler Plugin и многими другими).
Давайте возьмем в качестве примера управление компонентами Kubernetes. Для начала мы разработали централизованную систему регистрации и управления всеми этими подключенными компонентами.
Рис.
5. Гибкие и подключаемые компоненты.
Прежде чем двигаться дальше, вам необходимо убедиться, что обновление прошло успешно.
Для этого мы разработали систему проверки работоспособности компонентов.
Проверка выполняется до и после обновления.
Рис.
6. Предварительная проверка компонентов кластера Для быстрого и надежного обновления этих компонентов работает система непрерывного развертывания с поддержкой частичного продвижения (оттенки серого), пауз и других функций.
Стандартные контроллеры Kubernetes не очень подходят для этого варианта использования.
Поэтому для управления компонентами кластера мы разработали набор специализированных контроллеров, включающий плагин и вспомогательный модуль управления (управление коляской).
Например, контроллер BroadcastJob предназначен для обновления компонентов на каждой рабочей машине или проверки узлов на каждой машине.
Задание Broadcast запускает модуль на каждом узле кластера, например DaemonSet. Однако DaemonSet всегда поддерживает работу пода в течение длительного времени, а BroadcastJob его сворачивает. Контроллер Broadcast также запускает модули на вновь присоединенных узлах и инициализирует узлы необходимыми компонентами.
В июне 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 в разных зонах, подключенных к одним и тем же каскадным серверам.
Рис.
10. Глобальная многоуровневая архитектура мониторинга на основе механизма федерации Prometheus. Краткое содержание Облачные решения на базе Kubernetes продолжают трансформировать нашу отрасль.
Контейнерный сервис Alibaba Cloud обеспечивает безопасный, надежный и высокопроизводительный хостинг — это один из лучших облачных хостингов Kubernetes. Команда Alibaba Cloud твердо верит в принципы открытого исходного кода и сообщество открытого исходного кода.
Мы обязательно продолжим делиться своими знаниями в области эксплуатации и управления облачными технологиями.
Теги: #облачные сервисы #Kubernetes #Высокая производительность #DevOps #мониторинг #k8s #prometheus #itsumma #Grafana #планирование ресурсов #Alibaba #облако alibaba #cube-on-kube #KoK #Terway #OpenKruise
-
Понимание Статей: Основные Правила
19 Oct, 24 -
Я Горжусь Своей Профессией. Я Программист
19 Oct, 24
