Расширение

Продвинутые сетевые возможности

Интегрируйте Deckhouse Platform в физическую инфраструктуру дата⁠-⁠центров и подключайте нагрузки к одним и тем же сетям с общей адресацией.

Публикация сервисов в сети без дополнительного оборудования

Маршрутизаторы и ToR⁠-⁠коммутаторы получают анонсы сетевых адресов по BGP, благодаря чему кластеру не требуется балансировщик трафика.

Сокращение количества ручных операций

Узлы не нужно настраивать вручную: инженеры описывают маршруты, правила и анонсы как ресурс Kubernetes, а сетевые настройки проходят то же ревью, что и код.

Изоляция проектов на сетевом уровне

Каждый проект получает собственную VLAN⁠-⁠сеть: подсеть, пул адресов, DHCP, постоянные адреса, MTU. Виртуальные машины и контейнеры одного проекта работают в одних и тех же сетях.

Производительность в телекоме и высоконагруженных проектах

Нагрузки используют сетевые карты напрямую: целиком или с помощью виртуальных функций, при необходимости — с поддержкой DPDK.

Балансировка трафика под задачу проекта

При необходимости проект получает отдельный балансировщик в своём пространстве имён, который может направлять данные на серверы вне кластера и проверять их готовность принимать трафик.

Сетевая связность между кластерами

Приложения могут обращаться к сервисам других кластеров по имени. При этом кластеры остаются самостоятельными и изолированными.

Как Deckhouse обеспечивает сетевую связность

Deckhouse Platform встраивает кластер в сетевую инфраструктуру дата⁠-⁠центров штатными средствами: VLAN⁠-⁠транками, сессиями eBGP и статическими маршрутами. Перестраивать сеть ЦОДа под платформу не нужно.

На узлах кластера агент расширения поднимает интерфейсы в заданных VLAN⁠-⁠сетях и обрабатывает трафик на уровне ядра. Выделенные сети заданы ресурсами Kubernetes: подсеть, диапазон адресов, параметры выдачи, MTU. Попав в такую сеть, поды и виртуальные машины получают в ней интерфейс и адрес. Адреса разных проектов могут совпадать, но это не приводит к конфликту.

Адресный план и сетевой периметр остаются за инженерами. Они один раз определяют, какие сети доступны платформе и с кем она может устанавливать сессии. Затем сети, маршруты и анонсы описываются кодом — они проходят то же ревью и выкладку, что и приложения.

Работа с расширением

NetworkClass определяет диапазон VLAN и выбирает физические интерфейсы узлов для дополнительных сетей. Команда проекта использует готовый класс и не меняет конфигурацию узлов вручную.
Deckhouse Console группирует namespaced⁠-⁠сети по пространствам имён и отображает на одном экране с кластерными. Это позволяет увидеть, как сетевые ресурсы разделены между проектами.
Namespaced⁠-⁠сеть создаётся в пространстве имён на основе выбранного сетевого класса. Платформа назначает ей VLAN и пул IP⁠-⁠адресов, после чего к сети можно подключать приложения.
Статусы показывают, готова ли сеть и запущено ли приложение. Здесь же можно проверить назначенный VLAN и пул IP⁠-⁠адресов проекта.
Приложение получает дополнительный сетевой интерфейс с адресом из проектного пула. Оно остаётся в стандартной сети Kubernetes и одновременно подключается к отдельной сети проекта.

Покажем, как настроить интеграцию c сетью дата⁠-⁠центра

Обсудим ваш сценарий использования инфраструктуры, проведём демо и подберем оптимальную конфигурацию расширения.

Часто задаваемые вопросы

В каких редакциях платформы доступны «Продвинутые сетевые возможности»?

Расширение входит в состав редакций Deckhouse Platform Ultimate и Deckhouse Platform Certified Pro. Также оно доступно как дополнение к Deckhouse Platform Core и Deckhouse Platform Certified Core.

Какие расширения нужны для запуска «Продвинутых сетевых возможностей»?

Установка других расширений не требуется.

Чем расширение отличается от сетевых возможностей в Deckhouse Platform Core?

В Deckhouse Platform Core встроена базовая сеть кластера: связность контейнеров и виртуальных машин, публикация приложений, DNS, наблюдаемость. Расширение «Продвинутые сетевые возможности» нужно там, где кластер встраивается в сеть ЦОД: анонс адресов оборудованию, выделенные сети, проброс сетевой карты, связность между кластерами.

Нужно ли расширение для запуска виртуальных машин?

Нет. В общей сети кластера виртуальные машины работают и без него. Расширение нужно, чтобы вывести виртуальные машины в выделенную сеть проекта или в сеть ЦОД.

Как сервис становится виден в сети ЦОД?

Кластер анонсирует его адрес соседним маршрутизаторам по BGP. Отдельное оборудование перед кластером и заявка на каждый сервис не нужны.

Насколько изолированы проекты друг от друга?

Каждый работает в своей VLAN⁠-⁠сети со своей адресацией: трафик не смешивается, совпадающие адреса не конфликтуют. Правила доступа внутри выделенных сетей — в дорожной карте.

Когда нужен прямой проброс сетевой карты?

Когда задержка и объём пакетов важнее универсальности: сигнальный трафик телеком⁠-⁠функций и высоконагруженные сервисы.