В 2024 году в песочницу CNCF добавились новые проекты в категории Orchestration & Management (Оркестрация и управление). В статье мы сделали обзор этих инициатив, чтобы узнать, какие новые решения предлагаются для управления микросервисами и контейнерами. Давайте посмотрим, что нового принёс этот год.
В этой статье разберем следующие проекты:
Connect RPC
Connect RPC — это семейство библиотек для создания API, совместимых с браузером и gRPC. С их помощью можно сделать интерпретаторы для схем в формате Protocol Buffer: на нём описывается простая схема API, а Connect на её основе генерирует код для его реализации на одном из поддерживаемых языков программирования.
Поддерживаются следующие языки для генерации:
Go;
TypeScript и JavaScript;
Swift и Kotlin.
Серверы и клиенты Connect поддерживают три протокола: gRPC, gRPC-Web и собственный протокол Connect. Из основных особенностей можно выделить следующие:
Connect полностью поддерживает протокол gRPC, включая потоковую передачу, трейлеры и сведения об ошибках. Любой клиент gRPC на любом языке может вызывать сервер Connect, а клиенты Connect могут вызывать любой сервер gRPC. Совместимость с gRPC проверяется разработчиками с помощью расширенной версии собственных тестов Google на совместимость.
Connect предлагает прямую поддержку протокола gRPC-Web, используемого grpc/grpc-web, без использования транслирующего прокси-сервера, такого как Envoy.
Connect поддерживает собственный простой протокол на основе HTTP, работающий поверх HTTP/1.1, HTTP/2 и HTTP/3. Он берёт лучшие части gRPC и gRPC-Web, включая потоковую передачу, и упаковывает их в протокол, который одинаково хорошо работает в браузерах, монолитах и микросервисах. По умолчанию реализации поддерживают как JSON, так и двоично-кодированный Protobuf.
Изначально серверы Connect поддерживают входящий трафик со всех трёх протоколов. А клиенты по умолчанию используют протокол Connect, но могут переключиться на gRPC или gRPC-Web с помощью переключателя конфигурации — никаких дополнительных изменений кода не требуется. API для ошибок, заголовков, трейлеров и потоковой передачи не зависят от протокола.
Подробнее с проектом можно ознакомиться в официальной документации. Исходный код утилиты доступен на GitHub и распространяется под лицензией Apache 2.0.
HAMi
HAMi — промежуточное программное обеспечение для виртуализации гетерогенных вычислений на базе искусственного интеллекта в кластере Kubernetes. Он позволяет управлять виртуальными устройствами для вычислений. Ранее проект носил название k8s-vGPU-scheduler.
Основные особенности проекта:
-
Совместное использование устройств:
поддержка нескольких гетерогенных вычислительных устройств на базе ИИ;
поддержка совместного использования устройств для контейнеров с несколькими устройствами.
-
Управление памятью устройства:
лимиты внутри контейнера;
поддержка динамического распределения памяти устройства;
поддержка распределения памяти в мегабайтах или процентах.
-
Спецификация устройства:
поддержка указания типа определённых гетерогенных вычислительных устройств ИИ;
поддержка указания определённых гетерогенных вычислительных устройств ИИ с использованием UUID-устройства.
-
Простота работы:
прозрачен для задач внутри контейнера;
установка и удаление с помощью Helm.
HAMi включает в себя следующие компоненты:
HAMi Mutating Webhook — проверяет, может ли HAMi справиться с этой задачей.
Планировщик (HAMi scheduler) — отвечает за назначение задач соответствующим узлам и устройствам.
Плагин для устройства (HAMi-device-plugin) — получает результат планирования из поля аннотаций задачи и сопоставляет соответствующее устройство с контейнером.
Внутриконтейнерный контроль ресурсов (HAMi-Core) — отвечает за мониторинг использования ресурсов внутри контейнера и обеспечивает возможности жёсткой изоляции.
Схема работы HAMi изображена на рисунке ниже:
HAMi поддерживает совместное использование устройств:
позволяет частично выделять устройство, указывая необходимую память;
накладывает жёсткое ограничение на потоковые мультипроцессоры;
позволяет частично выделять ресурсы устройству, указывая лимиты использования ядра;
не требует внесения изменений в существующие программы.
Также поддерживается изоляция ресурсов устройства. Например, если указать в манифесте следующие ресурсы для виртуального устройства:
resources:
limits:
nvidia.com/gpu: 1 # Requesting 1 vGPU.
nvidia.com/gpumem: 3000 # Each vGPU contains 3000m device memory.то внутри контейнера будут видны только они:
Подробнее с проектом можно ознакомиться в официальной документации. Исходный код утилиты доступен на GitHub и распространяется под лицензией Apache 2.0.
Kmesh
Kmesh — это высокопроизводительный сервис-меш-сервис, основанный на sidecarless-архитектуре и не требующий развёртывания прокси-компонентов на плоскости данных. Он реализует функцию управления службами и улучшает производительность пересылки доступа к службам.
Особенности Kmesh:
прозрачное для приложений управление трафиком;
автоматическая интеграция с Istio и другим программным обеспечением;
задержка пересылки менее 60%;
производительность запуска службы выше на 40%;
накладные расходы плоскости данных сервис-меш ниже на 70%;
безопасная оркестровка трафика на основе eBPF;
изоляция оркестровки на уровне Cgroup;
интеграция с основными платформами мониторинга;
поддержка стандартов протокола XDS.
Kmesh прозрачно перехватывает и пересылает трафик на основе локального eBPF узла, не вводя дополнительных переходов соединения. При этом задержка и затраты ресурсов незначительны.
Основные компоненты:
Kmesh-daemon — компонент управления на каждом узле, отвечающий за управление программами bpf, подписку на конфигурацию xDS, наблюдаемость и т. д.
eBPF Orchestration — оркестровка трафика, реализованная на основе eBPF, поддерживает балансировку нагрузки L4, шифрование трафика, мониторинг и простую динамическую маршрутизацию L7.
Waypoint — отвечает за расширенное управление трафиком L7, может быть развёрнута отдельно для каждого пространства имён и для каждой службы.
Kmesh объединяет управление трафиком Layer 4 и Simple Layer 7 (HTTP) в ядре и создает прозрачный сервис-меш без прохождения через прокси-уровень на пути данных. Такой режим работы разработчики назвали Kernel-Native.
Kmesh также предоставляет режим Dual-Engine, который использует eBPF и waypoint'ы для раздельной обработки трафика L4 и L7. Это позволяет внедрять Kmesh постепенно, что обеспечивает плавный переход от отсутствия сетки к безопасной обработке L4 и полной обработке L7.
Разработчики провели тестирование на основе Fortio и сравнили производительность Kmesh и Envoy. Сводные результаты представлены на графике:
Подробнее с тестами производительности можно ознакомиться здесь. А с проектом — в официальной документации. Исходный код утилиты доступен на GitHub и распространяется под лицензией Apache 2.0.
Koordinator
Koordinator — это современная система планирования, которая позволяет совместно использовать микросервисы, искусственный интеллект и большие объёмы данных в Kubernetes. Она обеспечивает гибкое распределение ресурсов и эффективное управление подами, а также изоляцию ресурсов контейнеров. Этот продукт высокопроизводительный, масштабируемый и проверен в реальных условиях. Koordinator помогает создавать системы оркестровки контейнеров для корпоративных сред.
Основные особенности:
Улучшенное использование ресурсов — оптимизация использования ресурсов кластера с гарантией эффективного и результативного использования всех узлов.
Повышение производительности — используются современные алгоритмы и методы, что увеличивает производительность кластеров Kubernetes, уменьшая помехи между контейнерами и увеличивая общую скорость системы.
Гибкие политики планирования — предоставляется возможность настройки политик планирования, позволяющая администраторам адаптировать систему под свои потребности.
Простая интеграция — возможность простой интеграции в существующие кластеры Kubernetes, что позволяет пользователям быстро и с минимальными усилиями приступить к его использованию.
Koordinator представляет эффективный механизм приоритета и QoS для совместного размещения различных рабочих нагрузок в кластере и запуска разных типов подов на одном узле. Он достигает высокой утилизации ресурсов за счёт избыточного их выделения и обеспечивает гарантии QoS, используя механизм профилирования приложений.
Основная идея заключается в том, чтобы выделять ресурсы подам с низким приоритетом, возвращая высокоприоритетные ресурсы, которые были запрошены, но не использованы. Это позволяет избежать сбоев в прогнозировании благодаря разумному профилированию ресурсов и стратегии «снизу вверх» на уровне узла.
Компонент QoSManager предназначен для координации набора плагинов, которые отвечают за гарантию SLO по приоритету, смягчая помехи между подами. Эти плагины динамически настраивают «knobs» параметров ресурсов в различных сценариях в соответствии с профилированием ресурсов, результатами обнаружения помех и конфигурацией SLO.
QoSManager непрерывно настраивает параметры изоляции ресурсов каждого пода, чтобы устранить джиттер с длинным хвостом рабочих нагрузок, чувствительных к задержке. Поэтому, даже если нет задачи настроить улучшение использования ресурсов, он предоставляет ряд методов для улучшения стабильности и производительности во время выполнения.
Koordinator предоставляет ряд опций для настройки политик планирования, позволяя пользователям точно настраивать поведение системы в соответствии со своими конкретными потребностями, такими как Web Service, Spark, Presto, TensorFlow, Pytorch и т. д. Он даёт возможность управлять политиками планирования рабочей нагрузки с помощью профилей. Благодаря этому можно контролировать политики планирования без изменения существующего контроллера рабочей нагрузки.
Эти профили предоставляют лучшие практики для запуска типичных рабочих нагрузок в Kubernetes. Их можно легко расширить, если они не соответствуют потребностям напрямую. Сообщество разработчиков постоянно добавляет новые лучшие практики для размещения рабочей нагрузки.
Koordinator состоит из компонентов плоскости управления и узловых компонентов и не требует инвазивных модификаций собственных компонентов Kubernetes. Он работает аналогично sidecar в кластере Kubernetes и на основе выбранных политик планирует и управляет пользовательскими подами, наблюдает за их состоянием выполнения и оптимизирует их производительность.
Координатор следует принципу слабой связанности, позволяя использовать весь набор или комбинацию некоторых компонентов для удовлетворения своих бизнес-требований.
Подробнее с проектом можно ознакомиться в официальной документации. Исходный код утилиты доступен на GitHub и распространяется под лицензией Apache 2.0.
Kuadrant
Kuadrant — это система облачных компонентов K8s, которая расширяется по мере роста потребностей пользователей:
От простой защиты службы (через AuthN) для сотрудников, работающих в одном кластере, до AuthZ-пользователей, использующих OIDC и настраиваемые политики.
От отсутствия ограничения скорости до ограничения скорости для глобальной защиты сервиса и ограничения скорости по пользователям/планам.
Kuadrant объединяет Gateway API и контроллеры шлюзов на базе Istio для улучшения подключения приложений. Это позволяет инженерам платформ и разработчикам приложений легко подключить, защитить и обезопасить свои сервисы и инфраструктуру в нескольких кластерах. Делается это с помощью политик для TLS, DNS, аутентификации и авторизации приложений и ограничения скорости. Кроме того, Kuadrant предлагает шаблоны наблюдения для дальнейшей поддержки и управления инфраструктурой.
Особенности архитектуры:
Архитектура Kuadrant определена и реализована с использованием компонентов как плоскости управления, так и плоскости данных.
Плоскость управления — это место, где политики раскрываются и выражаются в виде API Kubernetes и согласовываются контроллером политик.
Плоскость данных — это то место, где существуют компоненты «политики принудительного исполнения» Kuadrant. Эти компоненты настраиваются плоскостью управления и интегрируются либо напрямую с поставщиком шлюза, либо через внешние интеграции.
Плоскость управления представляет собой набор контроллеров и операторов, которые отвечают за установку и настройку других компонентов. Это включает компоненты принудительного применения плоскости данных и настройку шлюза для обработки входящих запросов
Плоскость управления также владеет и согласовывает API-политики CRD, преобразуя их в более сложные объекты конфигурации. Эти объекты используются компонентами принудительного применения политики для определения правил, применяемых к входящим запросам, а также для настройки внешних интеграций, таких как поставщики DNS и ACME.
-
Kuadrant Operator:
устанавливает и настраивает другие компоненты плоскости управления;
устанавливает компоненты обеспечения политики плоскости данных через соответствующие операторы плоскости управления;
настраивает шлюз через плагин WASM и другие API для использования компонентов плоскости данных для аутентификации и ограничения скорости входящих запросов;
предоставляет RateLimitPolicy, AuthPolicy, DNSPolicy и TLSPolicy, а также согласовывает их в применимую конфигурацию для плоскости данных;
предоставляет Kuadrant и согласовывает эти данные для настройки и запуска установки требуемых компонентов плоскости данных и других компонентов плоскости управления.
Limitador Operator — устанавливает и настраивает компонент Limitador data plane на основе Limitador CRD. Лимиты, указанные в Limitador CRD, монтируются через ConfigMap в компонент limitador.
Authorino Operator — устанавливает и настраивает компонент плоскости данных Authorino на основе Authorino CRD.
Cert-Manager — управляет сертификатами TLS для компонентов и шлюзов. Использует ресурсы сертификатов, созданные оператором Kuadrant в ответ на TLSPolicy.
DNS Operator — использует ресурсы DNSRecord, настроенные через API DNSPolicy, и применяет их к целевому облачному поставщику DNS. Основными поставщиками являются AWS, Azure и Google DNS.
Компоненты плоскости данных обрабатывают запросы и реализуют конфигурацию, определённую политикой. Они обеспечивают защиту сервисов на основе конфигурации, управляемой и создаваемой плоскостью управления.
Limitador — сопоставляет API ограничения скорости Envoy для предоставления ограничения скорости шлюзу. Использует лимиты из ConfigMap, созданного на основе API RateLimitPolicy.
Authorino — сопоставляет API внешней аутентификации Envoy для обеспечения интеграции аутентификации со шлюзом. Предоставляет как Authn, так и Authz. Использует AuthConfigs, созданные Kuadrant Operator на основе определённого AuthPolicyAPI.
WASM Shim — использует спецификацию Proxy WASM ABI для интеграции с Envoy и обеспечивает фильтрацию и подключение к Limitador для обеспечения соблюдения времени запроса и ограничения скорости.
Поддерживается установка как на одиночный кластер так и в мультикластерную архитектуру:
-
В одиночном кластере есть плоскость управления Kuadrant и плоскость данных, расположенные вместе. Он настроен на интеграцию со шлюзами в том же кластере и настройку зоны DNS через секрет поставщика DNS (настроенный вместе с DNSPolicy). Хранение счётчиков ограничения скорости возможно, но не обязательно, поскольку они не являются общими.
-
В мультикластерной настройке по умолчанию в каждом кластере установлен Kuadrant. Кластеры не знают друг о друге. Они эффективно работают как отдельные сущности. Многокластерность достигается с помощью совместного доступа к зоне DNS, использования общего хоста по всем кластерам и общего хранилища счётчиков. Зона управляется независимо каждым из операторов DNS на всех кластерах для формирования единого связного набора записей.
Счётчики ограничения скорости также могут совместно использоваться разными кластерами для обеспечения глобального ограничения скорости. Это возможно с помощью подключения каждого экземпляра Limitador к общему хранилищу данных, использующему протокол Redis.
На рисунке выше показана топология шлюза с несколькими кластерами и несколькими входами. Например, её можно использовать для поддержки географически распределённой системы.
Архитектура Kuadrant предназначена для работы с некоторыми популярными инструментами мониторинга для трассировки, метрик и агрегации журналов. Эти инструменты:
Prometheus для сбора метрик и опционально Thanos для высокой доступности и федерации;
Loki для агрегации журналов — через сборщики журналов, такие как Vector;
Tempo для сбора трейсов;
Grafana для визуализации вышеизложенного.
В зависимости от количества кластеров в конфигурации систему мониторинга можно разместить в том же кластере, что и рабочие нагрузки, или в отдельном кластере. Ниже приведены два примера архитектур, основанных на однокластерной и многокластерной компоновках.
В однокластерной архитектуре компоненты коллектора (Prometheus, Vector и Tempo) находятся в том же кластере, что и компонент агрегации журналов (Loki) и визуализации (Grafana):
В мультикластерной архитектуре сборщики метрик или журналов (Prometheus и Vector) развёртываются вместе с рабочими нагрузками в каждом кластере. Однако, поскольку трассировки отправляются в сборщик (Tempo) из каждого компонента, он может быть централизован в отдельном кластере:
Thanos используется в этой архитектуре, поэтому каждый Prometheus может объединять метрики обратно в центральное местоположение. Сборщик журналов (Vector) может пересылать журналы в центральный экземпляр Loki. Наконец, компонент визуализации (Grafana) также централизован с источниками данных, настроенными для каждого из трёх компонентов в одном кластере.
Подробнее с проектом можно ознакомиться в официальной документации. Исходный код утилиты доступен на GitHub и распространяется под лицензией Apache 2.0.
KubeSlice
KubeSlice предоставляет сетевые сервисы для приложений, которым требуется безопасное и высоко доступное подключение между несколькими кластерами. Он создает оверлейную сеть, соединяющую кластеры. Эта сеть представляет собой срез приложения, который обеспечивает соединение между подами, работающими в нескольких кластерах. Её также можно описать как VPC для конкретного приложения, который охватывает кластеры. Поды могут подключаться к оверлейной сети среза и беспрепятственно взаимодействовать друг с другом через границы кластера.
KubeSlice позволяет создавать несколько логических срезов в одном кластере или группе кластеров независимо от их физического расположения. Существующая внутрикластерная коммуникация остаётся локальной для кластера, используя CNI-интерфейс каждого пода. Это достигается за счёт добавления второго интерфейса к поду, что позволяет локальному трафику оставаться на интерфейсе CNI, а трафику, направляемому для внешних кластеров, — маршрутизироваться через оверлейную сеть к поду назначения.
Архитектура KubeSlice состоит из нескольких компонентов, которые взаимодействуют друг с другом для управления жизненным циклом оверлейной сети срезов. На схеме ниже показаны основные компоненты KubeSlice и связи между ними.
Controller cluster содержит контроллер KubeSlice, который управляет пользовательской конфигурацией и организует создание оверлейной сети между несколькими рабочими кластерами. Он определяет и владеет рядом CRD, которые используются для хранения конфигурации и информации в кластере. CRD также используются во взаимодействии между кластером контроллера и рабочими кластерами. Рабочие кластеры подключаются к серверу API Kubernetes кластера контроллера для извлечения конфигурации, которая хранится в объектах пользовательских ресурсов.
Основным компонентом рабочих кластеров является Slice Operator. Он взаимодействует с кластером контроллера и настраивает необходимую инфраструктуру для оверлейной сети на рабочем кластере. Оператор среза предоставляет шлюзы и настраивает правила маршрутизации для направления трафика между модулями приложений и модулями шлюзов.
KubeSlice состоит из следующих основных компонентов:
KubeSlice Controller — устанавливается в одном из кластеров и обеспечивает централизованную систему управления конфигурацией для срезов в нескольких кластерах.
-
Slice Operator (или Worker Operator) — компонент оператора Kubernetes, который управляет жизненным циклом пользовательских определений ресурсов (CRD), связанных с KubeSlice. Выполняет следующие функции:
взаимодействие с KubeSlice Controller для получения обновлений конфигурации среза;
согласование ресурсов срезов в кластере KubeSlice Controller;
создание компонентов среза, необходимых для подключения шлюза Slice VPN и обнаружения служб;
автоматическая вставка и удаление компонентов среза для учёта изменений топологии;
управление жизненным циклом срезов, их конфигурациями, статусом и телеметрией;
управление жизненным циклом сетевых политик и мониторинг отклонений конфигурации для генерации событий и оповещений;
управление ассоциацией срезов с пространствами имён;
-
взаимодействие с KubeSlice Controller для:
упрощения разработки сетевой политики и обнаружения по всему сегменту;
импорта/экспорта служб Istio в другие кластеры, подключённые к срезу, и из них;
реализации контроля доступа на основе ролей (RBAC) для управления компонентами среза.
-
Slice VPN Gateways — компонент сетевой службы среза, который обеспечивает безопасный VPN-туннель между несколькими кластерами, входящими в конфигурацию. Выполняет следующие функции:
взаимодействует с KubeSlice Controller для получения конфигурации, связанной со шлюзами срезов;
поддерживает криптографические ключи и сертификаты, необходимые для защищённых VPN-туннелей;
развёртывает и согласовывает модули шлюзов VPN-сетей;
периодически отслеживает состояние шлюзовых подов;
постоянно взаимодействует с Slice VPN Gateways для получения статуса, ключей/сертификатов и изменений конфигурации.
Slice Router — виртуальное устройство третьего уровня, которое устанавливает правила маршрутизации и пересылки в оверлейной сети. На каждый срез в кластере выделяется минимум один Slice Router.
Slice Istio Components — предоставляет возможность настройки входящих и исходящих шлюзов для среза с использованием ресурсов Istio Service Mesh. Входящий/исходящий шлюз не является основным компонентом KubeSlice, это дополнительная функция, которую пользователи могут активировать при необходимости. Компоненты Istio должны быть установлены в кластере до установки компонентов KubeSlice, либо же они могут быть установлены как часть самой установки KubeSlice.
Slice Gateway Edge — необходим, когда настроенный тип подключения шлюза для кластера среза — LoadBalancer. Сетевой балансировщик нагрузки соединяет кластер с другими кластерами в срезе. Slice Gateway Edge программируется оператором среза для распределения внешнего трафика, поступающего через LoadBalancer, на нужные поды шлюза среза. На основе его связи с оператором среза он устанавливает правила NAT для фильтрации трафика и пересылает его на соответствующий под VPN-шлюза среза.
KubeSlice DNS — DNS-сервер, который используется для разрешения имён служб, отображаемых в срезах приложений.
Network Service Mesh Control and Data Plane — настраивает плоскость данных KubeSlice и подключает поды приложений к оверлейной сети.
Помимо подключения публичных кластеров, KubeSlice также может использоваться для подключения кластеров, которые заключены в частном VPC. Доступ к таким кластерам осуществляется через сетевой или прикладной балансировщик нагрузки, который предоставляется и управляется поставщиком облачных услуг.
KubeSlice использует сетевые балансировщики нагрузки для настройки межкластерного подключения к частным кластерам.
Подробнее с проектом можно ознакомиться в официальной документации. Исходный код утилиты доступен на GitHub и распространяется под лицензией Apache 2.0.
LoxiLB
LoxiLB — это облачный балансировщик нагрузки на основе GoLang/eBPF, целью которого является достижение кросс-совместимости в широком спектре локальных, общедоступных облачных или гибридных сред K8s. LoxiLB разрабатывается для поддержки внедрения облачных технологий в телекоммуникациях, мобильных устройствах и периферийных вычислениях.
LoxiLB превращает балансировку сетевой нагрузки Kubernetes в высокоскоростные, гибкие и программируемые службы LB. Он автоматизирует задачи администрирования внешнего балансировщика нагрузки: развёртывание, начальная загрузка, настройка, предоставление, масштабирование, обновление, миграция, маршрутизация, мониторинг и управление ресурсами.
Kubernetes определяет множество сервисных конструкций, таких как кластерный IP, node-port, балансировщик нагрузки, ingress и т. д., для связи между подами, между подами и службами, а также между внешним миром и службами.
Все эти сервисы предоставляются балансировщиками нагрузки и прокси, работающими на уровнях L4 и L7. Поскольку Kubernetes является высокомодульным, эти сервисы могут обеспечиваться различными программными модулями. Например, kube-proxy по умолчанию используется для сервисов cluster-ip и node-port. Для некоторых сервисов, таких как LB и Ingress, значения по умолчанию обычно не предусмотрены.
Балансировщик нагрузки типа Service обычно предоставляется поставщиком общедоступного облака в качестве управляемой сущности. Но для локальных и самоуправляемых кластеров доступно всего несколько хороших вариантов. Даже для управляемых поставщиком K8s, таких как EKS, многие хотели бы привнести свой LB в кластеры, работающие где угодно. Кроме того, телекоммуникационные 5G и пограничные сервисы представляют уникальные проблемы из-за разнообразия задействованных экзотических протоколов, включая GTP, SCTP, SRv6, SEPP и DTLS, что делает бесшовную интеграцию особенно сложной. LoxiLB предоставляет балансировщик нагрузки типа Service в качестве своего основного варианта использования.
Основные особенности:
использует eBPF, что делает его гибким и настраиваемым;
имеет расширенные возможности quality of service для рабочих нагрузок (на LB, на эндпоинт или на клиента);
работает с любыми версиями Kubernetes/CNI — k8s/k3s/k0s/kind/OpenShift + Calico/Flannel/Cilium/Weave/Multus и т. д.;
имеет расширенную поддержку SCTP workloads (с множественной адресацией) на K8s;
работает в любой облачной среде или в standalone-средах.
Основные характеристики:
-
балансировщик нагрузки L4/NAT с отслеживанием состояния:
NAT44, NAT66, NAT64 с One-ARM, FullNAT, DSR и т. д.;
поддержка TCP, UDP, SCTP (с множественной адресацией), QUIC, FTP, TFTP и т. д.;
поддержка высокой доступности с кластеризацией hitless/maglev/cgnat;
расширенные и масштабируемые проверки работоспособности конечных точек для облачных сред;
поддержка межсетевого экрана с отслеживанием состояния и IPSEC/Wireguard;
оптимизированная реализация таких функций, как Conntrack , QoS и т. д.;
полная совместимость с IPVS (политики IPVS могут наследоваться автоматически).
Подробнее с проектом можно ознакомиться в официальной документации. Исходный код утилиты доступен на GitHub и распространяется под лицензией Apache 2.0.
Sermant
Sermant (также известный как Java-mesh) — это proxyless-сервис-меш, основанный на технологии улучшения байт-кода Java. Он использует эту технологию для предоставления возможностей управления службами, решая проблемы управления в крупных архитектурах микросервисов.
Архитектура Sermant изображена на рисунке ниже:
JavaAgent Sermant имеет два уровня функций.
Уровень ядра фреймворка — обеспечивает базовые возможности фреймворка Sermant, чтобы облегчить разработку плагинов. Функция этого уровня включает в себя передачу данных, динамическую конфигурацию и т. д.
Уровень службы плагина — плагин предоставляет фактическую службу управления для приложения. Разработчик может разработать либо простой плагин, напрямую используя службу ядра фреймворка, либо сложный плагин, создав собственную сложную функцию управления службой плагина.
Sermant широко использует технологию изоляции классов для устранения конфликтов загрузки между кодом фреймворка, кодом плагина и кодом приложения.
Архитектура микросервисов, использующая Sermant, состоит из трёх компонентов:
Здесь:
Sermant JavaAgent — динамическое инструментирование приложений для управления службами.
Sermant Backend — обеспечение соединения и предварительной обработки всех загруженных данных JavaAgents.
Dynamic configuration center — предоставление инструкций путём динамического обновления конфигурации для прослушивающего JavaAgent. Этот центр не предоставляется напрямую проектом Sermant и в настоящее время поддерживает такие проекты, как servicecomb-kie и другие.
После установки и запуска пользователю будет доступен веб-интерфейс с основными дашбордами:
Подробнее с проектом можно ознакомиться в официальной документации. Исходный код утилиты доступен на GitHub и распространяется под лицензией Apache 2.0.
Заключение
Мы кратко рассмотрели новые проекты категории ландшафта CNCF Orchestration & Management, добавленные в песочницу фонда за последний год. Надеемся, что они успешно пройдут стадию принятия в CNCF и станут его полноценными членами.
P. S.
Читайте также в нашем блоге: