Профиль маршрутизации в Kubernetes: когда нужен и как настроить

В Kubernetes нет универсального API-объекта с именем профиль маршрутизации. Под этим термином обычно понимают логическую конфигурацию на Linux-узлах: таблицы маршрутизации, правила ip rule, метрики и, при необходимости, маркировку трафика через fwmark.

Такая конфигурация выбирает интерфейс, шлюз или подсеть для конкретного потока. Ее применяют, когда обычной таблицы маршрутизации недостаточно: например, на узле есть публичный и приватный интерфейсы, корпоративная сеть доступна через VPN, а разные исходные IP должны использовать разные шлюзы.

Выбор маршрута сам по себе не подтверждает доступность приложения. Для полного пути нужно отдельно проверить CNI-плагин, маршруты Pod-сетей и узлов, NetworkPolicy, обратный маршрут, firewall, NAT, порт и ответ приложения.

Что такое профиль маршрутизации в Kubernetes

Почему профиль маршрутизации не является стандартным ресурсом Kubernetes

Стандартный API Kubernetes не содержит ресурса ProfileRouting или эквивалентного объекта, который централизованно задает путь каждого пакета. Kubernetes управляет объектами вроде Pod, Service и NetworkPolicy, а policy based routing обычно настраивают на операционной системе узла.

Профиль формируют из нескольких компонентов Linux. Таблица содержит маршруты до сетей и шлюзов. Правило ip rule определяет, для какого источника, назначения, интерфейса или маркера нужно выбрать отдельную таблицу. Приоритет правила задает порядок проверки. Метрика помогает выбрать маршрут, когда несколько записей подходят для одного назначения.

На итоговое поведение влияют дистрибутив Linux, NetworkManager, systemd-networkd или Netplan, параметры ядра и способ работы CNI-плагина. CNI может создавать маршруты, туннели, правила NAT и фильтрации, а некоторые плагины строят dataplane на базе eBPF. Поэтому ручное изменение маршрута на хосте нужно сопоставлять с конфигурацией CNI и способом управления сетью узлов.

Практическая настройка таблиц, правил по исходному адресу и маркировки разобрана в материале о профиле маршрутизации Linux для нескольких интерфейсов. Для Kubernetes к этой схеме добавляются Pod-сети, Service и правила CNI.

Какие сетевые слои участвуют в доставке трафика

Слой	Что он определяет	Что проверять
Ядро Linux на узле	Интерфейс, next hop и таблицу маршрутизации	`ip rule`, маршруты, метрики, исходный адрес
CNI-плагин	Подключение Pod к сети, доставку между узлами и сетевой dataplane	Pod CIDR, туннели, host routes, NAT и правила фильтрации
Service и его dataplane	Преобразование адреса Service в адрес endpoint и распределение соединения	ClusterIP, endpoint, kube-proxy или другой механизм Service
NetworkPolicy	Разрешение или запрет соединений между workload	Направление, namespace, label, порт и протокол
Внешняя сеть	Доставку пакета к соседней подсети и возврат ответа	Маршруты, ACL, NAT, stateful firewall и обратный путь

Эти слои выполняют разные задачи. Ядро выбирает путь, CNI обеспечивает сетевую связность Pod, NetworkPolicy фильтрует разрешенные соединения, а внешние маршрутизаторы должны знать, куда возвращать ответ. Ошибка на любом участке выглядит как проблема Kubernetes, хотя причина может находиться в таблице маршрутов узла или в корпоративном firewall.

Маршрутизация в Kubernetes: сначала опишите путь конкретного потока

Какие параметры фиксировать для каждого соединения

Перед изменением маршрутов опишите конкретный поток. Одинаковая настройка редко подходит для обращения Pod к Pod, Pod к Service и Pod к внешнему API.

Источник: IP Pod, IP узла или исходная подсеть до применения NAT.
Назначение: IP другого Pod, ClusterIP, адрес endpoint, корпоративная сеть или публичный API.
Протокол и порт: TCP или UDP, например TCP 443.
Ожидаемый интерфейс и шлюз: через какой uplink, VPN или туннель должен пройти пакет.
Узел входа и узел выхода: один ли это сервер или трафик пересекает несколько узлов.
SNAT и DNAT: меняется ли исходный или адрес назначения на пути.
Обратный маршрут: каким путем удаленная сторона вернет пакет к фактическому источнику.

