/ru2/cluster-admin/networking/ Recent content in Управление сетями on Hugo -- gohugo.io Wed, 01 Jul 2026 19:41:08 +0300 /ru2/cluster-admin/networking/architecture/ Wed, 01 Jul 2026 19:41:08 +0300 /ru2/cluster-admin/networking/architecture/ Общая схема сетей кластера # Сетевой слой в кластере строится вокруг модулей: Cilium CNI (shturval-networking) — базовая сеть подов и сервисов; Ingress‑контроллеры (shturval-ingress-controller) — входящий HTTP/HTTPS‑трафик; Gateway API — модель маршрутизации (GatewayClass, Gateway, HTTPRoute и др.); Egress Gateway — управляемый исходящий трафик с предсказуемыми IP; Дополнительные сети — SR‑IOV и Multus для высокопроизводительных и изолированных сценариев; Сетевые политики Cilium — разграничение трафика между подами и сервисами. На практике это выглядит так: /ru2/cluster-admin/networking/gateway-api/ Wed, 01 Jul 2026 19:41:08 +0300 /ru2/cluster-admin/networking/gateway-api/ Начиная с релиза 2.14, в платформе «Штурвал» доступно управление объектами Gateway API в GUI. Это помогает подготовиться к переходу с Nginx Ingress Controller на Gateway API и упростить настройку маршрутизации для разных реализаций Service Mesh (Istio, Cilium и др.). Gateway API и ролевая модель: Объект Уровень Кто настраивает Назначение GatewayClass Кластер Поставщик инфраструктуры Тип контроллера и параметры реализации Gateway Кластер Оператор кластера Точка входа: адреса, обработчики (listeners), TLS Маршруты (HTTPRoute, GRPCRoute) Неймспейс Разработчик / владелец приложения Прикладная маршрутизация к backend-сервисам Где настраивать в GUI: /ru2/cluster-admin/networking/ingress/ Wed, 01 Jul 2026 19:41:08 +0300 /ru2/cluster-admin/networking/ingress/ Обзор # Страница Ingress Controllers содержит список Ingress-контроллеров, созданных в кластере. Ingress-контроллер управляет входящим трафиком неймспейсов кластера. На странице Ingress Controllers можно создать, отредактировать, удалить или просмотреть ранее созданные Ingress Controller. Системный Ingress Controller # По умолчанию в кластере для всех неймспейсов разворачивается системный Ingress Controller с именем ingress. При добавлении в кластер нового неймспейса он автоматически включается в список неймспейсов, для которых должен быть настроен входящий трафик. Для системного Ingress Controller значение * в колонке неймспейсов означает включение всех неймспейсов. /ru2/cluster-admin/networking/gateway-classes/ Wed, 01 Jul 2026 15:33:26 +0300 /ru2/cluster-admin/networking/gateway-classes/ GatewayClass — класс доступных Gateways описывает какой контроллер будет обрабатывать Gateways. Каждый GatewayClass может реализовывать один контроллер (например, Nginx, Envoy, Istio). Где настраивать: кластер → раздел Сети → Gateway Classes. Через кастомные ресурсы: кластер → раздел Администрирование → Кастомные ресурсы → API-группа gateway.networking.k8s.io → GatewayClass. На странице Gateway Classes отображается список ресурсов GatewayClass со сведениями: Колонка Описание Имя Имя созданного вручную или автоматически GatewayClass. GatewayClass могут быть созданы автоматически при развертывании контроллера Gateway API Контроллер Значение spec. /ru2/cluster-admin/networking/gateways/ Wed, 01 Jul 2026 15:33:26 +0300 /ru2/cluster-admin/networking/gateways/ Gateway — экземпляр инфраструктуры обработки трафика, конфигурация которого определяет: адреса, обработчики (listeners) и политики привязки маршрутов. Каждый Gateway связан с GatewayClass, который описывает фактический тип контроллера обработки трафика для Gateway. Gateway создаётся в неймспейсе кластера, управление доступно на уровне кластера. Где настраивать: кластер → раздел Сети → Gateways. Через кастомные ресурсы: кластер → раздел Администрирование → Кастомные ресурсы → API-группа gateway.networking.k8s.io → Gateway. На странице Gateways отображается список созданных в кластере Gateways. /ru2/cluster-admin/networking/egress-gateway/ Wed, 01 Jul 2026 19:41:08 +0300 /ru2/cluster-admin/networking/egress-gateway/ Обзор # Страница Egress Gateway содержит список Cilium Egress Gateway Policies, созданных в кластере. Ресурс Cilium Egress Gateway Policy определяет способ маршрутизации и доступа во внешнюю сеть из подов с предсказуемым IP-адресом или интерфейсом. Поскольку у подов постоянно меняются IP-адреса, Cilium Egress Gateway Policy может быть полезен в случаях, когда для трафика требуется известный исходный IP-адрес или интерфейс. На странице Egress Gateway можно создать, отредактировать, удалить или просмотреть ранее созданные Egress Gateway. /ru2/cluster-admin/networking/additional-network/ Wed, 01 Jul 2026 19:41:08 +0300 /ru2/cluster-admin/networking/additional-network/ Обзор # Дополнительные сети позволяют использовать пользовательские сети в дополнение к основному CNI Cilium. Для SR-IOV используются ресурсы SriovNetworkNodePolicy и SriovNetwork; для пользовательских сетей при установленном модуле shturval-metacni используется NetworkAttachmentDefinition. SR-IOV # SR-IOV позволяет подключать контейнеры непосредственно к сетевому оборудованию. Ресурсы SriovNetworkNodePolicy и SriovNetwork связаны между собой и вместе обеспечивают управление сетевыми настройками SR-IOV на уровне узла. Все ресурсы SR-IOV должны находиться в том же неймспейсе, где установлен SRIOV-Operator. В интерфейсе для этих ресурсов автоматически применяется неймспейс kube-system. /ru2/cluster-admin/networking/network-policies/ Wed, 01 Jul 2026 19:41:08 +0300 /ru2/cluster-admin/networking/network-policies/ Обзор # Сетевые политики Cilium ограничивают, какой трафик может приходить в поды (Ingress) и уходить из подов (Egress). Без политик весь трафик разрешён. После добавления хотя бы одной политики для неймспейса или пода действует принцип «запрещено всё, что не разрешено явно». Где настраивать: Сетевые политики в разделе сетей кластера или Администрирование → Кастомные ресурсы. Политики можно создавать через графический интерфейс или импорт манифеста. Скриншот: статус сетевой политики Важно: как работают политики # Поведение по умолчанию # Ситуация Результат В неймспейсе нет сетевых политик Весь трафик разрешён (входящий и исходящий) В неймспейсе есть хотя бы одна политика Разрешён только трафик, явно описанный в правилах. /ru2/cluster-admin/networking/troubleshooting/ Wed, 01 Jul 2026 15:33:26 +0300 /ru2/cluster-admin/networking/troubleshooting/ Обзор # На этой странице — как проверить настроенный Ingress и Egress. Рекомендации по созданию сетевых политик — в Справочной информации. Проверка Ingress # 1. Проверка подов Ingress Controller # kubectl get pods -n ingress -l app.kubernetes.io/name=shturval-ingress-controller Убедитесь, что поды в состоянии Running. 2. Проверка Service и LoadBalancer # kubectl get svc -n ingress Проверьте, что у Ingress Service есть внешний IP (тип LoadBalancer) или что используется NodePort/другой механизм доступа. /ru2/cluster-admin/networking/reference/ Wed, 01 Jul 2026 15:33:26 +0300 /ru2/cluster-admin/networking/reference/ Обзор # На этой странице — рекомендации по созданию и настройке сетевых политик Cilium. Best practices для сетевых политик # 1. Принцип наименьших привилегий # Разрешайте только необходимый трафик. Вместо «разрешить всё» — явно укажите разрешённые направления, порты и селекторы. 2. Начинайте с разрешающих правил # Сначала определите, какой трафик нужен приложению (DNS, KubeAPI, backend-сервисы), и добавьте разрешающие правила. Запрещающие правила добавляйте точечно. 3. Всегда разрешайте DNS # Если поды обращаются по имени (FQDN, Service), разрешите egress к Kubernetes DNS: