Настройка Azure CNI на основе Cilium в Azure Kubernetes Service (AKS)

Azure CNI Powered by Cilium объединяет надежную плоскость управления Azure сетевого интерфейса контейнеров (CNI) с уровнем данных Cilium для обеспечения высокопроизводительной сети и безопасности.

Azure CNI Powered by Cilium предоставляет следующие преимущества, используя программы eBPF, загруженные в ядро Linux и более эффективную структуру объектов API:

• Функциональные возможности, эквивалентные существующим плагинам Azure CNI и Azure CNI Overlay.
• Улучшенная маршрутизация служб
• Более эффективное применение политики сети
• Улучшенная наблюдаемость трафика кластера
• Поддержка больших кластеров (больше узлов, модулей pod и служб)

Управление IP-адресами (IPAM) с Azure CNI с помощью Cilium

Вы можете использовать Azure CNI Powered by Cilium с тремя параметрами управления IP-адресами (IPAM):

• Оверлей Azure CNI
• Подсеть подов CNI Azure
• Подсеть узла Azure CNI, устаревший вариант

Для большинства сценариев используйте Azure CNI Overlay. Если вам нужен прямой доступ к IP-адресам модулей из подключенных сетей, используйте Azure CNI Pod Subnet. Дополнительные сведения см. в разделе "Выбор параметра IPAM" для AKS.

Поддерживаемые версии Kubernetes и Cilium

В следующей таблице показана минимальная версия Cilium для каждой версии Kubernetes. Эти требования к версиям применяются как к кластерам AKS Automatic, так и к AKS Standard с помощью Azure CNI Powered by Cilium.

Дополнительные сведения об использовании версий AKS и временных шкалах выпуска см. в статье "Поддерживаемые версии Kubernetes".

Применение политик сети с помощью Cilium

Cilium применяет сетевые политики для разрешения или запрета трафика между pod. При использовании Cilium не требуется устанавливать отдельный обработчик политики сети, например диспетчер сетевых политик Azure или Calico.

Политика локального перенаправления (LRP)

Политика локального перенаправления (LRP) перенаправляет трафик pod, предназначенный для IP-адреса и порта или службы Kubernetes в серверный модуль pod на том же узле.

LRP поддерживается из Kubernetes версии 1.29 и выше. Чтобы LRP работал с расширенными сетевыми службами контейнеров (ACNS) — фильтрацией FQDN, метки сетевой политики Cilium должны совпадать с метками pod для локального кэша DNS на узле.

Следующая конфигурация CiliumLocalRedirectPolicy перенаправляет DNS-трафик, направляемый в службу kube-dns, в поды локального кэша DNS на том же узле. Если в вашем кластере используется другое имя службы DNS или другое пространство имён, обновите serviceName и namespace так, чтобы они соответствовали вашему кластеру.

apiVersion: cilium.io/v2
kind: CiliumLocalRedirectPolicy
metadata:
  name: dns-to-nodelocal
  namespace: kube-system
spec:
  redirectFrontend:
    serviceMatcher:
      serviceName: kube-dns
      namespace: kube-system
  redirectBackend:
    localEndpointSelector:
      matchLabels:
        k8s-app: node-local-dns
    toPorts:
      - port: "53"
        name: dns
        protocol: UDP
      - port: "53"
        name: dns-tcp
        protocol: TCP

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

...
- matchLabels:
    io.kubernetes.pod.namespace: kube-system
    k8s-app: node-local-dns

Limitations

Azure CNI Powered by Cilium в настоящее время имеет следующие ограничения:

