Краткий ответ

NetworkPolicy разрешает соединение не по имени сервиса, а по сочетанию выбранного пода назначения, источника, протокола и порта. Если хотя бы одна политика выбирает под по направлению Ingress, входящий трафик для него становится изолированным: проходят только явно разрешённые правила. Политики аддитивны, поэтому доступ разрешается объединением всех подходящих правил, а не последним применённым правилом.

Исторический контекст

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

Подход отделяет описание намерения от реализации. Оркестратор хранит и распространяет политики, а CNI-плагин применяет их с помощью доступных ему механизмов фильтрации.

Постановка проблемы

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

Ошибка часто возникает из-за предположения, что политика разрешает доступ к Service целиком. На самом деле Service только направляет соединение к подам, а NetworkPolicy проверяет трафик относительно самих подов. Неверный селектор, отсутствие метки пространства имён или закрытый исходящий трафик могут привести к недоступности.

Подробное решение

Под выбирается полем podSelector. Если хотя бы одна политика с направлением Ingress выбирает этот под, он становится изолированным для входящего трафика. Разрешённым считается трафик, который соответствует хотя бы одному правилу from и ограничениям ports из всех политик, выбирающих под.

podSelector обычно ограничивает поды в пространстве имён самой политики. namespaceSelector выбирает пространства имён по их меткам, а ipBlock задаёт диапазон IP-адресов. Если podSelector и namespaceSelector находятся в одном элементе списка источников, обычно требуется одновременное соответствие обоим условиям; отдельные элементы списка дают альтернативные варианты источника.

Минимальная политика, разрешающая фронтенду обращаться к backend на TCP-порту 8080, выглядит так:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: backend-ingress
  namespace: app
spec:
  podSelector:
    matchLabels:
      role: backend
  policyTypes: [Ingress]
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          name: web
      podSelector:
        matchLabels:
          role: frontend
    ports:
    - protocol: TCP
      port: 8080

Эта политика не делает сервис доступным сама по себе: должны существовать рабочие маршруты, корректный Service и готовые endpoints. Кроме того, для полного соединения может потребоваться разрешение Egress на стороне пода-источника; исходящий и входящий контроль рассматриваются независимо.

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

Ситуация из практики

В пространстве имён app backend был защищён default-deny-политикой. Фронтенд находился в пространстве имён web, но запросы не проходили. Рассматривались три варианта: разрешить весь трафик из web, разрешить доступ по IP-диапазону узлов или использовать селекторы подов и пространств имён.

Разрешение всего пространства web было простым, но избыточным: любой его под получил бы доступ к backend. IP-диапазон был хрупким из-за пересоздания подов и особенностей маршрутизации. Выбрали селекторы с обязательными метками name: web, role: frontend и role: backend.

После проверки также разрешили необходимый исходящий DNS-трафик и убедились, что Service направляет запросы на ожидаемые endpoints. В результате доступ восстановился только для требуемого класса клиентов, а случайные поды из web не получили автоматический доступ.

Что кандидаты часто упускают

Что произойдёт, если две политики разрешают разные источники?

Их правила объединяются. Например, одна политика может разрешить frontend, а другая — мониторинг; наличие второй не отменяет первую. Чтобы закрыть доступ, недостаточно добавить более строгую политику: уже разрешённое другой подходящей политикой соединение останется разрешённым, пока не изменены или не удалены все соответствующие правила.
Почему разрешение входящего трафика не гарантирует успешное соединение?

Для TCP-соединения исходящий трафик со стороны клиента также может быть ограничен политикой Egress. Кроме того, запрос может обращаться к DNS, а DNS-запросы — идти к подам системного сервиса, поэтому default-deny для исходящего трафика способен сломать разрешение имён ещё до попытки подключения к backend. Нужно проверять обе стороны политики, DNS и фактический маршрут.
Почему проверка доступности через ping может вводить в заблуждение?

Стандартная модель NetworkPolicy в первую очередь описывает TCP, UDP и SCTP-порты; обработка ICMP и других видов трафика может зависеть от реализации CNI и платформы. Поэтому неудачный ping не доказывает, что TCP-доступ к нужному порту запрещён. Проверять следует реальный протокол приложения, порт и логи сетевого плагина.