Рекомендации по топологии сети и подключению для AKS

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

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

Kubenet

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

Azure CNI

Azure CNI — это сетевая модель, предназначенная для расширенной сети. Он обеспечивает полное подключение к виртуальной сети для pod, позволяя устанавливать соединения между pod и между pod и виртуальными машинами (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 для предоставления разрешения имен подам, работающим в кластере, а исходящий сетевой трафик можно отправлять через брандмауэр Azure или кластер виртуальных сетевых устройств.

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

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

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

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

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

Следуя проверенным рекомендациям корпоративного масштаба, разрешение DNS для рабочих нагрузок Azure предлагается централизованными DNS-серверами, развернутыми в подписке на подключение, в виртуальной сети концентратора или в виртуальной сети общих служб, подключенной к виртуальной глобальной сети Azure. Эти серверы будут условно разрешать имена, связанные с Azure, и общедоступные имена с помощью Azure DNS (IP-адрес 168.63.129.16), а частные имена — с помощью корпоративных DNS-серверов. Однако эти централизованные DNS-серверы не смогут разрешить FQDN 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 Kubernetes AKS будет выполняться следующим образом:

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).
• Ingress-контроллеры могут запускаться вне кластера и в кластере.
  • Контроллер входящего трафика вне кластера разгружает вычисления (например, маршрутизацию HTTP-трафика или завершение соединения TLS) на другую службу за пределами AKS, например, надстройка контроллера входящего трафика шлюза приложений Azure (AGIC).
  • Решение в кластере использует ресурсы кластера AKS для вычислений (например, маршрутизации трафика HTTP или завершения TLS). Контроллеры входящего трафика в кластере могут предложить более низкую стоимость, но им требуется тщательное планирование ресурсов и обслуживание.
• Базовая надстройка маршрутизации http-приложений проста в использовании, но имеет некоторые ограничения, как описано в маршрутизации приложений HTTP.

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

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

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

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

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

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

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

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

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

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

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

Создать записи A можно вручную, но связывание частной зоны 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-адресом (вместо общедоступного IP-адреса), разверните частный кластер AKS.
  • Используйте пользовательские частные зоны DNS при создании частного кластера, а не разрешайте процессу создания использовать системную частную зону DNS.
• Используйте интерфейс сети контейнеров Azure (CNI) в качестве сетевой модели, если у вас нет ограниченного диапазона IP-адресов, которые можно назначить кластеру AKS.
  • Следуйте документации по планированию 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 Virtual WAN или Azure Route Server.
• Для не частных кластеров используйте авторизованные диапазоны IP-адресов.
• Используйте уровень "Стандартный", а не уровень "Базовый" в Azure Load Balancer.
• При разработке кластера Kubernetes в Azure одним из ключевых аспектов является выбор соответствующей сетевой модели для конкретных требований. Служба Azure Kubernetes (AKS) предлагает три различных сетевых модели: Kubenet, Azure CNI и Наложение Azure CNI. Чтобы принять обоснованное решение, важно понимать возможности и характеристики каждой модели.

Сравнение функций между тремя сетевыми моделями в AKS, Kubenet, Azure CNI и наложением Azure CNI см. в статье "Сравнение сетевых моделей в AKS".