Архитектурные схемы сетей кластера

Как устроен сетевой слой в кластере и как взаимодействуют его ключевые компоненты.

Общая схема сетей кластера

Сетевой слой в кластере строится вокруг модулей:

  • Cilium CNI (shturval-networking) — базовая сеть подов и сервисов;
  • Ingress‑контроллеры (shturval-ingress-controller) — входящий HTTP/HTTPS‑трафик;
  • Gateway API — модель маршрутизации (GatewayClass, Gateway, HTTPRoute и др.);
  • Egress Gateway — управляемый исходящий трафик с предсказуемыми IP;
  • Дополнительные сети — SR‑IOV и Multus для высокопроизводительных и изолированных сценариев;
  • Сетевые политики Cilium — разграничение трафика между подами и сервисами.

На практике это выглядит так:

  1. Cilium CNI подключает все поды к единой overlay/underlay‑сети, обеспечивает маршрутизацию и сервис‑discovery (ClusterIP, kube‑proxy/cilium‑proxy).
  2. Ingress‑контроллеры принимают внешний трафик на узлах (через VIP, NodePort/hostPort) и маршрутизируют его к сервисам внутри кластера.
  3. Egress Gateway перенаправляет исходящий трафик определённых подов/неймспейсов через выделенные узлы/адреса.
  4. Дополнительные сети добавляют вторичные интерфейсы к подам (через Multus/SR‑IOV), не нарушая работу основной сети Cilium.
  5. Сетевые политики определяют, какие потоки (pod → pod, pod → сервис, pod → внешний ресурс) разрешены или запрещены.

Подробнее о подсетях и диагностике пересечений CIDR см. раздел
Диагностика пересечения подсетей в кластере.
Схемы межсетевого взаимодействия (порты и направления трафика между кластерами, балансировщиками и внешними системами) сверяйте по страницам требований открытого контура и закрытого контура.

Используемые подсети

По умолчанию при создании кластера в платформе выделяются:

  • подсеть подов: 172.16.0.0/16;
  • подсеть сервисов: 10.96.0.0/12.

Диапазоны подсетей могут быть изменены под ваши требования. Рекомендуется до создания кластера проверять диапазоны на пересечения (например, с помощью онлайн‑калькулятора подсетей).

Подсети подов и сервисов располагаются в общей overlay‑сети кластера. Эти подсети:

  • существуют только внутри кластера;
  • не пересекаются с другими кластерами и вашей корпоративной сетью по уровню маршрутизации;
  • даже при совпадении адресного пространства с корпоративной сетью не дают подам прямого доступа к сервисам вне кластера без явной настройки шлюзов/NAT. (см. скриншот ниже)

Используемые подсети

Пример использования подсетей

На каждом узле кластера из общей подсети подов выделяется отдельная подсеть. Если в кластере разрешён исходящий трафик, по умолчанию весь исходящий трафик будет выходить от IP‑адреса узла.

Иллюстрация: Пример использования подсетей

Пример использования подсетей

С учётом этого:

  • для управления исходящим трафиком по IP‑адресам используются механизмы Egress Gateway и соответствующие политики;
  • для управления входящим трафиком в кластер применяются Ingress‑контроллеры и сетевые политики Cilium.

Подробнее о настройке сетей кластера:

Взаимодействие Ingress и базовой сети

Ingress‑контроллеры работают поверх базовой сети Cilium:

  • системный Ingress Controller обслуживает все неймспейсы по умолчанию;
  • дополнительные Ingress‑контроллеры позволяют выделять отдельные IP/домены/неймспейсы.

Типичный поток:

  1. Внешний клиент обращается по DNS‑имени на виртуальный IP или на адрес узлов (NodePort/hostPort).
  2. Трафик попадает на Ingress Controller, который по правилам Ingress‑ресурсов выбирает целевой сервис.
  3. Cilium доставляет трафик от выбранного сервиса до нужных подов.

Подробнее о настройке Ingress и сценариях:

Gateway API и базовая сеть

Gateway API включает основные типы объектов:

  • GatewayClass задаёт тип контроллера на уровне кластера;
  • Gateway описывает точку входа (например, внешний балансировщик нагрузки) и определяет: адреса, порты, протоколы, TLS-конфигурацию обработчиков;
  • Маршруты (HTTPRoute, GRPCRoute) связывает Gateway с backend‑сервисами в неймспейсе и определяют детальные правила маршрутизации для HTTP/HTTPS или gRPC трафика.

Подробнее:

Взаимодействие Egress Gateway с кластерами

Egress Gateway используется, когда важно, с какого IP‑адреса выходят запросы к внешним системам (фаерволы, внешние API, базы данных).

Общая логика:

  1. Администратор задаёт Egress Gateway Policy (для неймспейса, подов или меток).
  2. Cilium перенаправляет исходящий трафик подходящих подов через выделенный узел или IP‑адрес.
  3. Внешние системы видят запросы от заранее согласованных адресов.

Подробнее о настройке:

CoreHA и внешний балансировщик

Для сценариев, где внешний балансировщик (например, HAProxy) должен динамически узнавать активные узлы с Ingress‑контроллером, используется модуль CoreHA (shturval-coreha).

На схеме ниже показан типичный трафик, см. иллюстрацию ниже.

Схема трафика CoreHA

Ключевые моменты:

  1. В кластере работает модуль shturval-coreha, который отслеживает поды Ingress‑контроллера с нужными метками и формирует DNS‑записи.
  2. Внешний балансировщик (HAProxy) запрашивает DNS‑имена, сформированные CoreHA, и получает актуальный список IP‑адресов узлов с Ingress‑подами.
  3. Трафик от клиентов приходит на HAProxy и далее распределяется между узлами кластера по этим IP‑адресам.
  4. При изменении состава узлов/подов (scale‑up/scale‑down) CoreHA обновляет DNS‑записи, а балансировщик автоматически подхватывает изменения.

Подробнее о модуле и примерах конфигурации см. страницу
Модуль поиска узлов с запущенными hostport сервисами (shturval-coreha).

Дополнительные сети и SR‑IOV

Для сценариев с высокой пропускной способностью и жёсткими требованиями к сетевой изоляции используются:

  • Multus (shturval-metacni) — добавляет к подам несколько сетевых интерфейсов;
  • Whereabouts (shturval-metacni-ipam) — управляет IP‑адресами на вторичных интерфейсах;
  • SR‑IOV Operator (shturval-sriov) — выделяет виртуальные функции (VF) физических NIC и подключает их к подам.

Типичный поток:

  1. Приложение получает основной интерфейс от Cilium для служебного/управляющего трафика.
  2. Через Multus к поду добавляется вторичный интерфейс (SR‑IOV, отдельная L2/L3‑сеть).
  3. Whereabouts назначает IP‑адреса, SR‑IOV Operator управляет профилями и пулами VF.

Подробнее:

Сетевые политики Cilium

Сетевые политики Cilium задают, кто и куда может ходить в пределах кластера и между кластерами:

  • CiliumNetworkPolicy и ClusterwideCiliumNetworkPolicy описывают допустимые потоки;
  • политики могут фильтровать как L3/L4‑трафик, так и L7‑запросы (HTTP, DNS и др.);
  • политики применяются поверх базовой сети Cilium и учитывают метки подов/неймспейсов.

Архитектурно это выглядит так:

  1. Администратор определяет политики для неймспейсов и приложений.
  2. Cilium агент на каждом узле применяет политики к локальным подам (BPF‑программы).
  3. Любой трафик, не удовлетворяющий политике, отбрасывается до того, как покинет узел или попадёт к целевому поду.

Подробнее:

← Траблшутинг логирования
Gateway API →