Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
В процессе разработки, опирающемся на использование контейнеров и микрослужб, компоненты приложения должны слаженно работать вместе для обработки задач. Kubernetes предоставляет различные ресурсы для обеспечения этой слаженной работы:
- Вы можете подключиться к приложениям и открывать их внутри сети или вне её.
- Имеется возможность создавать приложения с высоким уровнем доступности путем распределения нагрузки.
- Вы можете ограничить поток сетевого трафика в поды и узлы, чтобы повысить безопасность.
- Вы можете настроить входящий трафик для терминации SSL/TLS или маршрутизации нескольких компонентов в более сложных приложениях.
В этой статье приводится обзор ключевых понятий сети в приложениях в AKS.
Основы сети Kubernetes
Kubernetes использует виртуальный сетевой уровень для управления доступом внутри и между приложениями или их компонентами:
Узлы Kubernetes и виртуальная сеть: узлы Kubernetes подключены к виртуальной сети. Эта настройка позволяет модулям pod (базовым единицам развертывания в Kubernetes) иметь как входящие, так и исходящие подключения.
Компонент маршрутизации служб: в зависимости от сетевого уровня данных узлы используют
kube-proxyлибо Cilium для маршрутизации служб Kubernetes. Кластеры AKS, использующие Azure CNI на базе Cilium, не используютkube-proxy.
Что касается конкретных функциональных возможностей Kubernetes:
- Подсистема балансировки нагрузки. Для равномерного распределения сетевого трафика между различными ресурсами можно использовать подсистему балансировки нагрузки.
- Контроллеры входящего трафика: это упрощает маршрутизацию уровня 7, что является важным для направления трафика приложения.
- Управление трафиком исходящего трафика: Kubernetes позволяет управлять исходящим трафиком с узлов кластера и управлять ими.
- Политики сети: эти политики обеспечивают меры безопасности и фильтрацию сетевого трафика в модулях pod.
В контексте платформы Azure:
- Azure упрощает виртуальные сети для кластеров AKS (Служба Azure Kubernetes).
- Создание подсистемы балансировки нагрузки Kubernetes в Azure одновременно настраивает соответствующий ресурс подсистемы балансировки нагрузки Azure.
- При создании службы Kubernetes
LoadBalancerAzure настраивает необходимые правила группы безопасности сети для трафика службы на ресурсах, управляемых AKS. - Azure также может управлять внешними конфигурациями DNS для маршрутизации приложений HTTP, так как устанавливаются новые маршруты входящего трафика.
виртуальные сети Azure
В AKS можно развернуть кластер, использующий одну из следующих сетевых моделей:
- Наложенная сетевая модель: наложение сети — это наиболее распространенная сетевая модель, используемая в Kubernetes. Модули получают IP-адрес из частного CIDR, логически отделённого от подсети виртуальной сети Azure, в которой развертываются узлы AKS. Эта модель обеспечивает более простую, улучшенную масштабируемость по сравнению с плоской сетевой моделью.
- Модель неструктурированных сетей: модель плоской сети в AKS назначает IP-адреса модулям pod из подсети в той же виртуальной сети Azure, что и узлы AKS. Для трафика в частной сети исходный IP-адрес, который виден узлу назначения, зависит от выбранного варианта управления IP-адресами (IPAM). Azure CNI Pod Subnet сохраняет IP-адрес пода в подключенных виртуальных сетях. При использовании Azure CNI Node Subnet узлы назначения в виртуальной сети кластера видят IP-адрес пода, а узлы назначения за пределами виртуальной сети кластера — IP-адрес узла. Для исходящего трафика в Интернете настроенный метод исходящего трафика определяет общедоступный исходный IP-адрес, который отображается в целевом интернет-расположении.
Дополнительные сведения о сетевых моделях в AKS см. в статье CNI Networking in AKS.
Управление исходящим (эфирным) трафиком
Кластеры AKS развертываются в виртуальной сети и зависят от сторонних служб за пределами этой виртуальной сети, которые почти полностью определяются с помощью полностью определенных доменных имен (FQDN). AKS предоставляет несколько параметров исходящей конфигурации, которые позволяют настроить способ доступа к этим внешним ресурсам.
Это важно
Начиная с Мarch 31, 2026 Azure Kubernetes Service (AKS) больше не поддерживает исходящий доступ по умолчанию для виртуальных машин. Новые кластеры AKS, использующие параметр виртуальной сети, управляемый AKS, по умолчанию помещает подсети кластера в частные подсети.defaultOutboundAccess = false Этот параметр не влияет на трафик управляемого AKS кластера, который использует явно настроенные исходящие пути. Это может повлиять на неподдерживаемые сценарии, например развертывание других ресурсов в той же подсети. Кластеры, использующие виртуальные сети BYO, не влияют на это изменение. В поддерживаемых конфигурациях никаких действий не требуется. Дополнительные сведения об этом выводе из эксплуатации см. в объявлении о прекращении поддержки обновлений Azure. Чтобы оставаться в курсе обновлений и объявлений, следите за заметками о релизах AKS.
Параметры конфигурации исходящего трафика
Дополнительные сведения о поддерживаемых типах конфигурации исходящего трафика кластера AKS см. в разделе Настройка исходящего трафика кластера с использованием типов в Azure Kubernetes Service (AKS).
По умолчанию кластеры AKS имеют неограниченный исходящий (исходящий) доступ к Интернету, что позволяет узлам и службам, которые вы запускаете для доступа к внешним ресурсам по мере необходимости. При желании можно ограничить исходящий трафик.
Дополнительные сведения об ограничении исходящего трафика из кластера см. в статье "Управление исходящим трафиком" для узлов кластера в AKS.
Группы безопасности сети
Группа безопасности сети фильтрует трафик для виртуальных машин, например для узлов AKS. При создании служб, таких какLoadBalancer, платформа Azure автоматически настраивает необходимые правила группы безопасности сети для трафика служб на ресурсах, управляемых AKS.
AKS не применяет группы безопасности сети к своей подсети и не изменяет группы безопасности сети, связанные с подсетью, предоставленной клиентом. Если вы связываете группу безопасности сети с пользовательской подсетью, вы должны убедиться, что её правила разрешают необходимый трафик узлов и pod'ов. Дополнительные сведения см. в статье о предварительных требованиях к сети AKS CNI.
Чтобы автоматически применять правила фильтрации трафика к модулям pod, вы также можете использовать политики сети.
Дополнительные сведения см. в разделе "Как группы безопасности сети фильтруют сетевой трафик".
Требования к пользовательской виртуальной сети
Если вы используете настраиваемую виртуальную сеть с кластерами AKS, при добавлении правил группы безопасности сети для ограничения трафика между подсетями убедитесь, что правила разрешают трафик, необходимый конфигурации кластера.
Интеграция виртуальной сети сервера API предварительно настроена в AKS Automatic. В AKS Standard компонент является необязательным, и его необходимо включить явным образом. Если ваш кластер использует интеграцию API-сервера с виртуальной сетью, разрешите следующий сетевой трафик:
| Место назначения | Исходный материал | Протокол | Порт | Использование |
|---|---|---|---|---|
| СЕРВЕРА APIServer подсети CIDR | Подсеть кластера | Протокол tcp | 443 и 4443 | Требуется для включения связи между узлами и сервером API. |
| СЕРВЕРА APIServer подсети CIDR | балансировщик нагрузки Azure | Протокол tcp | 9988 | Требуется для включения связи между Azure Load Balancer и сервером API. Вы также можете включить все взаимодействие между Azure Load Balancer и подсетью сервера API CIDR. |
Дополнительные сведения см. в интеграции VNet сервера API.
Для обмена данными между узлами и pod можно разрешить следующий трафик, если правила группы безопасности сети ограничивают соответствующие диапазоны CIDR:
| Место назначения | Исходный материал | Протокол | Порт | Использование |
|---|---|---|---|---|
| CIDR узла | CIDR узла | Все протоколы | Все порты | Требуется для включения связи между узлами. |
| Pod CIDR | CIDR узла | Все протоколы | Все порты | Требуется для маршрутизации трафика службы. |
| Pod CIDR | Pod CIDR | Все протоколы | Все порты | Требуется для трафика от Pod к Pod и от Pod к службе, включая DNS. |
Подходящие диапазоны CIDR для узлов и подов зависят от сетевой модели вашего кластера. Дополнительные сведения см. в статье о предварительных требованиях к сети AKS CNI.
Разрешение DNS
Разрешение DNS является важным для обнаружения служб и обмена данными в AKS. По умолчанию AKS использует CoreDNS для внутреннего разрешения имен подов и служб.
Для повышения производительности и надежности DNS AKS предлагает LocalDNS, который развертывает DNS-прокси на каждом узле. LocalDNS разрешает запросы локально, уменьшая задержку и устраняя conntrack нагрузку на таблицу от DNS-трафика. Вы можете настроить LocalDNS так, чтобы он выдавал кэшированные ответы при сбоях вышестоящих DNS-серверов, но кэширование устаревших ответов выполняется лишь по мере возможности. LocalDNS особенно полезна в больших кластерах или средах с большими томами ЗАПРОСОВ DNS.
LocalDNS предварительно настроен в AKS Automatic. В AKS Standard localDNS является необязательным и настроен для пула узлов. Прежде чем включить его в AKS Standard, проверьте версию Kubernetes, операционную систему узла и SKU виртуальной машины. Включение LocalDNS в существующем пуле узлов приводит к переустановке образа на его узлах. Предварительные требования и планирование развертывания см. в разделе "Настройка LocalDNS".
Политики сети
По умолчанию все контейнеры pod в кластере AKS могут отправлять и получать трафик без ограничений. Для повышения безопасности вы можете определить правила, управляющие потоком трафика, например:
- Бекенд-приложения предоставляются только для необходимых фронтенд-служб.
- Компоненты базы данных доступны только для уровней приложений, которые к ним подключаются.
Политика сети — это функция Kubernetes, доступная в AKS, которая позволяет контролировать поток трафика между pod. Вы можете разрешить или запретить трафик в pod на основе параметров, таких как назначенные метки, пространство имен или порт трафика. Несмотря на то что группы безопасности сети лучше подходят для узлов AKS, сетевые политики — это более подходящий и более тесно связанный с облаком способ управления потоком трафика для модулей Pod. Поскольку поды динамически создаются в кластере AKS, необходимые сетевые политики могут применяться автоматически.
Дополнительные сведения см. в разделе Обеспечить защиту трафика между модулями pod с помощью сетевых политик в Azure Kubernetes Service (AKS).
Следующие шаги
Чтобы приступить к работе с сетью AKS, создайте и настройте кластер AKS с собственными диапазонами IP-адресов с использованием Azure CNI Overlay или Azure CNI.
Рекомендации и описания лучших практик представлены в статье Рекомендации по сетевому подключению и безопасности в AKS.
Дополнительные сведения о ключевых понятиях Kubernetes и AKS приведены в следующих статьях: