Миграция из диспетчера сетевых политик (NPM) в политику сети Cilium

В этой статье мы предоставляем комплексное руководство по планированию, выполнению и проверке миграции из диспетчера политик сети (NPM) в политику сети Cilium. Цель заключается в обеспечении четности политик, минимизации нарушений работы служб и согласовании стратегического направления Azure CNI в отношении сетевых подключений на основе eBPF и повышенной наблюдаемости.

Основные рекомендации перед началом работы

• Совместимость политик: NPM и Cilium отличаются в моделях применения. Перед миграцией необходимо проверить совместимость существующих политик или определить необходимые изменения. Обратитесь к разделу проверки предварительной миграции за рекомендациями.
• Ожидания простоя: применение политик может быть временно несогласованным во время перепроецирования узла.
• Пулы узлов Windows: Сетевая политика Cilium в настоящее время не поддерживается для узлов Windows в AKS.

Предварительная проверка миграции

Прежде чем переходить с диспетчера сетевых политик (NPM) на политику сети Cilium, важно оценить совместимость существующих политик сети. Хотя большинство политик продолжают функционировать должным образом после миграции, существуют определенные сценарии, в которых поведение может отличаться от NPM и Cilium. Эти различия могут потребовать обновления политик до или после миграции, чтобы обеспечить согласованное применение и избежать непреднамеренного падения трафика. В этом разделе описаны известные сценарии, в которых могут потребоваться корректировки политики. Мы объясняем, почему это важно, и предоставляем рекомендации по необходимым действиям, если таковые имеются, для обеспечения совместимости ваших политик с Cilium.

NetworkPolicy с endPort

Поле endPort позволяет определить диапазон портов в одном правиле, а не указывать отдельные порты.

Ниже приведен пример Kubernetes NetworkPolicy, использующего поле endPort:

  egress:
    - to:
        - ipBlock:
            cidr: 10.0.0.0/24
      ports:
        - protocol: TCP
          port: 32000
          endPort: 32768

Обязательное действие:

• Если кластер AKS работает под управлением Cilium версии 1.17 или более поздней версии, изменения не требуются, так как endPort полностью поддерживается.
• Если кластер работает с версией Cilium до версии 1.17, удалите поле endPort из любых политик перед миграцией. Вместо этого используйте явные записи с одним портом.

NetworkPolicy с ipBlock

Поле ipBlock в Kubernetes NetworkPolicy позволяет определять диапазоны CIDR для источников входящего трафика или назначения исходящего трафика. Эти диапазоны могут включать внешние IP-адреса, IP-адреса pod или IP-адреса узлов. Однако Cilium не разрешает исходящий трафик к IP-адресам подов или узлов с помощью ipBlock, даже если эти IP-адреса попадают в указанный диапазон CIDR.

Например, следующий NetworkPolicy использует ipBlock для разрешения всего исходящего трафика на 0.0.0.0/0.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: example-ipblock
spec:
  podSelector: {}
  policyTypes:
    - Egress
  egress:
    - to:
      - ipBlock:
          cidr: 0.0.0.0/0 

• В рамках NPM эта политика разрешает исходящий трафик ко всем назначениям, включая модули Pod и Узлы.
• После миграции на Cilium исходящий трафик на Pod и IP-адреса узлов будет заблокирован, даже если они попадают в диапазон 0.0.0.0/0.

Обязательное действие:

• Чтобы разрешить трафик к IP-адресам Pod, перед миграцией замените ipBlock комбинацией namespaceSelector и podSelector.

Вот пример использования селектора пространства имен и селектора подов.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: example-ipblock
spec:
  podSelector: {}
  policyTypes:
    - Egress
  egress:
    - to:
      - ipBlock:
          cidr: 0.0.0.0/0
      - namespaceSelector: {}
      - podSelector: {}

• Для IP-адресов узлов не существует обходного решения перед миграцией. После миграции необходимо создать CiliumNetworkPolicy, чтобы он явно разрешал исходящий трафик к узловым и/или удаленным узлам. Пока эта политика не будет применена, исходящий трафик на IP-адреса узлов блокируется.

Ниже приведен пример CiliumNetworkPolicy для разрешения трафика между локальными и удаленными узлами:

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: allow-node-egress
  namespace: ipblock-test
spec:
  endpointSelector: {}  # Applies to all pods in the namespace
  egress:
     - toEntities:
          - host # host allows traffic from/to the local node's host network namespace
          - remote-node # remote-node allows traffic from/to the remote node's host network namespace

NetworkPolicy с именованными портами