• Доступно только для Linux, а не для Windows.
• Политики сети не могут использовать ipBlock для разрешения доступа к IP-адресам узлов или подов. Дополнительные сведения и рекомендуемые обходные пути см. в часто задаваемых вопросах.
• Для Cilium версии 1.16 или более ранней версии несколько служб Kubernetes не могут использовать один и тот же порт узла с различными протоколами (например, TCP или UDP) (проблема Cilium #14287).
• Политики сети не применяются к подам, использующим сетевые функции хоста (spec.hostNetwork: true), так как эти поды используют идентификацию узла вместо отдельных идентификаций.
• Правила для исходящей сети Sercutity Group (NSG), которые блокируют доступ к интернету или Azure службам, могут предотвратить экспорт журналов диагностики Cilium. Клиенты, использующие ограничительные политики исходящего трафика, должны разрешить исходящий трафик к тегу службы Azure Monitor, чтобы обеспечить корректный сбор данных для телеметрии, диагностики и устранения неполадок.
• Срезы конечных точек Cilium поддерживаются в Kubernetes версии 1.32 и выше. Срезы конечных точек Cilium не поддерживают конфигурацию группировки конечных точек Cilium. Пространство имен приоритета через cilium.io/ces-namespace не поддерживается.
• Cilium использует идентификаторы Cilium в качестве уникальных идентификаторов при подготовке конечных точек, поэтому быстро меняющиеся рабочие нагрузки, такие как задания Spark, создают большое количество идентификаторов Cilium. Чтобы избежать достижения предела удостоверений Cilium (65535), можно значительно сократить создание удостоверений Cilium, исключив из конфигурации Cilium метки задания Spark, такие как !spark-app-name и !spark-app-selector. Дополнительные сведения о правилах исключения идентификаторов Cilium см. в официальной документации по меткам Cilium.

Включите расширенные службы сетевого взаимодействия контейнеров для наблюдаемости и безопасности

Чтобы получить такие возможности, как наблюдаемость сетевого трафика и функции безопасности, такие как фильтрация на основе полностью квалифицированных доменных имен (FQDN) и сетевые политики на уровне 7 в вашем кластере, рассмотрите возможность включения Расширенных сетевых служб контейнеров в ваших кластерах.

Эта рекомендация применяется как к кластерам AKS Automatic, так и AKS Standard. Если вы используете AKS Automatic, базовая сеть уже предварительно настроена. Включение ACNS добавляет наблюдаемость контейнерной сети и фильтрацию по FQDN. Другие функции ACNS, включая политики сети L7, шифрование WireGuard, шифрование mTLS и маршрутизацию узла eBPF, требуют дополнительной настройки. Некоторые функции также имеют требования к версии, операционной системе или предварительной версии. Дополнительные сведения см. в таблице поддержки функций.

Конфигурация кластера с помощью режима кластера AKS

Действия, необходимые для использования Azure CNI с помощью Cilium, зависят от режима кластера AKS: AKS Automatic или AKS Standard.

Автоматические кластеры AKS

Azure CNI Overlay на базе Cilium — это виртуальная сеть по умолчанию в кластерах AKS Automatic. Эта конфигурация полностью управляема. Вам не нужно подготовить виртуальную сеть, выбрать подключаемый модуль CNI или указать плоскость данных. AKS Automatic также предварительно настраивает LocalDNS, управляемый шлюз NAT для исходящего трафика и надстройку маршрутизации приложений для входящего трафика.

Никаких действий по настройке не требуется. Если вы хотите добавить расширенные функции наблюдения или безопасности поверх существующей сети, см. статью "Расширенные сетевые службы контейнеров".

Кластеры AKS Standard

В AKS Standard Azure CNI Powered by Cilium является необязательной конфигурацией сети. Выполните действия, описанные в этой статье, чтобы создать кластер с плоскостем данных Cilium. Вы можете выбрать режим назначения IP-адресов: оверлейной сети, виртуальной сети или подсети узла.

Prerequisites

Требуемая версия Azure CLI зависит от метода назначения IP-адресов:

Запустите az --version , чтобы просмотреть текущую установленную версию. Если необходимо установить или обновить, см. раздел Install Azure CLI.

• Просмотрите предварительные требования к сети AKS CNI. Если вы не используете изолированный сетевой кластер, виртуальная сеть должна разрешить исходящее подключение к необходимым конечным точкам. Диапазоны адресов не могут перекрывать зарезервированные диапазоны AKS или подключенные сети, а подсети узлов нельзя делегировать.
• Чтобы использовать управляемые клиентом подсети, удостоверение кластера должно иметь разрешения участника сети или эквивалентные пользовательские разрешения в подсетях. Пользователь, создав кластер, должен иметь разрешение на создание необходимых назначений ролей. Если вы связываете группы сетевой безопасности с подсетями, убедитесь, что их правила разрешают необходимый трафик для узлов и pod'ов.

Создание нового кластера AKS с Azure CNI на платформе Cilium

В следующих разделах используется az aks create команда для создания кластера AKS Standard и назначения IP-адресов. Если вы используете AKS Automatic, эта конфигурация уже применяется. Для сети не требуются шаги по созданию кластера.

Вариант 1: Назначение IP-адресов из наложенной сети

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

az aks create \
  --name <clusterName> \
  --resource-group <resourceGroupName> \
  --location <location> \
  --network-plugin azure \
  --network-plugin-mode overlay \
  --pod-cidr 192.168.0.0/16 \
  --network-dataplane cilium \
  --generate-ssh-keys

Флаг --network-dataplane cilium заменяет устаревший --enable-ebpf-dataplane флаг, используемый в более ранних версиях расширения CLI aks-preview.

Вариант 2. Назначение IP-адресов из виртуальной сети

Выполните следующие команды, чтобы создать группу ресурсов и виртуальную сеть с подсетью для узлов и подсетью для подов.

# Create the resource group
az group create --name <resourceGroupName> --location <location>

# Create a virtual network with a subnet for nodes and a subnet for pods
az network vnet create \
  --resource-group <resourceGroupName> \
  --location <location> \
  --name <vnetName> \
  --address-prefixes <address prefix, example: 10.0.0.0/8> \
  -o none
az network vnet subnet create \
  --resource-group <resourceGroupName> \
  --vnet-name <vnetName> \
  --name nodesubnet \
  --address-prefixes <address prefix, example: 10.240.0.0/16> \
  -o none
az network vnet subnet create \
  --resource-group <resourceGroupName> \
  --vnet-name <vnetName> \
  --name podsubnet \
  --address-prefixes <address prefix, example: 10.241.0.0/16> \
  -o none

Создайте кластер с помощью команды az aks create, используя --network-dataplane cilium для указания плоскости данных Cilium. Замените значения для <clusterName>, <resourceGroupName>, , <location><subscriptionId>и <vnetName>убедитесь, что --vnet-subnet-id и --pod-subnet-id значения указывают на правильные подсети, созданные на предыдущем шаге.

az aks create \
  --name <clusterName> \
  --resource-group <resourceGroupName> \
  --location <location> \
  --max-pods 250 \
  --network-plugin azure \
  --vnet-subnet-id /subscriptions/<subscriptionId>/resourceGroups/<resourceGroupName>/providers/Microsoft.Network/virtualNetworks/<vnetName>/subnets/nodesubnet \
  --pod-subnet-id /subscriptions/<subscriptionId>/resourceGroups/<resourceGroupName>/providers/Microsoft.Network/virtualNetworks/<vnetName>/subnets/podsubnet \
  --network-dataplane cilium \
  --generate-ssh-keys

Вариант 3. Назначение IP-адресов из подсети узла

Создайте кластер с помощью подсети узла с плоскостью данных Cilium:

az aks create \
  --name <clusterName> \
  --resource-group <resourceGroupName> \
  --location <location> \
  --network-plugin azure \
  --network-dataplane cilium \
  --generate-ssh-keys

Часто задаваемые вопросы

Доступна ли Azure CNI на базе Cilium в автоматических кластерах AKS?

Yes. CNI Overlay в Azure на базе Cilium используется как виртуальная сеть по умолчанию в любом кластере AKS Automatic и не требует настройки. AKS Automatic также предварительно настраивает LocalDNS и управляемый шлюз NAT для исходящего трафика. Если требуется дополнительная наблюдаемость или функции безопасности, такие как фильтрация полного доменного имени, политики сети L7 или шифрование Wireguard, вы можете включить расширенные сетевые службы контейнеров в кластере AKS Automatic.

Можно ли использовать CiliumNetworkPolicy пользовательские ресурсы вместо ресурсов Kubernetes NetworkPolicy ?

Поддерживаются L3 и L4 CiliumNetworkPolicy и могут использоваться вместе с ресурсами Kubernetes NetworkPolicy .

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

Можно ли использовать CiliumClusterwideNetworkPolicy?

Да, Azure CNI на базе Cilium поддерживает CiliumClusterwideNetworkPolicy.

Следующий пример политики разрешает входящий трафик на TCP-порту 80 к подам с меткой role: backend от подов с меткой role: frontend.

apiVersion: "cilium.io/v2"
kind: CiliumClusterwideNetworkPolicy
metadata:
  name: "l4-rule-ingress-backend-frontend"
spec:
  endpointSelector:
    matchLabels:
      role: backend
  ingress:
    - fromEndpoints:
        - matchLabels:
            role: frontend
      toPorts:
        - ports:
            - port: "80"
              protocol: TCP

Какие функции Cilium поддерживаются в Azure CNI на базе Cilium? Для каких функций требуется Advanced Container Networking Services?

Инструкции и ограничения для конкретной функции см. в разделе "Расширенные сетевые службы контейнеров".

Можно ли изменить Cilium ConfigMap?

Поддерживается только исключение метки label для Azure CNI с использованием Cilium. Этот ConfigMap существует в kube-system пространстве имен как cilium-config. Добавление меток сохраняется при перезапусках, обновлениях кластера и их согласовании. Изменения других значений в ConfigMap не поддерживаются.

Почему трафик блокируется, если у NetworkPolicy есть ipBlock, разрешающий этот IP-адрес?

Ограничение Azure CNI Powered by Cilium заключается в том, что NetworkPolicyipBlock не удается выбрать IP-адреса pod или узла.

Например, этот 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 # This will still block pod and node IPs.

Даже при использовании cidr: 0.0.0.0/0, Cilium блокирует исходящий трафик к IP-адресам pod'ов и узлов, поскольку ipBlock не может выбирать эти адреса.

В качестве обходного решения можно добавить namespaceSelector и podSelector для выбора Pods. В этом примере выбираются все pod'ы во всех пространствах имен.

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: {}

В настоящее время невозможно указать NetworkPolicy с ipBlock для разрешения трафика на IP-адреса узлов.

Настраивает ли AKS ограничения ЦП или памяти на Cilium daemonset?

Нет, AKS не настраивает ограничения ЦП или памяти на Cilium daemonset, так как Cilium является критически важным системным компонентом для сетей pod и осуществления политик сети.

Использует ли «Azure CNI Powered by Cilium» kube-proxy?

Нет, кластеры AKS, созданные с сетевой плоскостью данных Cilium, не используют kube-proxy.

Это поведение применяется ко всем версиям Kubernetes, поддерживаемым Azure CNI Powered Cilium, без отдельного ограничения версии AKS. Обновление плоскости данных поддерживается только в кластерах на базе Linux и требует, чтобы автоматическое выделение узлов (NAP) было отключено во время обновления.

Если вы обновляете кластеры AKS на Azure CNI Overlay или Azure CNI с динамическим выделением IP-адресов до кластеров AKS, использующих Azure CNI Powered by Cilium, рабочие нагрузки на новых узлах создаются без kube-proxy. Рабочие нагрузки на существующих узлах также переносятся в рамках этого процесса обновления, чтобы работать без kube-proxy.

Поддерживается ли локальный DNS AKS в Azure CNI на базе Cilium?

Да, политики сети должны явно разрешать исходящий трафик pod в IP-адрес LocalDNS.

Следующая политика разрешает исходящий трафик к CIDR LocalDNS 169.254.10.0/24 по протоколам UDP и TCP через порт 53, а также к сущности host через те же порты.

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: "allow-azure-dns-egress"
  namespace: default
spec:
  endpointSelector:
    matchLabels: {} # This selects ALL pods in the namespace
  egress:
    - toCIDR:
        - 169.254.10.0/24
      toPorts:
        - ports:
            - port: "53"
              protocol: UDP
            - port: "53"
              protocol: TCP
    - toEntities:
        - host
      toPorts:
        - ports:
            - port: "53"
              protocol: UDP
            - port: "53"
              protocol: TCP

Сеть с двумя стеками с Azure CNI с помощью Cilium

У вас должна быть версия Kubernetes версии 1.29 или более поздней. Это относится к кластерам AKS Automatic и AKS Standard.

Вы можете развернуть двухстековые кластеры AKS с Azure CNI, управляемой с помощью Cilium. Эта функция также позволяет управлять трафиком IPv6 с помощью подсистемы сетевой политики Cilium.

Настройка кластеров наложения с помощью Azure CNI на базе Cilium

Создайте кластер с наложением CNI Azure, используя команду az aks create. Обязательно используйте аргумент --network-dataplane cilium для указания плоскости данных Cilium.

clusterName="myOverlayCluster"
resourceGroup="myResourceGroup"
location="westcentralus"

az aks create \
  --name $clusterName \
  --resource-group $resourceGroup \
  --location $location \
  --network-plugin azure \
  --network-plugin-mode overlay \
  --network-dataplane cilium \
  --ip-families ipv4,ipv6 \
  --generate-ssh-keys

Связанный контент

Дополнительные сведения о сети AKS и AKS Automatic см. в следующих ресурсах:

• Что такое AKS Automatic?
• Краткое руководство: создание кластера AKS с автоматическим режимом
• Обновление режимов IPAM CNI для Azure и технологии дата-плоскости.
• Использовать статический IP-адрес с подсистемой балансировки нагрузки Azure Kubernetes Service (AKS)
• Использование внутреннего балансировщика нагрузки в Службе Kubernetes Azure (AKS)
• Понятия Ingress в Azure Kubernetes Service (AKS)