Источник｜Сообщество открытого исходного кода KubeAdmiral
Адрес проекта: https://github.com/kubewharf/kubeadmiral
С момента открытия исходного кода в 2014 году Kubernetes стал фактическим стандартом для систем оркестрации и планирования, предоставляя разработчикам большое удобство. Поскольку все больше и больше предприятий переходят на облачную среду, масштабы глобальной облачной инфраструктуры продолжают расти. Единый кластер из версии сообщества Kubernetes на 5000 узлов больше не может соответствовать сценариям крупномасштабных приложений на уровне предприятия. Все больше компаний предпочитают использовать мультиоблачную архитектуру для удовлетворения своих потребностей. Учитывая требования снижения затрат и повышения эффективности, удаленного аварийного восстановления и изоляции окружающей среды, необходимость управления несколькими кластерами становится все более очевидной.
фон
С быстрым развитием бизнеса количество кластеров Kubernetes в рамках ByteDance также продолжает расти. Количество кластеров превышает 500, а количество копий приложений колеблется от 0 до 20 000. Самое большое приложение превышает 100 Вт.
Вначале из соображений изоляции и безопасности каждое бизнес-направление Byte имело эксклюзивные кластеры. Эти эксклюзивные кластеры создавали островки ресурсов, что в конечном итоге влияло на эластичную эффективность ресурсов. Во-первых, это выражается в необходимости поддерживать независимые буферы для каждого бизнес-направления, во-вторых, бизнес глубоко привязан к кластеру, бизнес знает о большом количестве кластеров и распределяет ресурсы для приложения также между SRE; необходимо глубоко знать бизнес и кластеры с точки зрения операционных ресурсов, что в конечном итоге приводит к медленному обороту ресурсов между различными бизнес-направлениями, низкой эффективности автоматизации и неоптимальным темпам развертывания. Поэтому нам необходимо ввести федерацию, отделить связи между приложениями и кластерами, объединить ресурсы каждого бизнес-направления, уменьшить буферы и повысить эффективность автоматизации ресурсов.
Поскольку мультиоблачные и гибридные облака все чаще становятся основными формами в отрасли, а Kubernetes становится облачной операционной системой, различные инфраструктуры дополнительно абстрагируются и стандартизируются, чтобы обеспечить более унифицированные стандартные интерфейсы для приложений. Исходя из этого, мы надеемся внедрить федерацию в качестве основы собственной облачной системы в сценариях распределенного облака, обеспечить единый вход на платформу для приложений, улучшить возможности распределения приложений по кластерам, хорошо выполнить работу по распределению и планированию приложений по кластеры и управлять несколькими облаками в собственных сценариях.
Байтовая реализация KubeFed V2
Столкнувшись с проблемами, связанными с управлением несколькими кластерами, в 2019 году инфраструктурная команда приступила к созданию кластерной федерации на базе сообщества KubeFed V2 . KubeFed V2 различает главные кластеры и кластеры-члены. Пользователи создают «объекты федерации» в главном кластере, а несколько контроллеров KubeFed распределяют ресурсы между кластерами-членами на основе объектов федерации. В объединенном объекте имеется три поля: «Шаблон» (шаблон объекта), «Размещение» (целевой кластер) и «Переопределения» (дифференциация кластера) для объявления статуса развертывания объекта. Например, вы можете создать FederatedDeployment, как показано ниже, в главном кластере для распространения развертывания:
apiVersion: types.kubefed.k8s.io/v1beta1
kind: FederatedDeployment
metadata:
name: test-deployment
namespace: test-namespace
spec:
template: # 定义 Deployment 的所有內容，可理解成 Deployment 与 Pod template 之间的关联。
metadata:
labels:
app: nginx
spec:
...
placement:
# 分发到指定的两个集群中
clusters:
- name: cluster1
- name: cluster2
overrides:
# 在cluster2中修改副本数为5
- clusterName: cluster2
clusterOverrides:
- path: spec.replicas
value: 5
Для развертываний и наборов реплик KubeFed также позволяет указывать более продвинутые стратегии распространения реплик через ReplicaSchedulingPreference (RSP). Пользователи могут настроить вес, минимальное и максимальное количество реплик каждого кластера на RSP, а контроллер RSP автоматически вычисляет размещение, переопределяет поля и обновляет FederatedDeployment или FederatedReplicaSet.
Источник изображения: https://www.kubernetes.org.cn/5702.html.
Однако в ходе внедрения мы обнаружили, что KubeFed не может соответствовать требованиям производственной среды:
- Низкое использование ресурсов. Политика планирования реплик KubeFed RSP может устанавливать только статические веса для каждого членского кластера и не может гибко реагировать на изменения в ресурсах кластера, что приводит к неравномерным уровням развертывания различных членских кластеров.
- Изменения происходят недостаточно плавно. При увеличении или уменьшении масштабирования часто возникает неравномерное распределение экземпляров, что приводит к снижению возможностей аварийного восстановления.
- Семантические ограничения планирования — только хорошая поддержка ресурсов без отслеживания состояния, недостаточная поддержка различных ресурсов, таких как службы и задания с сохранением состояния, а также плохая масштабируемость планирования.
- Стоимость доступа высока — ее необходимо распределять посредством создания федеративных объектов, она несовместима с нативными API, а пользователям и верхней платформе необходимо полностью менять свои привычки использования.
С развитием инфраструктуры Bytedance мы выдвинули более высокие требования к эффективности, масштабированию, производительности и стоимости, поскольку такие бизнес-сценарии, как услуги с отслеживанием состояния, хранилище, автономные операции и машинное обучение, все больше охватывают облачные возможности и поддерживают разнообразные возможности; Возможности межкластерной оркестрации и планирования в специализированных сценариях становятся все более важными. Поэтому в конце 2021 года мы разработали систему кластерной федерации нового поколения KubeAdmiral на базе KubeFed v2.
Эволюция архитектуры KubeAdmiral
Название KubeAdmiral происходит от слова адмирал (произносится [ˈædm(ə)rəl]), что первоначально означает командующий флотом. Добавление префикса Kube(rnetes) означает, что инструмент обладает мощными возможностями многокластерной оркестрации и планирования Kubernetes.
KubeAdmiral поддерживает собственный API Kubernetes, предоставляет богатую и масштабируемую структуру планирования, а также тщательно совершенствует алгоритм планирования и процесс распространения. Некоторые примечательные особенности подробно описаны ниже:
1. Богатые возможности мультикластерного планирования.
Планировщик является основным компонентом объединенной системы. Он отвечает за распределение ресурсов между членами кластеров. В сценарии планирования реплик он также отвечает за расчет количества реплик, которых заслуживает каждый кластер. Его логика планирования напрямую влияет на аварийное восстановление объединенных нескольких кластеров. , эффективность использования ресурсов, важные функции, такие как стабильность.
KubeFed предоставляет планировщик RSP для планирования реплик, но его настройка и масштабируемость очень ограничены, а его логическая абстракция недостаточна. Чтобы изменить его поведение, его необходимо дополнить модификацией кода. В то же время в нем отсутствует поддержка сервисов с отслеживанием состояния. , рабочие ресурсы и т. д.
KubeAdmiral представляет более богатую семантику планирования, поддерживает более гибкий выбор кластеров с помощью меток, пятен и т. д., предоставляет возможности планирования ресурсов с отслеживанием состояния и типов заданий, а также вводит такие оптимизации, как планирование с учетом зависимостей. Семантику планирования можно настроить с помощью объекта PropagationPolicy, как показано ниже:
apiVersion: core.kubeadmiral.io/v1alpha1
kind: PropagationPolicy
metadata:
name: mypolicy
namespace: default
spec:
# 提供多种集群选择方式，最终结果取交集
placement: # 手动指定集群与权重
- cluster: Cluster-01
preferences:
weight: 40
- cluster: Cluster-02
preferences:
weight: 30
- cluster: Cluster-03
preferences:
weight: 40
clusterSelector: # 类似Pod.Spec.NodeSelector，通过label过滤集群
IPv6: "true"
clusterAffinity: # 类似Pod.Spec.NodeAffinity，通过label过滤集群，语法比clusterSelector更加灵活
- matchExpressions:
- key: region
operator: In
values:
- beijing
tolerations: # 通过污点过滤集群
- key: "key1"
operator: "Equal"
value: "value1"
effect: "NoSchedule"
schedulingMode: Divide # 是否为副本数调度
stickyCluster: false # 仅在首次调度，适合有状态服务或作业类服务
maxClusters: 1 # 最多可分发到多少个子集群，适合有状态服务或作业类服务
disableFollowerScheduling: false # 是否开启依赖调度
В то же время для ресурсов, запланированных в разные кластеры, OverridePolicy можно использовать для различения на основе имен или меток кластера:
apiVersion: core.kubeadmiral.io/v1alpha1
kind: OverridePolicy
metadata:
name: example
namespace: default
spec:
# 最终匹配的集群是所有rule匹配集群的交集
overrideRules:
- targetClusters:
# 通过名称匹配集群
clusters:
- member1
- member2
# 通过标签selector匹配集群
clusterSelector:
region: beijing
az: zone1
# 通过基于标签的affinity匹配集群
clusterAffinity:
- matchExpressions:
- key: region
operator: In
values:
- beijing
- key: provider
operator: In
values:
- volcengine
# 在匹配的集群中，使用jsonpatch语法修改第一个容器的镜像
overriders:
jsonpatch:
- path: "/spec/template/spec/containers/0/image"
operator: replace
value: "nginx:test"
2. Возможности планирования можно расширить.
KubeAdmiral относится к конструкции kube-scheduler и предоставляет расширяемую структуру планирования. Он разделяет логику планирования на четыре этапа: фильтр, оценка, выбор и реплика, а также использует несколько относительно независимых плагинов для реализации своей логики на каждом этапе. Почти каждое поле в PropagaionPolicy, показанное на рисунке выше, реализовано независимым встроенным плагином планирования. Плагины не мешают друг другу, и планировщик вызывает необходимые плагины для глобальной оркестрации.
Кроме того, планировщик KubeAdmiral также поддерживает взаимодействие с внешними плагинами через протокол http. Пользователи могут писать и развертывать настраиваемую логику планирования для удовлетворения потребностей доступа к внутренней системе компании для планирования. Встроенный плагин реализует более общие возможности и дополняет внешний плагин. Пользователи могут расширить логику планирования с минимальными затратами и без изменения плоскости управления федерацией и положиться на мощные возможности многокластерного распределения KubeAdmiral для планирования. результаты эффективны.
3. Автоматическая миграция в случае сбоя планирования приложения.
Для ресурсов, запланированных по репликам, KubeAdmiral рассчитает, сколько реплик заслуживает каждый член кластера, перезапишет количество полей реплик, а затем доставит их в каждый член кластера. Этот процесс называется федеративным планированием после доставки ресурсов, kube- каждого члена кластера. Планировщик выделит модуль, соответствующий ресурсу, соответствующему узлу. Этот процесс становится планированием одного кластера.
После выдачи ресурсов планирование одного кластера может иногда давать сбой из-за отключения узла, недостаточности ресурсов, неудовлетворительной привязки узлов и т. д. Если не обработать, количество доступных бизнес-экземпляров будет ниже ожидаемого. KubeAdmiral предоставляет функцию автоматической миграции при сбое планирования. Если эта функция включена, она может выявлять незапланированные реплики в членских кластерах и переносить их в кластеры, которые могут размещать избыточные реплики, реализуя оборот ресурсов нескольких кластеров.
Например, трем кластерам A, B и C выделяется по 6 копий с одинаковым весом. После первоначального планирования федерации каждому кластеру будет назначено 2 копии. Если две копии в кластере C не удастся запланировать в одном кластере, KubeAdmiral автоматически перенесет их в A и B.
| кластер | А | Б | С |
|---|---|---|---|
| Веса | 1 | 1 | 1 |
| Количество начальных экземпляров федеративного планирования | 2 | 2 | 2 |
| Реплики, которые не удалось запланировать в одном кластере | 0 | 0 | 2 |
| Количество экземпляров федеративного планирования после автоматической миграции | 3 | 3 | 0 |
4. Динамическое планирование ресурсов на основе уровня воды в кластере.
В среде с несколькими кластерами уровни ресурсов каждого кластера изменяются динамически по мере того, как машины подключаются и отключаются от сети. Использование только статических реплик планирования веса, предоставляемых KubeFed RSP, может легко привести к неравномерному уровню воды в кластерах со слишком высокой скоростью развертывания. подвержены проблемам во время обновлений служб. Поды ожидают ожидания в течение длительного времени, а ресурсы кластера с низкой скоростью развертывания не могут быть полностью использованы. В связи с этим KubeAdmiral представляет динамическое планирование веса на основе уровня воды в кластере. Он рассчитывает доступный объем, собирая общий объем ресурсов и использование каждого кластера, и использует доступный объем ресурсов в качестве веса планирования копирования, в конечном итоге достигая балансировки нагрузки. каждого членского кластера, а уровень развертывания всех членских кластеров поддерживается на уровне выше 95%.
5. Улучшение алгоритма распределения копий.
Алгоритм распределения копий KubeFed часто приводит к отклонению количества экземпляров от ожидаемого при увеличении или уменьшении масштаба, например:
30 экземпляров распределены по трем кластерам-участникам A, B и C. В случае rsp.rebalance = false пользователь хочет уменьшить количество экземпляров до 15:
Перед сокращением:
| кластер | А | Б | С |
|---|---|---|---|
| Веса | 10 | 10 | 10 |
| Количество экземпляров | 15 | 15 | 0 |
После сжатия:
| кластер | А | Б | С |
|---|---|---|---|
| Веса | 10 | 10 | 10 |
| Количество экземпляров | 15 | 0 | 0 |
Причина этого явления в том, что алгоритм реплик KubeFed сначала предварительно распределяет количество существующих на данный момент экземпляров в кластере, а затем распределяет оставшиеся экземпляры в соответствии с весом каждого кластера. Если в текущем кластере слишком много реплик, это происходит. Это приведет к серьезному расхождению между распределением экземпляров и весом.
KubeAdmiral оптимизирует алгоритм копирования KubeFed, чтобы сделать окончательное распределение максимально близким к распределению веса, гарантируя при этом, что во время расширения и сжатия не произойдет неожиданная миграция. На примере масштабирования с 30 экземпляров до 15 упрощенный алгоритм выглядит следующим образом:
- текущее распределение = [15, 15, 0], всего реплик: 30
- желаемое распределение = [5, 5, 5], всего реплик: 15
- расстояние = желаемое - текущее = [-10, -10, 5], общее расстояние: 15
- Для сценариев сокращения удалите положительный член distance = [-10, -10, 0]
- Используя расстояние в качестве веса, перераспределите разницу 15: [-7, -8, 0]
- Окончательный результат планирования: [-7, -8, 0] + [15, 15, 0] -> [8, 7, 0]
| кластер | А | Б | С |
|---|---|---|---|
| Веса | 10 | 10 | 10 |
| Количество экземпляров | 8 | 7 | 0 |
6. Поддержка собственных ресурсов
В отличие от KubeFed, который требует от пользователей использования совершенно несовместимого нового API, KubeAdmiral учитывает привычки использования пользователей одного кластера Kubernetes и обеспечивает поддержку собственных API Kubernetes. После того как пользователи создают собственные ресурсы (например, развертывание), контроллер федерации автоматически преобразует их в объединенные внутренние объекты для использования другими контроллерами. Пользователи могут быстро перейти от одного кластера к многокластерной архитектуре и насладиться удобством нескольких кластеров с помощью одного кластера. низкий порог.
KubeAdmiral не останавливается на достигнутом. В одном кластере собственный контроллер Kubernetes обновляет статус некоторых ресурсов, чтобы отразить их текущий статус. Пользователи или системы верхнего уровня часто полагаются на статус для просмотра такой информации, как статус развертывания и состояние работоспособности. В нескольких кластерах состояние ресурсов разбросано по нескольким кластерам. Чтобы просмотреть глобальное состояние, пользователи должны просматривать состояние ресурсов в каждом кластере по одному, что приводит к таким проблемам, как фрагментация представлений и низкая эффективность эксплуатации и обслуживания. Чтобы решить эту проблему и беспрепятственно поддерживать собственные ресурсы, KubeAdmiral предоставляет возможности агрегирования статусов, которые объединяют и интегрируют статусы ресурсов в нескольких членских кластерах и записывают их обратно в собственные ресурсы, так что пользователям не нужно знать о множестве. -кластерная топология. Состояние ресурсов по всей федерации можно сразу увидеть.
настоящее и будущее
KubeAdmiral уже много лет существует в Byte. Он активно поддерживает бизнес-платформу TCE Byte Group и управляет более чем 210 000 машинами и более чем 10 миллионами модулей. Он был усовершенствован такими крупными компаниями, как Douyin и Toutiao, и накопил много ценных данных. практический опыт. . Чтобы принести пользу сообществу, KubeAdmiral был официально открыт на GitHub. В то же время Volcano Engine создает новую модель управления несколькими облаками и несколькими кластерами корпоративного уровня на основе KubeAdmiral — Distributed Cloud Native Platform (DCP), так что следите за обновлениями.
Заглядывая в будущее, мы планируем продолжать развиваться в следующих аспектах:
- Продолжайте совершенствовать возможности оркестрации и планирования ресурсов с отслеживанием состояния, типов заданий и других ресурсов, а также разрабатывать расширенные возможности, такие как автоматическая миграция и планирование сравнения цен, чтобы охватить наступление мультиоблачной и мультикластерной эры пакетных вычислений.
- Улучшайте взаимодействие с пользователем и предоставляйте готовые решения для дальнейшего снижения когнитивной нагрузки пользователей.
- Улучшите наблюдаемость, оптимизируйте показатели журналов и мониторинга, а также улучшите интерпретируемость планировщика.
- Изучите такие функции, как объединение в один клик и миграцию нескольких кластеров, чтобы полностью раскрыть потенциал многокластерной архитектуры.
Многокластерная оркестровка и планирование не просты по своей природе. Универсальную и полную многокластерную федеративную систему необходимо оттачивать в различных сценариях. Мы надеемся, что больше друзей обратят внимание и присоединятся к сообществу KubeAdmiral. Мы также приглашаем всех попробовать KubeAdmiral. и предоставьте нам различные предложения!
GitHub: https://github.com/kubewharf/kubeadmiral
Товарищ-цыпленок «открыл исходный код» Deepin-IDE и наконец-то добился начальной загрузки! Хороший парень, Tencent действительно превратила Switch в «мыслящую обучающуюся машину». Обзор сбоев Tencent Cloud от 8 апреля и объяснение ситуации. Реконструкция запуска удаленного рабочего стола RustDesk. Веб-клиент . Терминальная база данных с открытым исходным кодом WeChat на основе SQLite. WCDB положила начало серьезному обновлению. Апрельский список TIOBE: PHP упал до рекордно низкого уровня, Фабрис Беллард, отец FFmpeg, выпустил инструмент сжатия звука TSAC , Google выпустил большую модель кода CodeGemma , она вас убьет? Это так хорошо, что это инструмент с открытым исходным кодом - инструмент для редактирования изображений и плакатов с открытым исходным кодом.