Рекомендации по подключению к сети и безопасности в Azure Kubernetes Service (AKS)

Это важно

В 31 марта 2028 сеть Kubenet для Azure Kubernetes Service (AKS) будет прекращена.

Чтобы избежать сбоев в работе служб, вам необходимоперейти на наложение интерфейса Azure Container Networking Interface (CNI)до этой даты, когда больше не будут поддерживаться рабочие нагрузки на kubenet для AKS.

При создании кластеров и управлении ими в Azure Kubernetes Service (AKS) вы предоставляете сетевое подключение для узлов и приложений. К этим сетевым ресурсам относятся диапазоны IP-адресов, подсистемы балансировки нагрузки и контроллеры входящего трафика.

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

• Описание сетевого режима интерфейса контейнеров Azure (CNI) в AKS.
• Планирование требуемой IP-адресации и возможности подключения.
• Распределение трафика с помощью подсистем балансировки нагрузки, контроллеров входящего трафика и брандмауэра веб-приложений (WAF).
• Защищенное подключение к узлам кластера.

выбор подходящей сетевой модели.

Руководство по передовым практикам

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

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

• Оверлейная сеть: Azure CNI Overlay назначает IP-адреса модулям из отдельного диапазона CIDR модулей. Трафик, покидающий кластер, транслируется в IP-адрес узла, а поды недоступны напрямую по своим частным IP-адресам из подключённых сетей.
• Плоская сеть: Azure CNI Pod Subnet или устаревшая Azure CNI Node Subnet назначают IP-адреса подов из адресного пространства виртуальной сети. К подам можно обращаться по их приватным IP-адресам из подключённых сетей.

Дополнительные сведения о выборе сетевой модели см. в разделе "Планирование сети pod" для AKS.

Обзор сети CNI Azure

Azure CNI обеспечивает управление IP-адресами (IPAM) и сетевую связность для подов и узлов. Параметр IPAM отличается от сетевой плоскости данных. Например, можно использовать Azure CNI на базе Cilium с Azure CNI Overlay или с вариантом плоской сети.

На следующей схеме показаны два узла AKS, каждый из которых подключен через сетевой мост к общей Azure виртуальной сети.

Сетевая модель Azure CNI позволяет разделить контроль и управление ресурсами. С точки зрения безопасности для управления ресурсами и их защиты часто требуется задействовать разные группы сотрудников. Характеристики подключения зависят от сетевой модели. Overlay-поды устанавливают соединения с виртуальной сетью и ресурсами локальной инфраструктуры через IP-адрес узла. Поды с плоской сетью могут напрямую взаимодействовать с подключёнными ресурсами через их приватные IP-адреса.

При использовании Azure сети CNI ресурс виртуальной сети находится в отдельной группе ресурсов кластера AKS. Делегируйте разрешения удостоверению кластера AKS для доступа к этим ресурсам и управления ими. Идентификатор кластера, используемый кластером AKS, должен иметь по крайней мере разрешения Сетевой соавтор в подсети вашей виртуальной сети.

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

Разрешение	Description
Microsoft.Network/virtualNetworks/subnets/join/action	Присоединяет ресурсы кластера AKS к подсети виртуальной сети.
Microsoft.Authorization/roleAssignments/write	Создает необходимые назначения ролей.
Microsoft.Network/virtualNetworks/subnets/read	Считывает конфигурацию подсети при определении собственных подсетей и идентификаторов CIDR.

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

• Дополнительные сведения о делегировании служебного принципала AKS см. в статье Delegate access to other Azure resources.
• Для получения дополнительной информации об управляемых удостоверениях см. статью Использование управляемых удостоверений.

Планирование диапазонов адресов на основе сетевой модели. Имейте в виду следующие критерии:

• При использовании Azure CNI Overlay задайте размер подсети узлов для узлов и используйте отдельный частный диапазон CIDR для подов. Каждый узел получает адресное пространство /24 из CIDR pod.
• В плоской сети задайте размер подсетей виртуальной сети как для узлов, так и для подов. Azure CNI Pod Subnet использует отдельные подсети для узлов и pod-ов, а устаревший Azure CNI Node Subnet использует одну подсеть для узлов и pod-ов.
• Старайтесь не использовать диапазоны IP-адресов, перекрывающие существующие сетевые ресурсы.
  • Необходимо разрешить подключение к локальным или пиринговым сетям в Azure.