Для потока Pod-to-Pod обычно проверяют маршруты Pod-сетей и состояние CNI. Для Pod-to-Service нужно учитывать преобразование ClusterIP в endpoint. Для Pod-to-external нужно знать, остается ли источником адрес Pod или после SNAT им становится адрес узла. Поток external-to-Service требует проверки входного интерфейса, публикации Service и обратного пути.

Полезный шаблон записи выглядит так: источник 10.244.1.12, назначение 10.30.40.15, TCP 443, выход через tun0, SNAT на адрес VPN-узла, ответ через тот же туннель. Конкретные адреса заменяют адресами своей сети.

Как определить слой, на котором нужно исправлять проблему

Начинайте с вопроса, чего именно не хватает потоку.

Нет маршрута до Pod CIDR или между узлами. Проверяйте CNI и маршрутизаторы инфраструктуры.
Маршрут выбран, но соединение запрещено. Проверяйте NetworkPolicy, host firewall и ACL внешней сети.
Пакет уходит через неправильный шлюз из-за исходного IP. Настраивайте policy based routing на нужном узле.
Запрос проходит, ответ теряется. Ищите асимметрию, SNAT, отсутствие обратного маршрута и ограничения stateful firewall.
TCP-соединение доходит до узла, но приложение не отвечает. Проверяйте процесс, bind-адрес, порт и авторизацию.

Такая последовательность экономит время: правило маршрутизации не исправит запрет NetworkPolicy, а NetworkPolicy не создаст маршрут до корпоративной подсети. Базовые механизмы Pod-сетей, Service и диагностики собраны в руководстве по маршрутизации трафика между Pod и Service.

Когда профиль маршрутизации действительно нужен

Несколько интерфейсов, шлюзов и исходных IP-адресов на узле

Основной сценарий policy based routing возникает у узла с двумя сетевыми путями. Например, eth0 подключен к публичной сети, а eth1 ведет в приватный сегмент. Маршрут по умолчанию через eth0 не гарантирует правильный ответ на запрос, который пришел через eth1 или был отправлен с приватного IP.

Если ответ выберет другой uplink, появится асимметричная маршрутизация. Удаленный firewall может отбросить пакет, потому что не видел начало сессии на этом интерфейсе. Проблема проявляется для части соединений: ping иногда проходит, а TCP или доступ к конкретному API завершается тайм-аутом.

Отдельная таблица и правило по исходному адресу позволяют связать поток с нужным шлюзом:

ip rule add from 10.20.0.10/32 table private priority 100
ip rule add from 203.0.113.10/32 table public priority 110

Профиль не нужен узлу с одним интерфейсом, одним шлюзом и обычной destination-based маршрутизацией. В такой схеме дополнительные таблицы усложнят диагностику без практической пользы.

Доступ Pod-приложений к корпоративным сетям, VPN и внешним API

Выделенный путь нужен, когда адреса из корпоративной сети доступны через VPN, отдельный маршрутизатор или egress-интерфейс. Например, запросы к сети 10.30.40.0/24 должны уходить через tun0, а публичные адреса оставаться на основном uplink.

Если назначение однозначно связано с одной сетью, достаточно обычного маршрута. Policy based routing добавляют, когда один и тот же адрес назначения должен обслуживаться разными путями для разных источников или когда маршруты пересекаются.

Проверьте адрес источника после NAT. Если CNI или узел заменяет IP Pod на адрес узла, правило по Pod CIDR не сработает на том этапе, где ядро уже видит адрес узла. Для egress-схемы нужно согласовать таблицу маршрутов, SNAT, разрешенные адреса на VPN и обратный маршрут со стороны корпоративной сети.

Связь между подсетями и гибридной инфраструктурой

Связь между Pod CIDR, node CIDR, виртуальными машинами, дата-центром и облаком начинается с согласованной адресной схемы. Пример диапазонов 10.244.0.0/16 для Pod и 10.96.0.0/12 для Service не универсален. Эти сети нельзя использовать без проверки пересечений с корпоративными и VPN-подсетями.

