Введение

OpenYurt - это первый в отрасли ненавязчивый проект периферийных вычислений Kubernetes, созданный с помощью Alibaba Cloud с открытым исходным кодом на базе нативного Kubernetes . Цель состоит в том, чтобы расширить Kubernetes для беспрепятственной поддержки сценариев пограничных вычислений. Он обеспечивает полную совместимость с Kubernetes API; поддерживает все рабочие нагрузки, службы, операторов Kubernetes, плагины CNI и плагины CSI; обеспечивает хорошую автономность узла, даже если граничный узел отключен от облака, приложения, работающие на граничном узле Это не повлияет. OpenYurt можно легко развернуть в любой кластерной службе Kubernetes, что позволяет распространить мощные облачные возможности на периферию.

Выпущен OpenYurt v0.3.0

8 ноября 2020 года по пекинскому времени Openyurt выпустила версию v0.3.0, в которой впервые была предложена концепция пула узлов и унифицированного развертывания, а также добавлен облачный компонент Yurt-App-Manager для всестороннего повышения эффективности развертывания приложений в граничных сценариях и уменьшения количества граничных узлов. И сложность эксплуатации и обслуживания приложений. Чтобы полностью оптимизировать производительность основных компонентов yurthub и yurt-tunnel , yurtctl предоставляет поставщика kubeadm, который может быстро и легко преобразовать кластер Kubernetes, созданный kubeadm, в кластер Openyurt.

1. Yurt-App-Manger создан для работы и обслуживания периферийных приложений.

После обширных обсуждений со студентами сообщества OpenYurt предоставляет компонент OpenYurt Yurt-App-Manager. Yurt-App-Manager - это стандартное расширение Kubernetes. Его можно использовать с Kubernetes. Он предоставляет два контроллера: NodePool и UnitedDeployment. Он обеспечивает возможности эксплуатации и обслуживания узлов и приложений в пограничных сценариях из измерения хоста и измерения приложения.

1) Пул узлов: NodePool

В граничных сценариях граничные узлы обычно имеют сильные региональные, региональные или другие характеристики логической группировки (например, одинаковая архитектура ЦП, один и тот же оператор, облачный провайдер), и часто существуют сетевые различия между узлами в разных группах. Очевидные свойства изоляции, такие как взаимодействие, отсутствие совместного использования ресурсов, разнородные ресурсы и независимость от приложений, также являются источником NodePool.

NodePool, как следует из названия, мы можем назвать его пулом узлов, группой узлов или единицей узла. Для управления узлами Woker с общими атрибутами традиционный подход заключается в использовании метки для классификации и управления хостами. Однако по мере увеличения количества узлов и меток хосты узлов классифицируются и управляются (например: пакетная настройка политик планирования, портит и т. д.) Эффективность и гибкость ухудшатся, как показано на следующем рисунке:

NodePool делает многомерную абстракцию разделения узлов в измерении групп узлов и может выполнять унифицированное управление, эксплуатацию и обслуживание узлов в различных граничных областях с точки зрения пулов узлов, как показано на следующем рисунке:

2) Размещение подразделения: UnitedDeployment

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

Однако с увеличением географического распределения и дифференцированными требованиями к приложениям в разных регионах эксплуатация и обслуживание становятся все более сложными, что проявляется в следующих аспектах:

Чтобы обновить версию образа, вам необходимо изменить каждое развертывание одно за другим.
Необходимо настроить соглашение об именах развертывания, чтобы указать одно и то же приложение.
По мере того, как граничные сценарии становятся все более и более сложными и требования возрастают, развертывание каждого пула узлов будет иметь некоторые дифференцированные конфигурации, которыми сложно управлять.

Единое развертывание (UnitedDeployment) через более высокий уровень абстракции, унифицированное управление этими вложенными развертываниями: автоматическое создание / обновление / удаление. Как показано ниже:

