Сетевые политики (Network Policies)#

Если необходимо управлять потоком трафика на уровне IP-адреса или порта (уровень OSI 3 или 4), то можно рассмотреть возможность использования NetworkPolicies для конкретных приложений в кластере DropApp. Сетевые политики – это конструкция, ориентированная на приложения, которая позволяет указать, как pod разрешено взаимодействовать с различными сетевыми «объектами» (термин «объект» используется здесь, чтобы избежать перегрузки более распространенных терминов, таких как «конечные точки» и «службы», которые имеют специфические коннотации DropApp) по сети. Сетевые политики применяются к соединению с pods на одном или обоих концах и не имеют отношения к другим подключениям.

Объекты, с которыми pod может взаимодействовать, идентифицируются с помощью комбинации следующих 3 идентификаторов:

• других pod, которые разрешены (исключение: pod не может заблокировать доступ к себе);

• разрешенные пространства имен;

• IP-блоки (исключение составляет трафик к узлу, на котором запущен pod. С этого узла трафик всегда разрешен, независимо от IP-адреса pod или самого узла).

При определении сетевой политики на основе pod или пространства имен используйте селектор, чтобы указать, какой трафик разрешен для и из pod, которые соответствуют селектору. Когда создаются сетевые политики на основе IP, пользователи определяют политики на основе блоков IP (диапазонов CIDR).

Сетевые политики реализуются с помощью сетевого плагина. Чтобы использовать сетевые политики, необходимо использовать сетевое решение, поддерживающее NetworkPolicy. Создание ресурса NetworkPolicy без контроллера, который его реализует, не будет иметь эффекта.

Два вида изоляции pod#

Существует два вида изоляции для pod: изоляция для «Egress» и изоляция для «Ingress». Они касаются того, какие соединения могут быть установлены. «Изоляция» здесь не является абсолютной, скорее это означает «применяются некоторые ограничения». Альтернатива «неизолированный для $direction означает, что в указанном направлении не применяются никакие ограничения. Два вида изоляции (или более, чем два вида) объявляются независимо, и оба имеют отношение к соединению от одного pod к другому.

По умолчанию pod не изолирован для выхода: разрешены все исходящие подключения. Pod изолирован для выхода, если существует какая-либо сетевая политика, которая одновременно выбирает pod и имеет «Egress» в своем policyTypes. Когда pod изолирован для выхода, единственными разрешенными подключениями из pod являются те, которые разрешены Egress списком сетевой политики и применяются к pod.

По умолчанию pod не изолирован для входа: разрешены все входящие подключения. Pod изолирован для входа, если существует какая-либо сетевая политика, которая одновременно выбирает pod и имеет Ingress в policyTypes: такая политика применяется к pod для входа. Когда pod изолирован для входа, единственными разрешенными подключениями к pod являются соединения с узла pod и те, которые разрешены Ingress списком сетевой политики и применяются к pod для входа.

Сетевые политики не конфликтуют: они дополняют друг друга. Если какая-либо политика или положения применяются к данному pod для данного направления, соединения, разрешенные в этом направлении из этого pod, являются объединением того, что разрешено применимыми политиками. Таким образом, порядок оценки не влияет на результат политики.

Для того чтобы соединение из pod источника в pod назначения было разрешено, необходимо разрешить подключение как политикой Ingress в pod источника, так и политикой Egress в pod назначения. Если какая-либо из сторон не разрешает подключение, этого не произойдет.

Ресурс сетевой политики#

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

service/networking/networkpolicy.yaml Скопируйте сервис / сеть/networkpolicy.yaml в буфер обмена
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: test-network-policy
namespace: default
spec:
podSelector:
matchLabels:
role: db
policyTypes:
- Ingress
- Egress
ingress:
- from:
- ipBlock:
cidr: NNN.NN.0.0/16
except:
- NNN.NN.1.0/24
- namespaceSelector:
matchLabels:
project: myproject
- podSelector:
matchLabels:
role: frontend
ports:
- protocol: TCP
port: 6379
egress:
- to:
- ipBlock:
cidr: MM.M.M.0/24
ports:
- protocol: TCP
port: 5978

Где NNN.NN.0.0/16, NNN.NN.1.0/24, MM.M.M.0/24 – выбранные подсети.

Обязательные поля (Mandatory Fields): как и во всех других конфигурациях DropApp, для сетевой политики необходимы поля apiVersion, kind и metadata.

Спецификация (spec): спецификация NetworkPolicy содержит всю информацию, необходимую для определения конкретной сетевой политики в данном пространстве имен.

Pod-cелектор (podSelector): каждая сетевая политика включает в себя podSelector, выбирающий группировку pod, к которым применяется политика. В примере политики выбираются pod с меткой role=db. Пустое значение podSelector выбирает все pod в пространстве имен.

Типы политик (policyTypes): каждая сетевая политика включает в себя policyTypes список, который может включать в себя ingress, egress или сразу оба типа. Поле policyTypes указывает, применяется ли данная политика к входящему трафику в выбранный pod, исходящему трафику из выбранных pod или к обоим типам. Если в сетевой политике указано не policyTypes, то по умолчанию всегда будет установлено ingress, а egress установится, если сетевая политика имеет какие-либо правила выхода.

Вход (ingress): каждая сетевая политика может включать список разрешенных ingress-правил. Каждое правило разрешает трафик, соответствующий разделам from и ports. Пример политики (представлен выше) содержит единственное правило, которое сопоставляет трафик на одном порту с одним из трех источников, первый из них указан через ipBlock, второй через namespaceSelector, а третий через podSelector.

Выход (egress): каждая сетевая политика может содержать список разрешенных egress-правил. Каждое правило разрешает трафик, соответствующий разделам to и ports. Пример политики (представлен выше) содержит единственное правило, которое сопоставляет трафик по одному порту в любой выбранной подсети (в примере MM.M.M.0/24).