Рекомендации по топологии сети и подключению для Azure Red Hat OpenShift

Ознакомьтесь с рекомендациями по проектированию и топологии сети и подключениям при использовании акселератора целевой зоны Azure Red Hat OpenShift.

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

• Для Azure Red Hat OpenShift требуется первичная подсеть и вторичная подсеть.

  • Используйте основную подсеть для развертывания главных узлов кластера.
  • Используйте вторичную подсеть для развертывания рабочих узлов кластера.
  • Вторичная подсеть и основная подсеть должны быть минимальным /27 маршрутом.
  • После развертывания кластера невозможно изменить вторичную подсеть или основную подсеть.
  • Основная подсеть и вторичная подсеть не могут иметь связанную с ними группу безопасности сети. Кластер Azure Red Hat OpenShift автоматически создает и управляет группой безопасности сети.
  • Вторичная подсеть и основная подсеть не могут перекрываться с локальными сетями или любой другой сетью в Azure.

• Тщательно спланируйте IP-адреса и размер подсети виртуальной сети для поддержки масштабирования кластера. Возможно, потребуется добавить узлы.

• Вы можете предоставлять службы и маршруты Azure Red Hat OpenShift с помощью общедоступных или внутренних подсистем балансировки нагрузки. Настройте внутренние подсистемы балансировки нагрузки в той же подсети, что и вторичные узлы. В ограниченном кластере исходящего трафика нельзя использовать общедоступные подсистемы балансировки нагрузки из-за асимметричной маршрутизации.

• Azure Red Hat OpenShift использует CoreDNS для предоставления разрешения имен модулям pod, работающим в кластере.

  • CoreDNS напрямую разрешает внутренние домены кластера.
  • Azure Red Hat OpenShift также поддерживает пользовательские DNS-серверы в виртуальной сети.
  • Другие домены перенаправляются на DNS-серверы, настроенные в Azure виртуальная сеть. DNS-серверы будут либо сопоставителями Azure DNS по умолчанию, либо любыми настраиваемыми DNS-серверами, настроенными на уровне виртуальной сети.
  • Вы можете настроить перенаправление DNS в Azure Red Hat OpenShift CoreDNS.
  • Если пользовательские DNS-серверы не настроены в виртуальной сети, Azure Red Hat OpenShift использует сопоставитель Azure DNS по умолчанию.

  Дополнительные сведения о DNS см. в статье о конфигурации DNS частной конечной точки Azure.

• Вы можете отправлять исходящий (исходящий) сетевой трафик через Брандмауэр Azure или через кластер виртуального сетевого устройства.

  • По умолчанию кластеры Azure Red Hat OpenShift имеют неограниченный исходящий доступ к Интернету.
  • Вы можете развернуть Azure Red Hat OpenShift с ограниченным трафиком исходящего трафика, добавив определяемый пользователем маршрут (UDR), имеющий 0.0.0.0/0 маршрут для Брандмауэр Azure или в сетевое виртуальное устройство. Azure Red Hat OpenShift имеет функцию блокировки исходящего трафика, которая обеспечивает доступ, даже если исходящий трафик ограничен устройством брандмауэра или другими средствами.
  • Вы можете выбрать две модели развертывания Azure Red Hat OpenShift:
    • Конечная точка сервера частного API и частный контроллер входящего трафика
    • Конечная точка сервера общедоступного API и общедоступный контроллер входящего трафика
  • Если вы используете неограниченный доступ к исходящему трафику, необходимо тщательно управлять исходящими портами, чтобы убедиться, что вы не используете все доступные исходящие порты. Дополнительные сведения см. в разделе "Использование преобразования сетевых адресов источника" (SNAT) для исходящих подключений.

• По умолчанию все модули pod в кластере Azure Red Hat OpenShift могут отправлять и получать трафик без ограничений. Все модули pod в проекте доступны из других модулей pod и сетевых конечных точек. Чтобы изолировать один или несколько модулей pod в проекте, можно создать NetworkPolicy объекты в проекте, чтобы указать разрешенные входящие подключения. Сеть Red Hat OpenShift, определяемая программным обеспечением (SDN), поддерживает использование политики сети в режиме изоляции сети по умолчанию.

• Сетка служб предоставляет такие возможности, как управление трафиком, устойчивость, политика, безопасность, надежный идентификатор и наблюдаемость. Дополнительные сведения о сетке службы Red Hat OpenShift см. в разделе "Сетка службы" и "Istio".

• Глобальные механизмы балансировки нагрузки, такие как Диспетчер трафика Azure и Azure Front Door, повышают устойчивость путем маршрутизации трафика между несколькими кластерами, потенциально в разных регионах Azure.

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

IP-адрес кластера API OpenShift для Azure Red Hat может быть общедоступным или частным. Частные кластеры предоставляют API Azure Red Hat OpenShift через частный IP-адрес, но не через общедоступный. Доступ к API OpenShift Для Azure Red Hat не должен осуществляться через ЕГО IP-адрес. Вместо этого перейдите к API Azure Red Hat OpenShift через полное доменное имя (FQDN). Azure DNS разрешает полное доменное имя API OpenShift Для Azure Red Hat к IP-адресу.

В соответствии с проверенными рекомендациями целевой зоны Azure разрешение DNS для рабочих нагрузок Azure предлагается централизованными DNS-серверами, развернутыми в подписке на подключение. Dns-серверы Azure находятся в концентраторе виртуальной сети или в виртуальной сети общих служб, подключенной к экземпляру Azure Виртуальная глобальная сеть. DNS-серверы условно разрешают имена azure и общедоступные имена с помощью Azure DNS (IP-адрес 168.63.129.16). Серверы разрешают частные имена с помощью корпоративных DNS-серверов. Эта модель подключения распространена, и важно разрешить частный доступ к другим ресурсам Azure, если вы используете частные конечные точки.

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