Kubernetes NetworkPolicy позволяет ссылаться на порты по имени вместо числа. Если вы используете именованные порты в NetworkPolicies, Cilium может неправильно применять правила и привести к неожиданной блокировке трафика. Эта проблема возникает, когда одно и то же имя порта используется для разных портов. Дополнительные сведения см. в проблеме #30003 на GitHub Cilium.

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

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  annotations:
  name: allow-egress
  namespace: default
spec:
  podSelector:
    matchLabels:
      network-rules-egress: cilium-np-test
  egress:
  - ports:
    - port: http-test # Named port
      protocol: TCP
  policyTypes:
  - Egress

Обязательное действие:

• Перед миграцией замените все именованные порты в политиках соответствующими числовыми значениями.

NetworkPolicy с политиками исходящего трафика

Kubernetes NetworkPolicy в NPM не блокирует исходящий трафик из pod в IP-адрес собственного узла, этот трафик неявно разрешен. После миграции на Cilium это поведение изменится, и трафик к локальным узлам, который ранее был разрешён, будет заблокирован, если только он явно не разрешён.

Например, следующая политика разрешает исходящий трафик только во внутреннюю подсеть API:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-egress 
  namespace: default
spec:
  podSelector: {}
  policyTypes:
    - Egress
  egress:
    - to:
      - ipBlock:
          cidr: 10.20.30.0/24

• При использовании NPM: трафик исходящего трафика до 10.20.30.0/24 разрешен явным образом, и исходящий трафик на локальный узел разрешен неявно.
• В Cilium: разрешен только трафик на 10.20.30.0/24; Исходящий трафик к IP-адресу узла блокируется, если только вы не разрешаете его явным образом.

Обязательное действие:

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

Изменения поведения политики входящего трафика

В разделе Диспетчер политик сети (NPM) входящий трафик, поступающий через службу LoadBalancer или NodePort с параметром externalTrafficPolicy=Cluster, который является параметром по умолчанию, не подлежит применению политики входящего трафика. Это означает, что даже если модуль pod имеет ограничивающую политику входящего трафика, трафик из внешних источников может по-прежнему достичь его с помощью служб loadbalancer или nodeport.

В отличие от этого, Cilium применяет политики входящего трафика на весь трафик, включая трафик, маршрутизованный внутри из-за externalTrafficPolicy=Cluster. В результате после миграции трафик, который ранее был разрешен, может быть удален, если соответствующие правила входящего трафика не определены явным образом.

Например, заказчик создает политику сети, чтобы запретить весь входящий трафик

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

• При использовании NPM: прямое подключение к pod или через сервис ClusterIP блокируется. Однако доступ через NodePort или LoadBalancer по-прежнему разрешен, несмотря на политику запрета.
• При использовании Cilium: весь трафик входящего трафика блокируется, включая трафик через NodePort или LoadBalancer, если не разрешено явным образом.

Обязательное действие:

• Просмотрите все политики входящего трафика для рабочих нагрузок за службами LoadBalancer или NodePort с помощью externalTrafficPolicy=Cluster.
• Убедитесь, что правила входящего трафика явно разрешают трафик из ожидаемых внешних источников (например, диапазоны IP-адресов, пространства имен или метки).
• Если ваша политика в настоящее время зависит от неявного разрешающего поведения в NPM, необходимо добавить явные правила входящего трафика для поддержания подключения после миграции.

Обновление до Azure CNI с помощью Cilium

Чтобы использовать политику сети Cilium, кластер AKS должен работать под управлением CNI Azure на базе Cilium. При включении Cilium в кластере, который в данный момент использует NPM, существующий движок NPM автоматически удаляется и заменяется Cilium.

Чтобы выполнить обновление, вам потребуется Azure CLI версии 2.52.0 или более поздней. Запустите az --version , чтобы просмотреть текущую установленную версию. Если вам нужно установить или обновить, см. статью "Установка Azure CLI".

Используйте следующую команду, чтобы обновить существующий кластер до Azure CNI с помощью Cilium. Замените значения для clusterName и resourceGroupName:

az aks update --name <clusterName> --resource-group <resourceGroupName> --network-dataplane cilium

Дальнейшие шаги

• Дополнительные сведения о использовании политики FQDN Cilium в AKS см. в разделе «Настройка функции фильтрации FQDN для защиты сети контейнеров в расширенных сетевых службах контейнеров».

• Дополнительные сведения об использовании политики сети Cilium L7 в AKS см. в статье "Настройка политик уровня 7(L7) с расширенными сетевыми службами контейнеров".

• Дополнительные сведения о рекомендациях по политике сети в aks см. в рекомендациях по политикам сети в службе Azure Kubernetes (AKS)