Спланируйте сеть кластера для Azure Red Hat OpenShift с размещёнными плоскостями управления (предварительная версия)

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

Планирование вычислительной емкости

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

Ответы на следующие вопросы помогут спланировать подсети и диапазоны IP-адресов для кластера:

• Сколько пулов узлов вы будете использовать? Количество пулов узлов определяет, сколько подсетей может потребоваться. Если все пулы совместно используют рабочую подсеть кластера по умолчанию, достаточно одной подсети. Если вы назначаете отдельные подсети разным пулам, каждая из них увеличивает требования к CIDR виртуальной сети и машин.
• Будете ли вы разворачивать в нескольких зонах доступности? Каждый пул узлов развертывается в одной зоне доступности. Для распределения рабочих нагрузок между зонами для обеспечения высокой доступности требуется отдельный пул узлов и потенциально отдельная подсеть для каждой зоны. Дополнительные зоны означают больше подсетей и более крупный компьютер CIDR.
• Будет ли каждый пул узлов использовать собственную подсеть? Пулы узлов развертываются в рабочей подсети кластера по умолчанию, если не указать другую подсеть. Отдельные подсети обеспечивают сетевую изоляцию между пулами узлов, но каждая подсеть должна соответствовать диапазону CIDR компьютера и адресному пространству виртуальной сети.
• Сколько узлов вы будете запускать при пиковой нагрузке? Максимальное число узлов, включая максимальное максимальное значение автомасштабирования, определяет, насколько большой должна быть каждая подсеть. Кластер поддерживает не более 500 узлов во всех пулах.
• Вы позже добавите ещё пулы узлов? Диапазоны CIDR кластера не могут быть изменены после создания. Если вы планируете добавить пулы узлов с новыми подсетями в будущем, ciDR и виртуальная сеть должны иметь достаточно адресного пространства для их размещения.

Подсказка

Пример определения размера: Кластеру с 3 зонами доступности, до 50 узлов в каждой зоне и отдельной подсетью для каждой зоны требуются три /26 подсети (по 64 адреса в каждой, чего достаточно для 50 узлов и зарезервированных Azure адресов) и одна /29 подсеть интеграции с виртуальной сетью. Все четыре подсети укладываются в пределах CIDR машины /24 (256 адресов). Если вы планируете позже добавить новые пулы узлов, используйте более крупный диапазон CIDR для машин, например /22 или /16, чтобы осталось место для дополнительных подсетей.

Требования к подсети

Виртуальная сеть должна содержать следующие компоненты:

• Рабочая подсеть — подсеть по умолчанию, в которой развертываются рабочие узлы кластера. При создании пула узлов он развертывается в этой подсети, если не указать другую подсеть. Если планируется развернуть пулы узлов в нескольких зонах доступности, можно создать отдельную подсеть для каждой зоны. Все подсети пула узлов должны находиться в той же виртуальной сети, что и кластер. Размер каждой подсети в зависимости от количества рабочих узлов, которые планируется запустить в нем.
• Подсеть интеграции с виртуальной сетью (VNet) — выделенная подсеть, которая обеспечивает закрытое подключение между размещённой плоскостью управления (работающей в учётной записи Azure Red Hat) и рабочими узлами в вашей подписке. Он должен соответствовать следующим требованиям:
  • Минимальный размер /29
  • Расположен в той же виртуальной сети, что и рабочая подсеть
  • Не используется совместно с рабочей подсетью или подсетями пула узлов
• Группы безопасности сети — Если вы связываете группу безопасности сети (NSG) с рабочим узлом, пулом узлов или подсетью интеграции виртуальной сети, проверьте ее правила на соответствие требованиям к трафику, описанным в разделе Требуемый трафик для группы безопасности сети. Вы назначаете группы безопасности сети непосредственно подсетям.

Обязательный трафик для группы безопасности сети

Группа безопасности сети (NSG), связанная с пулом узлов и подсетями интеграции виртуальной сети, должна разрешить следующий трафик:

ассоциация NSG	Направление	Source	Destination	Конечные порты
Подсеть рабочих узлов или пула узлов	исходящий	Подсеть рабочего узла или пула узлов	Родительская подсеть кластера	TCP 443 и 6443
Подсеть интеграции с VNet	Inbound	Подсеть рабочего узла или пула узлов	Подсеть интеграции VNet	TCP 443 и 8443