Используйте входящие контроллеры (входящего трафика) для предоставления приложений, работающих в кластерах Azure Red Hat OpenShift.

• Контроллеры входящего трафика обеспечивают маршрутизацию на уровне приложения только с небольшим увеличением сложности.
• Azure Red Hat OpenShift создает универсальную запись DNS, которая упрощает доступ к предоставляемым приложениям в кластере. Примером записи DNS является *.apps.<cluster-ID>.<region>.aroapp.io. Это полезно для частного кластера для маршрутизации трафика для приложения.
• Azure Red Hat OpenShift предлагает встроенный контроллер и маршруты входящего трафика.
• Вы можете использовать входящий трафик Azure Red Hat OpenShift с Azure Front Door.
• Выровняйте конфигурацию с структурой фильтрации исходящего трафика, чтобы избежать асимметричной маршрутизации. UDR потенциально может привести к асимметричной маршрутизации.
• Если для сценария требуется завершение TLS, рассмотрите способ управления сертификатами TLS.

Внимание

Если вы используете Брандмауэр Azure для ограничения исходящего трафика и создания UDR для принудительного принудительного трафика исходящего трафика, убедитесь, что в Брандмауэр Azure правильно разрешить трафик входящего трафика. Использование Брандмауэра Azure в сочетании с определяемыми пользователем маршрутами нарушает передачу входящего трафика из-за асимметричной маршрутизации. Проблема возникает, если подсеть Azure Red Hat OpenShift имеет маршрут по умолчанию, который переходит к частному IP-адресу брандмауэра, но вы используете общедоступную подсистему балансировки нагрузки (входящий трафик или службу Kubernetes типа Load Balancer). В этом случае входящий трафик подсистемы балансировки нагрузки поступает через общедоступный IP-адрес, а обратный путь проходит через частный IP-адрес брандмауэра. Так как брандмауэр находится в состоянии, он удаляет возвращаемый пакет, так как брандмауэр не обнаруживает установленный сеанс. Сведения о том, как интегрировать Брандмауэр Azure с подсистемой балансировки нагрузки для входящего трафика или служб, см. в статье Интеграция Брандмауэра Azure с Azure Load Balancer (цен. категория "Стандартный").

Следующие шаги описывают поток, если вы используете Azure Front Door с частным кластером Azure Red Hat OpenShift и контроллером входящего трафика:

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

В этих шагах описывается поток для не-веб-приложения, который обращается к частному кластеру Azure Red Hat OpenShift:

1. Клиенты из общедоступного Интернета разрешают DNS-имя приложения, указывающего на общедоступный IP-адрес Брандмауэр Azure или сетевого виртуального устройства.
2. Брандмауэр Azure или виртуальное сетевое устройство перенаправит трафик (DNAT) в частный кластер Azure Red Hat OpenShift с помощью частного IP-адреса внутренней подсистемы балансировки нагрузки сети Azure для доступа к приложению в контроллере входящего трафика Azure Red Hat OpenShift.

Трафик из модулей pod Azure Red Hat OpenShift в серверные службы

Модули pod, работающие в кластере Azure Red Hat OpenShift, могут потребоваться для доступа к внутренним службам, таким как служба хранилища Azure, Azure Key Vault, База данных SQL Azure и Azure Cosmos DB. Конечные точки службы виртуальной сети можно использовать и Приватный канал Azure для защиты подключения к этим управляемым Azure службам.

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

Вы можете вручную создать записи A, но связывание частной зоны DNS с частной конечной точкой приводит к настройке, которая менее подвержена неправильной настройке.

Серверное подключение из модулей pod Azure Red Hat OpenShift к платформе Azure как услуга (PaaS), предоставляемых через частные конечные точки, следует следующей последовательности:

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

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

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

• Если политика безопасности требует использования частного IP-адреса для API Azure Red Hat OpenShift, разверните частный кластер Azure Red Hat OpenShift.
• Используйте Службу защиты от атак DDoS Azure для защиты виртуальной сети, используемой для кластера Azure Red Hat OpenShift, если вы не используете Брандмауэр Azure или Брандмауэр веб-приложений в централизованной подписке.
• Используйте конфигурацию DNS, связанную с общей настройкой сети с помощью Azure Виртуальная глобальная сеть или концентратора и периферийной архитектуры, зон Azure DNS и собственной инфраструктуры DNS.
• Используйте Приватный канал Azure для защиты сетевых подключений и использования подключения на основе частного IP-адреса к другим управляемым службам Azure, поддерживающим Приватный канал, например служба хранилища Azure, Реестр контейнеров Azure, База данных SQL Azure и Azure Key Vault.
• Используйте контроллер входящего трафика, чтобы обеспечить расширенную маршрутизацию и безопасность HTTP и предложить одну конечную точку для приложений.
• Все веб-приложения, настроенные для использования входящего трафика, должны использовать шифрование TLS и не должны разрешать доступ через незашифрованный HTTP.
• Используйте Azure Front Door с Брандмауэр веб-приложений для безопасной публикации приложений Azure Red Hat OpenShift в Интернете.
• Если вашей политике безопасности требуется проверить весь исходящий интернет-трафик, созданный в кластере Azure Red Hat OpenShift, безопасный исходящий сетевой трафик с помощью Брандмауэр Azure или стороннего сетевого виртуального устройства, развернутого в виртуальной сети управляемого концентратора. Дополнительные сведения см. в разделе "Управление исходящим трафиком" в кластер Azure Red Hat OpenShift.
• Используйте уровень "Стандартный" azure Load Balancer вместо уровня "Базовый" для не веб-приложений.

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

• Планирование организации ресурсов для Azure Red Hat OpenShift.