• Для обработки событий горизонтального масштабирования или обновлений кластера требуется дополнительные IP-адреса, доступные в назначенной подсети.
  • Это дополнительное адресное пространство особенно важно, если вы используете контейнеры Windows Server, так как эти пулы узлов требуют обновления для применения последних исправлений безопасности. Дополнительные сведения об узлах Windows Server см. в статье Обновление пула узлов в AKS.

Чтобы вычислить требуемое пространство IP-адресов, см. сведения о планировании IP-адресов для кластеров AKS.

При создании кластера с использованием сетевой модели Azure CNI необходимо указать дополнительные диапазоны адресов для кластера, например IP-адрес службы DNS и диапазон адресов служб. Как правило, убедитесь, что эти диапазоны адресов не перекрываются друг с другом или любыми сетями, связанными с кластером, включая любые виртуальные сети, подсети, локальные сети и пиринговые сети.

Дополнительные сведения о сетевых моделях, ограничениях и размерах адресов см. в Azure обзоре сети CNI.

Распределение входящего трафика

Руководство по передовым практикам

Чтобы распределить трафик HTTP или HTTPS между приложениями, используйте ресурсы и контроллеры входящего трафика. По сравнению с подсистемой балансировки нагрузки Azure контроллеры входящего трафика предоставляют дополнительные функции и могут управляться как собственные ресурсы Kubernetes.

Хотя подсистема балансировки нагрузки Azure может распределять трафик клиентов в приложениях в кластере AKS, это ограничивается пониманием этого трафика. Ресурс подсистемы балансировки нагрузки работает на уровне 4 и распределяет трафик на основе протокола или портов.

Большинство веб-приложений, использующих HTTP или HTTPS, должны использовать ресурсы и контроллеры входящего трафика Kubernetes, которые работают на уровне 7. Ingress может распределять трафик на основе URL-адреса приложения и обрабатывать завершение TLS/SSL. Ingress также уменьшает число IP-адресов, сопоставляемых и открытых.

При использовании подсистемы балансировки нагрузки каждому приложению обычно требуется назначить общедоступный IP-адрес и сопоставить его со службой в кластере AKS. При использовании ресурса входящего трафика один IP-адрес позволяет распределять трафик между несколькими приложениями.

На схеме показан один общедоступный IP-адрес, получающий внешний трафик, и контроллер входящего трафика, распространяющий этот трафик нескольким службам в кластере AKS.

Ingress имеет два компонента: ресурс Ingress и контроллер Ingress.

Ресурс Ingress

Ресурс ingress представляется в виде манифеста YAML . Он определяет хост, сертификаты и правила для маршрутизации трафика к службам, работающим в кластере AKS.

В следующем примере манифест YAML использует управляемый класс Ingress надстройки маршрутизации приложений NGINX. Он распределяет трафик для сайта myapp.com между двумя службами, blogservice и storeservice, и направляет пользователя к той или иной службе в зависимости от URL-адреса, к которому он обращается.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: myapp-ingress
spec:
  ingressClassName: webapprouting.kubernetes.azure.com
  tls:
  - hosts:
    - myapp.com
    secretName: myapp-secret
  rules:
  - host: myapp.com
    http:
      paths:
      - path: /blog
        pathType: Prefix
        backend:
          service:
            name: blogservice
            port:
              number: 80
      - path: /store
        pathType: Prefix
        backend:
          service:
            name: storeservice
            port:
              number: 80

Поле ingressClassName выбирает класс входящего трафика и должен соответствовать классу, настроенном на контроллере входящего трафика в кластере. Значение webapprouting.kubernetes.azure.com выбирает управляемый контроллер входящего трафика NGINX, предоставляемый надстройкой маршрутизации приложений. Замените его именем класса для контроллера входящего трафика, если вы используете другую реализацию.

Контроллер входящего трафика

Контроллер входящего трафика, размещенный в кластере, выполняется в качестве рабочей нагрузки на узле AKS и проверяет входящие запросы. Затем входящий трафик распределяется на основе правил, определенных в ресурсе входящего трафика, связанного с этим контроллером. Хотя наиболее распространенный контроллер входящего трафика основан на NGINX, AKS не ограничивает вас каким-либо определенным контроллером. Вы можете использовать Application Gateway for Containers, Contour, HAProxy, Traefik и другие.

Необходимо запускать работающие в кластере Ingress-контроллеры на узле под управлением Linux. Укажите, что ресурс должен выполняться на узле под управлением Linux, используя селектор узлов в манифесте YAML или при развертывании с помощью диаграммы Helm. Дополнительные сведения см. в статье Использование селекторов узлов для управления планированием модулей в AKS.

Ingress с надстройкой маршрутизации приложений

Надстройка для маршрутизации приложений предоставляет управляемые реализации Ingress для AKS. Для новых длительных развертываний используйте реализацию API шлюза маршрутизации приложений, если она поддерживает ваши требования. API шлюза — это долгосрочный стандарт для входящего трафика Kubernetes и управления трафиком уровня 7.

Внимание

Обслуживание upstream Ingress NGINX заканчивается в марте 2026 года. Microsoft предоставляет поддержку критически важных исправлений безопасности для ресурсов NGINX Ingress надстройки маршрутизации приложений до конца ноября 2026 года. Если вы используете управляемую реализацию NGINX, планируйте переход на реализацию API шлюза маршрутизации приложений или другую поддерживаемую реализацию к ноября 2026 года.

Управляемая реализация NGINX предоставляет следующие функции:

• Простая настройка управляемых контроллеров NGINX Ingress, основанных на Kubernetes NGINX Ingress Controller.
• Интеграция с Azure DNS для управления общедоступными и частными зонами.
• Завершение SSL с сертификатами, хранящимися в Azure Key Vault.

Дополнительные сведения см. в статье Настройка входящего трафика с помощью API шлюза маршрутизации приложений и управляемых входящего трафика NGINX с помощью надстройки маршрутизации приложений.

Защита трафика с помощью брандмауэра веб-приложений (WAF)

Руководство по передовым практикам

Чтобы анализировать входящий трафик на наличие потенциальных атак, используйте межсетевой экран веб-приложений (WAF), например Barracuda WAF для Azure или Брандмауэр веб-приложений Azure on Application Gateway for Containers. Шлюз приложений для контейнеров маршрутизирует трафик HTTP, HTTPS, gRPC, WebSocket и логического вывода ИИ, а также поддерживает терминацию TLS.

Развернутый в кластере контроллер ingress работает как рабочая нагрузка Kubernetes в вашем кластере AKS и распределяет трафик между службами и приложениями. Он использует некоторые ресурсы узла, такие как ЦП, память и пропускная способность сети. В более крупных средах может потребоваться рассмотреть следующее:

• Разгружать часть маршрутизации трафика или обработки TLS-терминации в сетевой ресурс за пределами кластера AKS.
• Проверять входящий трафик на наличие потенциальных атак.

На схеме показан внешний трафик, проходящий через Шлюз приложений Azure для контейнеров. При настройке защиты WAF правила WAF фильтруют запросы, прежде чем шлюз приложений для контейнеров перенаправит трафик в службы в кластере AKS.

Для этого дополнительного уровня безопасности брандмауэр веб-приложения (WAF) фильтрует входящий трафик. Управляемые и настраиваемые правила защищают от атак, таких как межсайтовые скрипты и внедрение SQL. Шлюз приложений для контейнеров — это служба балансировки нагрузки уровня 7 и управления трафиком, которая поддерживает Azure WAF.

Защита WAF не включается при развертывании только Application Gateway for Containers. Прежде чем WAF начнет проверять трафик, необходимо создать политику WAF и выполнить обе указанные ниже настройки:

• Создайте дочерний ресурс AzureSecurityPolicy, ссылающийся на политику WAF.
• Примените пользовательский ресурс Kubernetes WebApplicationFirewallPolicy, который ссылается на ту же политику WAF и нацелен на ресурс Gateway или HTTPRoute, который нужно защитить.

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

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

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

Управляйте потоком трафика с помощью сетевых политик

Руководство по передовым практикам

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

Политика сети — это функция Kubernetes, доступная в AKS, которая позволяет контролировать поток трафика между подами. Вы разрешаете или запрещаете трафик в pod, основываясь на таких параметрах, как назначенные метки, пространство имен или порт трафика. Политики сети — это ориентированный на облако способ управления потоком трафика для модулей pod. Поскольку поды динамически создаются в кластере AKS, необходимые политики сети могут применяться автоматически.

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

Для пулов узлов Linux используйте Azure CNI на базе Cilium и встроенный механизм применения сетевых политик Cilium. Cilium не поддерживается для пулов узлов Windows. Для рабочих нагрузок Windows используйте Calico.

Это важно