Эти подключения позволяют рабочим узлам достичь размещенного сервера kube-apiserver и размещенного уровня управления. Если правило запрета NSG блокирует необходимый трафик, невозможно создать пулы узлов.

Чтобы исправить правило Deny, которое блокирует необходимый поток, выполните одно из следующих действий:

• Удалите правило "Запретить".
• Сузьте правило запрета, чтобы оно не применялось к требуемым источнику, адресу назначения и портам.
• Добавьте разрешающее правило, которое соответствует требуемому источнику, адресу назначения и портам и имеет более высокий приоритет, чем запрещающее правило. В NSG чем меньше числовое значение приоритета, тем выше его приоритет.

Azure Red Hat OpenShift с размещёнными управляющими плоскостями оценивает правила TCP и правила с подстановочными знаками, включающие необходимые порты. Запрещающие правила для несвязанных портов, UDP-трафика или несвязанных адресов назначения не влияют на эту проверку. Однако эти правила по-прежнему могут блокировать другой трафик.

Требования CIDR

В следующей таблице описаны требования к виртуальной сети и CIDR.

Требование к сети	По умолчанию	Description
CIDR-диапазон машины	10.0.0.0/16	Диапазон IP-адресов для вычислительных узлов. Он должен охватывать все диапазоны адресов CIDR для подсетей виртуальной сети, включая все подсети, которые планируется использовать для дополнительных пулов узлов. Подсети должны быть смежными. Для развертываний в одной зоне доступности поддерживается минимум 128 адресов (/25). Для развертываний в нескольких зонах доступности поддерживается минимум 256 адресов (/24).
Диапазон CIDR для служб	172.30.0.0/16	Диапазон IP-адресов для IP-адресов службы Kubernetes. Диапазон должен быть достаточно большим, чтобы вместить вашу рабочую нагрузку, и он не должен пересекаться с диапазонами, используемыми внешними службами, к которым осуществляется доступ из кластера.
Диапазон CIDR для подов	10.128.0.0/14	Диапазон IP-адресов для модулей pod. Диапазон должен быть достаточно большим, чтобы вместить вашу рабочую нагрузку, и он не должен пересекаться с диапазонами, используемыми внешними службами, к которым осуществляется доступ из кластера.
Префикс узла	23	Длина префикса подсети, выделенная каждому узлу для его подов. Значение 23 назначает для каждого узла подсеть /23 (512 IP-адресов) из диапазона CIDR подов.

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

• Модули pod, службы и CIDR компьютера не должны перекрываться друг с другом.
• CIDR-диапазоны pod'ов и сервисов не должны пересекаться с какими-либо диапазонами адресов, используемыми в вашей сети, или с диапазонами адресов любых внешних сервисов, к которым осуществляется доступ из кластера.
• CiDR компьютера должен охватывать все подсети виртуальной сети, используемые кластером, включая рабочую подсеть, все дополнительные подсети пула узлов и подсеть интеграции виртуальной сети. Если в будущем вы планируете добавить пулы узлов с отдельными подсетями, убедитесь, что диапазон CIDR для машин достаточно велик, чтобы охватить их. Например, если виртуальная сеть использует 10.0.0.0/16, то CIDR компьютера по умолчанию 10.0.0.0/16 охватывает все подсети.
• Сеть pod использует неизменяемые IP-адреса и используется только в программно-определяемой сети кластера.

Подключение к частному кластеру

Если вы выбрали частный сервер API, частный вход по умолчанию или оба, необходимо установить подключение к частной сети между сетями пользователей и виртуальной сетью кластера перед развертыванием кластера. Без этого подключения администраторы, конвейеры CI/CD и конечные пользователи не могут получить доступ к частным конечным точкам.

Распространенные варианты подключения:

• Пиринг виртуальных сетей Azure — подключите две виртуальные сети Azure, чтобы ресурсы в каждой сети могли взаимодействовать друг с другом.
• Azure VPN Gateway. Подключите локальную сеть к виртуальной сети кластера через VPN-туннель типа "сеть — сеть".
• Azure ExpressRoute. Создайте частное выделенное подключение из локальной сети для Azure через поставщика подключений.

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

Дальнейшие действия

Создание кластера