Рекомендации по топологии сети и подключению к Виртуальному рабочему столу Azure

Рекомендации по проектированию

Служба Azure Kubernetes (AKS) предоставляет три различных сетевых модели для сети контейнеров: Kubenet, CNI Overlay и CNI. Каждая из этих моделей имеет свой уникальный набор функций и преимуществ, предлагая гибкость и масштабируемость для сети контейнеров в AKS.

Kubenet

Kubenet — это базовое сетевое решение, которое экономит пространство IP-адресов и предлагает простую конфигурацию. Это идеально подходит для небольших кластеров AKS с менее чем 400 узлами, где можно вручную управлять и поддерживать определяемые пользователем маршруты. Он подходит для сценариев, когда внутренние или внешние подсистемы балансировки нагрузки достаточно для достижения модулей pod извне кластера.

Azure CNI

Azure CNI — это сетевая модель, предназначенная для расширенной сети. Он предоставляет полное подключение к виртуальной сети для модулей pod, что позволяет подключаться к pod-to-pod и pod-to-VM. Это идеально подходит для сценариев, когда требуются расширенные функции AKS, такие как виртуальные узлы. Он подходит для сценариев, в которых доступно достаточное пространство IP-адресов, и внешние ресурсы должны напрямую обращаться к модулям pod. Политики сети AKS также поддерживаются в Azure CNI.

Наложение Azure CNI

Наложение Azure CNI предназначено для устранения нехватки IP-адресов и упрощения конфигурации сети. Это подходит для сценариев, когда достаточно масштабирование до 1000 узлов и 250 модулей pod на узел, а дополнительное прыжки для подключения pod приемлемы. Требования к исходящего трафика AKS также можно выполнить с помощью наложения Azure CNI.

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

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

Кластеры AKS поддерживают номера SKU "Базовый" и "Стандартный" Azure Load Balancer, а службы можно предоставлять с помощью общедоступных или внутренних подсистем балансировки нагрузки. AKS использует CoreDNS для предоставления разрешения имен модулям pod, работающим в кластере, и исходящий (исходящий) сетевой трафик можно отправлять через Брандмауэр Azure или виртуальный кластер виртуальных (модуль) сети.

По умолчанию все контейнеры pod в кластере AKS могут отправлять и получать трафик без ограничений. Однако политики сети Kubernetes можно использовать для повышения безопасности и фильтрации сетевого трафика между модулями pod в кластере AKS. Для AKS доступны две модели политики сети: политики сети Azure и Calico.

Наконец, AKS настраивает группу безопасности сети (NSG) в подсети, в которой развернут кластер. Не рекомендуется вручную изменять эту группу безопасности сети, но службы, развернутые в AKS, могут повлиять на нее.

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

Частные кластеры

IP-адреса кластера AKS могут быть либо общедоступными, либо частными. Частные кластеры предоставляют API Kubernetes через частный, а не общедоступный IP-адрес. Такой частный IP-адрес представляется в виртуальной сети AKS частной конечной точкой. Доступ к API Kubernetes должен осуществляться не по его IP-адреса, а через его полное доменное имя (FQDN). Разрешение из полного доменного имени API Kubernetes в IP-адрес обычно выполняется частной зоной DNS Azure. Azure может создать эту зону DNS в группе ресурсов узла AKS. Кроме того, можно указать существующую зону DNS.

Ниже приведены проверенные рекомендации корпоративного уровня. Разрешение DNS для рабочих нагрузок Azure предоставляется централизованными DNS-серверами, развернутыми в подписке на подключение, в виртуальной сети концентратора или в виртуальной сети общих служб, подключенной к виртуальной глобальной сети Azure. Эти серверы будут условно разрешать конкретные и общедоступные имена Azure с помощью Azure DNS (IP-адрес 168.63.129.16 ) и частных имен, используя корпоративные DNS-серверы. Однако эти централизованные DNS-серверы не смогут разрешать полное доменное имя API AKS, пока они не будут подключены к частной зоне DNS, созданной для кластера AKS. Каждый AKS имеет уникальную частную зону DNS, так как случайный GUID добавляется к имени зоны. Таким образом, для каждого нового кластера AKS соответствующая частная зона DNS должна быть подключена к виртуальной сети, где находятся центральные DNS-серверы.

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

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

Примечание.

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

1. Администратор разрешает полное доменное имя API Kubernetes. Локальные DNS-серверы перенаправляют запрос на полномочные серверы: сопоставители DNS в Azure. Эти серверы перенаправляют запрос на DNS-сервер Azure (168.63.129.16), который затем получает IP-адрес из частной зоны DNS Azure.
2. После разрешения IP-адреса трафик к API Kubernetes направляется из локальной среды в шлюз VPN или ExpressRoute в Azure в зависимости от модели подключения.
3. Частная конечная точка ввела /32 маршрут в виртуальной сети концентратора. Шлюзы VPN и ExpressRoute отправляют трафик непосредственно в частную конечную точку API Kubernetes, развернутую в виртуальной сети AKS.