Поддержка Azure Network Policy Manager (NPM) для узлов Windows прекращается 30 сентября 2026 г., и в новых подписках его больше нельзя включить. Azure поддержка NPM для узлов Linux заканчивается 30 сентября 2028 г. Перенос кластеров Linux из NPM в Cilium до даты окончания поддержки.

Вы создаете сетевую политику в качестве ресурса Kubernetes с помощью манифеста YAML. Политики применяются к определённым модулям, с использованием правил для входящего и исходящего трафика, которые определяют поток трафика.

В следующем примере применяется политика сети к контейнерам pod с примененной к ним меткой app: backend. Правило входящего трафика разрешает трафик только из pod'ов с меткой app: frontend.

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: backend-policy
spec:
  podSelector:
    matchLabels:
      app: backend
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend

Чтобы начать работу с политиками, см. раздел Экспедирование трафика между подами с помощью сетевых политик в Azure Kubernetes Service (AKS).

Оптимизация разрешения DNS с помощью LocalDNS

Руководство по передовым практикам

Используйте LocalDNS для повышения производительности и надежности DNS и снижения нагрузки на централизованные модули pod CoreDNS. LocalDNS предварительно настроен в AKS Automatic. В AKS Standard включите и настройте LocalDNS на пул узлов.

LocalDNS развертывает DNS-прокси в качестве systemd службы на каждом узле для локальной обработки запросов DNS. По умолчанию поды отправляют все DNS-запросы в централизованные поды CoreDNS. При масштабировании централизация этих запросов может стать узким местом, тогда как локальное разрешение снижает количество сетевых переходов и задержку.

LocalDNS также устраняет conntrack записи таблицы трафика DNS, предотвращая conntrack переполнение таблицы и состояния гонки, которые могут привести к разрывам соединений. Подключения из локального кэша к CoreDNS обновляются до TCP, что позволяет перебалансировать подключения и ускорить очистку записей отслеживания.

Для рабочих нагрузок, требующих высокой доступности DNS, LocalDNS поддерживает обслуживание устаревших кэшированных ответов для настраиваемой длительности при недоступности вышестоящего DNS. Эта возможность лучше всего помогает поддерживать подключение pod и надежность службы во время временных сбоев DNS, но это не гарантирует доступность устаревшей записи.

В AKS Standard включение LocalDNS для существующего пула узлов приводит к переустановке образа на его узлах. Спланируйте развертывание с учетом этого сбоя.

Дополнительные сведения об архитектуре и возможностях LocalDNS см. в разделе "Разрешение DNS" в AKS. Инструкции по настройке см. в разделе "Настройка LocalDNS".

Безопасное подключение к узлам

Руководство по передовым практикам

Не предоставляйте возможность удаленного подключения к узлам AKS. Для стандартного устранения неполадок узла Linux используйте kubectl debug через API Kubernetes. Если вам нужен доступ по протоколу SSH, подключитесь через частную сеть или Бастион Azure.

Большинство операций в AKS можно выполнить с помощью средств управления Azure или сервера API Kubernetes. Узлы AKS доступны только в частной сети и не подключаются к общедоступному Интернету. Для узлов Linux используйте kubectl debug для запуска привилегированного контейнера отладки через API Kubernetes. Этот подход не требует прямого подключения SSH к узлу.

Если доступ к API Kubernetes не подходит или требуется SSH, используйте частный IP-адрес узла из подключенной сети. Бастион Azure может обеспечить частное подключение без предоставления общедоступного IP-адреса на узле. Для Windows узлов используйте контейнер процесса узла или подключитесь через прокси-узел Linux. Бастион Azure является альтернативой, если прокси-узел недоступен. Дополнительные сведения см. в разделе "Подключение к узлам кластера AKS" для обслуживания или устранения неполадок.

На схеме показана виртуальная сеть управления, содержащая бастионный узел, который направляет подключения через защищённое пиринговое соединение к виртуальной сети кластера AKS.

Если вы используете bastion-хост или промежуточный хост, разместите его в отдельной виртуальной сети управления, безопасно связанной пирингом с другими сетями. Защита сети управления с помощью Azure ExpressRoute или VPN-шлюза для подключения к локальной сети и управления доступом с помощью групп безопасности сети.

Следующие шаги

В этой статье описаны вопросы, связанные с безопасностью и подключению сетей. Дополнительные сведения об основах сети в Kubernetes подробнее см. в разделе Концепции сети для приложений в Azure Kubernetes Service (AKS)