Контроллер UnitedDeployment может предоставить шаблон для определения приложения и управления несколькими рабочими нагрузками для соответствия следующим различным областям. Рабочая нагрузка каждого региона в рамках каждого UnitedDeployment называется пулом. В настоящее время пул поддерживает две рабочие нагрузки: StatefulSet и Deployment. Контроллер будет создавать дочерние объекты ресурсов рабочей нагрузки на основе конфигурации пула в UnitedDeployment, и каждый объект ресурсов имеет ожидаемое количество подов реплик. Через экземпляр UnitedDeployment можно автоматически поддерживать несколько ресурсов Deployment или Statefulset, а также он может иметь дифференцированные конфигурации, такие как реплики. Чтобы получить более интуитивно понятный интерфейс, ознакомьтесь с руководством по использованию Yurt-App-Manager и руководством для разработчиков .

Чтобы узнать больше о Yurt-App-Manager, обратитесь к проблеме сообщества и запросу на перенос:

Проблема 124: Использование UnitedDeployment
проблема 171: [запрос функции] определение NodePool и UnitedDeployment
запрос на вытягивание 173: [предложение] добавить пул узлов и предложение crd объединенного развертывания

2. Узел автономной составляющей юрта-хаб.

yurt-hub - это демон, который запускается на каждом узле кластера Kubernetes. Его роль заключается в том, чтобы действовать как прокси для исходящего трафика (плагины Kubelet, Kubeproxy, CNI и т. д.). Он кэширует состояние всех ресурсов, к которым может получить доступ демон узла Kubernetes, в локальном хранилище граничного узла. Если граничный узел находится в автономном режиме, эти демоны могут помочь узлу восстановить состояние после перезапуска и обеспечить возможность автономной работы на границе. В версии v0.3.0 сообщество внесло множество функциональных улучшений в юрт-хаб, в том числе:

Когда yurt-hub подключается к облачному kube-apiserver, он автоматически запрашивает сертификат от kube-apiserver и поддерживает автоматическую ротацию по истечении срока действия сертификата.
При просмотре облачных ресурсов добавьте механизм тайм-аута.
Если данные локального кэша не существуют, оптимизируйте ответ.

3. Облачная часть канала эксплуатации и технического обслуживания юрта-тоннель.

yurt-tunnel состоит из TunnelServer в облаке и TunnelAgent, работающего на каждом граничном узле. TunnelServer устанавливает соединение с демоном TunnelAgent, работающим на каждом граничном узле, через обратный прокси-сервер и устанавливает безопасный сетевой доступ между плоскостью управления публичного облака и граничным узлом в корпоративной интрасети. В версии v0.3.0 сообщество внесло множество улучшений в компонент юрта-туннель с точки зрения надежности, стабильности и тестирования интеграции.

4. Компонент эксплуатации и обслуживания OpenYurt yurtctl

В версии v0.3.0 yurtctl поддерживает провайдера kubeadm, который может быстро и легко преобразовать собственный кластер Kubernetes, созданный kubeadm, в кластер Kubernetes, который может адаптироваться к слабой пограничной сетевой среде, что значительно улучшает опыт OpenYurt.

Для более практических действий обратите внимание: « Введение в OpenYurt-Playing OpenYurt на Raspberry Pi »

План на будущее

Выпуск OpenYurt V0.3.0 дополнительно улучшает масштабируемость нативного Kubernetes в пограничных сценариях. В то же время, компонент Yurt-App-Manger выпущен для решения проблем развертывания приложений в пограничных сценариях. Сообщество OpenYurt будет следить за управлением устройствами, а также периферийной эксплуатацией и обслуживанием. Мы продолжаем инвестировать в планирование, управление сообществом и опыт участников. Еще раз спасибо за участие студентов Intel / Vmware. В то же время, заинтересованные студенты также могут присоединиться и участвовать в совместном строительстве для создания стабильной и надежной полностью облачной платформы периферийных вычислений.

Чтобы узнать больше о сообществе, обратите внимание:https://github.com/alibaba/openyurt。

Тяжелый выпуск OpenYurt v0.3.0: всестороннее повышение эффективности развертывания приложений в пограничных сценариях