Трафик от пользователей приложения к кластеру

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

• Контроллеры входящего трафика обеспечивают маршрутизацию на уровне приложений за счет незначительного увеличения сложности.
• Контроллеры входящего трафика могут включать также функции брандмауэра веб-приложения (WAF).
• Контроллеры входящего трафика могут запускаться вне кластера и в кластере:
  • Контроллер входящего трафика вне кластера выгружает вычисления (например, маршрутизацию трафика HTTP или завершение сеанса TLS) в другую службу за пределами AKS, например, в надстройку контроллера входящего трафика Шлюза приложений Azure (AGIC).
  • Решение в кластере для вычислений (например, для маршрутизации трафика HTTP или завершения сеанса TLS) задействует ресурсы кластера AKS. Контроллеры входящего трафика в кластере могут стоить дешевле, но требуют тщательного планирования ресурсов и обслуживания.
• Основная надстройка маршрутизации приложений HTTP проста в использовании, но имеет некоторые ограничения, описанные в статье Маршрутизация приложений HTTP.

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

• Конфигурация должна быть согласована со структурой фильтрации исходящего трафика, чтобы не допустить асимметричной маршрутизации. Определяемые пользователем маршруты могут вызвать асимметричную маршрутизацию (потенциально), хотя и не обязательно. Шлюз приложений может использовать SNAT по трафику, то есть возвращаемый трафик возвращается в узел Шлюз приложений, а не маршрут UDR, если UDR настроен только для трафика в Интернете.
• Если требуется завершение сеанса TLS, следует учитывать необходимость управления сертификатами TLS.

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

Трафик из локальной среды следует по маршруту, отмеченному на показанной выше схеме пронумерованными синими выносками.

1. Клиент разрешает полное доменное имя, назначенное приложению, с помощью DNS-серверов, развернутых в подписке подключения или локальных DNS-серверах.
2. После разрешения полного доменного имени приложения на IP-адрес (частный IP-адрес шлюза приложений) трафик направляется через шлюз VPN или ExpressRoute.
3. Маршрутизация в подсети шлюза настраивается на отправку запроса в брандмауэр веб-приложений.
4. Брандмауэр веб-приложений отправляет допустимые запросы к рабочей нагрузке, выполняемой в кластере AKS.

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

1. Клиенты из общедоступного Интернета разрешают DNS-имя для приложения с помощью Диспетчера трафика Azure. Кроме того, можно использовать и другие глобальные технологии балансировки нагрузки, такие как Azure Front Door.
2. Общедоступное полное доменное имя приложения разрешается Диспетчером трафика на общедоступный IP-адрес шлюза приложений, к которому клиенты обращаются через общедоступный Интернет.
3. Шлюз приложений обращается к рабочей нагрузке, развернутой в AKS.

Примечание.

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

Кроме того, трафик для веб-приложений можно использовать для обхода брандмауэра Azure в подписке на подключение и WAF в виртуальной сети AKS. Такой подход выгодно отличается тем, что обеспечивает некоторую дополнительную защиту, например использование фильтрации с применением средств искусственного интеллекта брандмауэра Azure, позволяющих игнорировать трафик с известных вредоносных IP-адресов в Интернете. Однако у него тоже есть недостатки. Например, потеря исходного IP-адреса клиента и необходимость дополнительной координации между брандмауэром и группами приложений при предоставлении приложений. Это связано с тем, что в брандмауэре Azure потребуются правила преобразования сетевых адресов назначения (DNAT).

Трафик из модулей AKS в серверные службы

Для модулей Pod, запускаемых в кластере AKS, может потребоваться доступ к серверным службам, таким как служба хранилища Azure, базы данных Azure SQL и базы данных Azure Cosmos DB NoSQL. Для безопасного подключения к этим управляемым службам Azure могут использоваться Конечные точки службы виртуальной сети и приватный канал.

Если вы используете частные конечные точки Azure для внутреннего трафика, разрешение DNS для служб Azure можно выполнить с помощью зон Частная зона DNS Azure. Поскольку сопоставители DNS для всей среды находятся в виртуальной сети концентратора (или в виртуальной сети общих служб при использовании модели подключения виртуальной глобальной сети), такие частные зоны нужно создавать в подписке на подключение. Для создания записи A, необходимой для разрешения полного доменного имени частной службы, можно связать частную зону DNS (в подписке на подключение) с частной конечной точкой (в подписке на приложение). Для выполнения этой операции требуются определенные привилегии в этих подписках.