Внешняя сеть должна знать, через какой узел доступен каждый Pod CIDR, либо трафик нужно преобразовывать через SNAT. На узлах должны работать forwarding и правила CNI, а обратный путь до источника должен оставаться доступным. Если один и тот же корпоративный сегмент виден через несколько шлюзов, профиль маршрутизации помогает выбирать путь по источнику, назначению или метке.

Для лабораторного кластера с несколькими сетевыми сегментами можно использовать облачную инфраструктуру с VDS и Kubernetes, например Timeweb Cloud. Перед проверкой маршрутов зафиксируйте CIDR кластера и правила сети провайдера, чтобы тест не смешивал ошибки Kubernetes с ограничениями внешней инфраструктуры.

Как Linux выбирает маршрут на Kubernetes-узле

Таблицы маршрутизации, правила ip rule и приоритеты

Linux сначала обрабатывает правила из ip rule. Правила проверяются по приоритету, обычно меньшее числовое значение означает более раннюю проверку. Правило может учитывать исходный адрес, адрес назначения, входной интерфейс, выходной интерфейс или fwmark.

В типичной конфигурации присутствуют системная таблица локальных адресов, основная таблица main и таблица default. Администратор может добавить отдельные таблицы, например public, private или vpn. После выбора таблицы ядро ищет подходящий маршрут по назначению и учитывает метрику, если несколько маршрутов конкурируют.

Порядок правил нужно задавать явно. Пересекающиеся диапазоны, одинаковые приоритеты и неочевидное продолжение обработки после отсутствия маршрута создают ситуации, когда один поток идет ожидаемым путем, а другой использует main. Проверка начинается с команд:

ip rule show
ip route show table all

Подробная шпаргалка по ip route, таблицам, NAT и policy routing для Linux доступна в материале по базовой настройке маршрутизации.

Зачем в отдельной таблице нужен connected-маршрут до шлюза

Отдельная таблица должна содержать маршрут до сети, в которой находится шлюз. Записи с одной строкой default via 203.0.113.1 недостаточно, если выбранная таблица не знает, как достичь самого адреса 203.0.113.1.

Пример для интерфейса eth1 с адресом 203.0.113.10/24:

ip route add 203.0.113.0/24 dev eth1 src 203.0.113.10 table public
ip route add default via 203.0.113.1 dev eth1 table public
ip rule add from 203.0.113.10/32 table public priority 110

Первая строка описывает connected-маршрут до непосредственно подключенной сети. Вторая задает шлюз по умолчанию в этой таблице. Третья связывает исходный IP с таблицей. Интерфейс, адреса и приоритеты в примере нужно заменить на реальные значения, а возможность использовать шлюз следует проверить у сетевой команды или в конфигурации сегмента.

Как маркировка fwmark расширяет правила выбора пути

Правило по исходному IP подходит, когда сервисы используют стабильные адреса. При динамических адресах Pod, разных портах или сложной классификации трафика можно применить связку nftables и fwmark. Фильтр помечает пакет, а ip rule выбирает таблицу по этой метке.

ip rule add fwmark 0x20/0xff table vpn priority 120

Само правило не создает метку. Ее должен поставить согласованный набор правил фильтрации. Нужно проверить порядок обработки, сохранение метки для нужных пакетов и взаимодействие с правилами CNI. Перехват трафика на неправильном этапе может привести к тому, что маркировка не будет применяться к ответным пакетам или исчезнет после NAT.

Граница между CNI-плагином, NetworkPolicy и маршрутами узлов

Что обычно контролирует CNI-плагин

CNI-плагин подключает Pod к сети и определяет, как пакет покидает сетевое пространство имен Pod. В зависимости от выбранного решения он может выдавать IP-адреса, создавать veth-пары, настраивать host routes или туннели, программировать NAT и фильтрацию, а для некоторых dataplane использовать eBPF.

Одинаковые команды на разных CNI не дают одинаковый результат. Один плагин может полагаться на маршруты между узлами, другой на туннель, третий на eBPF-программы. Перед ручным изменением маршрутов выясните, кто создает запись, какие диапазоны Pod использует кластер и что происходит после перезапуска агента CNI.

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

Почему NetworkPolicy не заменяет маршрутизацию

NetworkPolicy задает разрешенные направления соединений и условия доступа: namespace, label Pod, порт и протокол. Политика может запретить приложению обращаться к базе данных или разрешить ingress только от определенного набора workload, если это поддерживает CNI.

NetworkPolicy не создает маршрут, не выбирает интерфейс и не назначает шлюз. Политика не исправит отсутствие обратного маршрута и не заменит SNAT. Если пакет не знает, куда идти, сначала исправляют связность CNI или сети узлов. Если путь есть, но соединение запрещено, проверяют NetworkPolicy и firewall.

Как Service и NAT меняют видимый путь пакета

Приложение обращается к ClusterIP, но конечный пакет может пойти к конкретному endpoint. Механизм Service, например kube-proxy или другой dataplane, преобразует адрес назначения и выбирает backend. Диагностика по одному ClusterIP не показывает весь фактический путь.

Исходный адрес тоже может измениться. При SNAT внешний сервер видит IP узла или egress-шлюза, а не IP Pod. Поэтому правило по источнику нужно проверять на том участке пути, где этот адрес еще существует. Для каждого этапа фиксируйте исходный и конечный IP, интерфейс и наличие DNAT или SNAT.

Типовые сценарии настройки без смешения инструментов

Изоляция трафика между сервисами

Для изоляции east-west-трафика базовым механизмом служит NetworkPolicy. Начните с default deny для namespace, затем разрешите конкретные направления по label и портам. Такой подход ограничивает доступ, но не меняет маршрут.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
  namespace: production
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

После применения политики добавьте отдельные разрешения для DNS, API и базы данных, если они нужны приложению. Например, frontend может получать TCP 8080 от ingress, а backend может обращаться к базе по TCP 5432. Точный синтаксис селекторов зависит от меток в вашем кластере.

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

Выход к внешним ресурсам через выделенный шлюз

Предположим, запросы Pod к корпоративному API должны идти через VPN, а остальные внешние запросы через публичный uplink. Сначала определите исходный адрес на узле, потому что после SNAT им может стать IP узла.

Создайте отдельную таблицу для VPN-пути.
Добавьте в нее connected-маршрут до сети VPN-шлюза.
Добавьте маршрут к корпоративному CIDR через туннель или выделенный next hop.
Свяжите таблицу с источником, назначением или fwmark с явным приоритетом.
Проверьте SNAT и обратный маршрут на стороне корпоративной сети.

Если целевая сеть уникальна и не пересекается с другими маршрутами, отдельное правило может не понадобиться. Если для одного назначения требуется разный путь по источнику, policy based routing становится оправданным. Egress-механизм CNI может решать задачу на уровне кластера, но его возможности зависят от конкретного плагина и его конфигурации.

Маршрутизация между Pod-сетями, узлами и внешними подсетями

Для связи Pod на разных узлах проверьте маршруты между Pod CIDR и node CIDR. CNI должен знать, как доставить пакет к удаленному Pod, а внешняя сеть не должна пересекать эти диапазоны с корпоративными подсетями.

Если внешний сервер обращается к Pod напрямую, ему нужен маршрут к Pod CIDR через нужный узел или маршрутизатор. При использовании SNAT внешний сервер возвращает ответ на адрес узла, а узел передает его Pod. Оба варианта рабочие, но требуют разных правил firewall и диагностики.

Policy based routing добавляют, когда путь зависит от характеристики потока. Для обычной связности между уникальными подсетями достаточно согласованных маршрутов CNI и инфраструктурной сети. Ручное правило на одном узле не исправит отсутствие маршрута на остальных узлах.

Безопасная настройка и проверка профиля маршрутизации

Порядок внедрения изменений

Сохраните исходное состояние: адреса интерфейсов, таблицы маршрутов, правила, NAT и параметры firewall.
Опишите поток с источником, назначением, портом, интерфейсом, шлюзом и ожидаемым обратным путем.
Выберите свободный номер таблицы и понятное имя, например 200 vpn.
Добавьте connected-маршрут до сети шлюза и маршрут до целевой сети или маршрут по умолчанию.
Добавьте ip rule с явным приоритетом, не перекрывающим системные правила.
Проверьте расчет маршрута командой ip route get с реальным источником.
Проверьте фактический пакет, ответ, NAT и состояние соединения.
Перенесите рабочие параметры в NetworkManager, systemd-networkd, Netplan или другой механизм, который управляет сетью узла.

Первые изменения выполняйте на одном узле или тестовом кластере. Сохраните консольный доступ к серверу: ошибочное правило по умолчанию может разорвать SSH-сессию и доступ к управляющей сети.

Команды для проверки выбора маршрута

Полный набор таблиц и порядок правил смотрят отдельно:

ip addr show
ip rule show
ip route show table all

Проверка с заданным источником показывает, какой маршрут Linux выберет для конкретного потока:

ip route get 198.51.100.25 from 203.0.113.10
ip route get 10.20.0.15 from 10.244.1.12

Адрес 203.0.113.10 в примере должен принадлежать узлу. Если источник не назначен интерфейсу или не соответствует этапу до NAT, результат не описывает реальный пакет. Для Pod-потока проверяйте маршрут в правильном сетевом пространстве и отдельно на узле, через который пакет выходит.

Как подтвердить фактическое прохождение трафика

Расчет маршрута нужно сопоставить с захватом пакетов. Для общей проверки подойдет:

tcpdump -ni any host 10.20.0.15

Захват на конкретном интерфейсе дает более точный результат, например на tun0 или eth1. Сравните исходный и конечный адреса, наличие ответа и направление каждого пакета.

Проверьте доступность самого шлюза.
Проверьте маршрут и фильтрацию на следующем узле.
Проверьте обратный маршрут до фактического источника.
Проверьте SNAT, DNAT и правила firewall.
Проверьте, слушает ли приложение нужный TCP или UDP-порт.
Проверьте ответ приложения и его авторизацию.

Команда ip route get подтверждает решение ядра. Она не подтверждает, что пакет прошел через VPN, был принят удаленным firewall или обработан приложением.

Ошибки, из-за которых маршрутизация в Kubernetes работает непредсказуемо

Асимметричная маршрутизация и reverse path filtering

Асимметрия возникает, когда запрос приходит через один интерфейс, а ответ выбирает другой. Причины включают второй маршрут по умолчанию, пересекающиеся подсети, неправильный приоритет ip rule и неверный next hop.

Механизм reverse path filtering, или rp_filter, проверяет ожидаемый обратный путь. При несовпадении интерфейса входа и результата проверки ядро может отбросить пакет. Симптомом становится односторонняя связь: SYN приходит, но ответный SYN-ACK не покидает узел или теряется на firewall.

Проверьте текущие значения:

sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf.default.rp_filter

Изменять rp_filter вслепую нельзя. Сначала зафиксируйте требуемую схему обратного пути, требования безопасности и поведение всех интерфейсов. Для диагностики асимметрии полезен отдельный разбор причин и способов проверки асимметричной маршрутизации.

Пересекающиеся подсети, метрики и конфликтующие правила

Проверьте, что Pod CIDR, Service CIDR, node CIDR, VPN-сети и корпоративные диапазоны не пересекаются.
Сравните приоритеты всех ip rule и убедитесь, что более общее правило не срабатывает раньше специального.
Проверьте метрики маршрутов с одинаковым или близким назначением.
Добавьте connected-маршрут до next hop в каждую отдельную таблицу.
Проверьте, что SNAT не меняет источник раньше, чем срабатывает нужное правило.
Сравните конфигурацию всех узлов, через которые проходят Pod-пакеты.
Убедитесь, что ручные маршруты не конфликтуют с правилами агента CNI.

Схему адресов, таблиц, правил, NAT и обратных маршрутов храните вместе с документацией кластера. Это сокращает время поиска ошибки, когда проблема возникает только на одном узле или для одной подсети.

Краткий критерий: нужен ли отдельный профиль

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

Для связности Pod-сетей используйте возможности CNI. Для ограничения доступа между сервисами применяйте NetworkPolicy. Для простого узла с одним выходом оставляйте основную таблицу маршрутизации.

Нужен выбор шлюза по источнику, используйте ip rule from.
Нужен путь к отдельной сети через VPN, добавьте маршрут к целевому CIDR и проверьте возврат.
Нужна изоляция сервисов, настройте NetworkPolicy.
Нет маршрута между Pod и узлами, проверяйте CNI и инфраструктурные маршрутизаторы.
Пакет уходит, но ответ не приходит, ищите асимметрию, NAT, firewall и rp_filter.

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