Записи А можно создавать вручную, однако связывание частной зоны DNS с частной конечной точкой позволит уменьшить вероятность ошибок к настройке конфигурации.

Серверное подключение из модулей pod AKS к службам Azure PaaS, предоставляемым через частные конечные точки, выполните следующую последовательность:

1. Модули pod AKS разрешают полное доменное имя платформы Azure как услуга (PaaS) с помощью центральных DNS-серверов в подписке на подключение, которые определяются как пользовательские DNS-серверы в виртуальной сети AKS.
2. Разрешенный IP-адрес — это частный IP-адрес частных конечных точек, доступ к которым осуществляется непосредственно из модулей pod AKS.

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

Рекомендации по проектированию

• Если политика безопасности требует, чтобы API Kubernetes был частный (а не общедоступный) IP-адрес, разверните частный кластер AKS.
  • Используйте пользовательские частные зоны DNS при создании частного кластера вместо того, чтобы позволить процессу создания использовать системную частную зону DNS.
• В диапазон IP-адресов, которые можно назначить кластеру AKS, не ограничен, используйте сетевой интерфейс контейнеров Azure (CNI) как сетевую модель.
  • Следуйте инструкциям из документации по планированию IP-адресов с помощью CNI.
  • Сведения о проверке конечных ограничений с помощью пулов узлов Windows Server и виртуальных узлов см. в статье Часто задаваемые вопросы о поддержке Windows AKS.
• Используйте Защиту от атак DDoS Azure для защиты виртуальной сети, используемой для кластера AKS, если вы не используете Брандмауэр Azure или WAF в централизованной подписке.
• Используйте конфигурацию DNS, связанную с общей сетевой конфигурацией, вместе с виртуальной глобальной сетью Azure или звездообразной топологией, зонами Azure DNS и собственной инфраструктурой DNS.
• Используйте приватный канал для защиты сетевых подключений и частные IP-подключения к другим управляемым службам Azure, которые поддерживают приватный канал, такие как служба хранилища Azure, реестр контейнеров Azure, База данных SQL Azure и Azure Key Vault.
• Используйте контроллер входящего трафика для обеспечения расширенной маршрутизации и безопасности HTTP, а затем и единой конечной точки для приложений.
• Все веб-приложения, настроенные для приема входящего трафика, должны использовать TLS-шифрование и не разрешать доступ через незашифрованный HTTP. Эта политика уже применяется, если подписка включает рекомендуемые политики в политиках, включенных в базовые реализации целевых зон корпоративного масштаба.
• При необходимости для сохранения ресурсов вычислений и хранения в кластере AKS используйте контроллер входящего трафика вне кластера.
  • Используйте надстройку Контроллер входящего трафика Шлюза приложений Azure (AGIC) — собственную управляемую службу Azure.
  • С помощью AGIC разверните выделенную Шлюз приложений Azure для каждого кластера AKS и не совместно используете одинаковые Шлюз приложений в нескольких кластерах AKS.
  • Если ресурсов или операционных ограничений нет, или AGIC не предоставляет необходимые функции, используйте решение контроллера входящего трафика в кластере, например NGINX, Traefik или любое другое решение, поддерживаемое Kubernetes.
• Для внутренних веб-приложений, критически важных для доступа к Интернету и обеспечения безопасности, используйте брандмауэр веб-приложений с контроллером входящего трафика.
  • И шлюз приложений Azure, и Azure Front Door включают брандмауэр веб-приложений Azure для защиты веб-приложений.
• Если политика безопасности требует проверки всего интернет-трафика из кластера AKS, защитите исходящий сетевой трафик с помощью брандмауэра Azure или стороннего сетевого виртуального модуля (NVA), развернутого в управляемой виртуальной сети концентратора. Дополнительные сведения см. в статье Ограничение исходящего трафика. Для UDR типа исходящего трафика AKS требуется связывание таблицы маршрутов с подсетью узла AKS, поэтому ее нельзя использовать сегодня с динамической внедрением маршрутов, поддерживаемой Azure Виртуальная глобальная сеть или сервером маршрутов Azure.
• Для общедоступных кластеров используйте диапазоны авторизованных IP-адресов.
• Используйте стандартный, а не базовый уровень подсистемы балансировки нагрузки.
• При разработке кластера Kubernetes в Azure одним из ключевых аспектов является выбор соответствующей сетевой модели для конкретных требований. Служба Azure Kubernetes (AKS) предлагает три различных сетевых модели: Kubenet, Azure CNI и Наложение Azure CNI. Чтобы принять обоснованное решение, важно понимать возможности и характеристики каждой модели.

Сравнение признаков трех сетевых моделей в AKS; Kubenet, Azure CNI и Azure CNI Overlay см. в статье "Сравнение сетевых моделей в AKS".