Поделиться через

Рекомендации по организации ресурсов для Azure Red Hat OpenShift (необязательно)

  • Статья

Организация ресурсов в основном управляется платформой. Ниже приведены некоторые способы, которыми основа платформы может повлиять на акселератор целевой зоны Azure Red Hat OpenShift.

Структура подписки и группы ресурсов являются ключевыми рекомендациями по универсальным целевым зонам Azure. Они играют фундаментальную роль в управлении организацией ресурсов Azure Red Hat OpenShift. Подписки — это граница управления для управления ресурсами и изоляции. Как описано в разделе Группа управления и организация подписки, используйте подписки и группы управления для назначения политик ресурсам в пределах границ.

Например, если у вас есть общедоступные и частные приложения, разделите их на разные подписки и поместите в соответствующие группы управления с именами Corp и Onlineили другие группы управления под целевыми зонами. Подписки, которые живут в Corp группе управления, имеют политики, препятствующие созданию общедоступных IP-адресов. Подписки, которые живут в группах Online управления, обеспечивают подключение к Интернету и открытый доступ напрямую. Дополнительные сведения о том, какие политики применяются на разных уровнях структуры целевой зоны Azure, включая политики, относящиеся к ARO, см. в статье Политики, включенные в эталонные реализации целевых зон Azure.

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

  • Решите, кто будет управлять узлами контейнеров:

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

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

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

  • Выберите модель аренды для кластеров:

    • Один клиент, управляемый командой рабочей нагрузки: Для одного узла кластера, поддерживающего одну рабочую нагрузку, скорее всего, требуется выделенная целевая зона для сегментации и контроля команды рабочей нагрузки.

    • Технологические платформы, мультитенантные узлы: При централизованном управлении узлами эффективность работы происходит благодаря консолидации нескольких узлов и нескольких рабочих нагрузок в общих подписках целевой зоны. Консолидация сокращает количество целевых зон и узлов, выделенных для поддержки одного кластера или рабочей нагрузки.

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

      Совет

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

    • Централизованное управление с одним клиентом: Для враждебных или регулируемых рабочих нагрузок, которые по-прежнему работают централизованно, обычно имеются выделенные узлы для рабочих нагрузок. Благодаря консолидации поддерживаемых целевых зон вы можете продолжать работать эффективно.

  • Выберите иерархию группы управления на основе общего масштаба и сопоставления сред и узлов, необходимых для поддержки общих требований к портфелю:

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

  • Определите, какой реестр контейнеров следует использовать:

  • Решите, какую топологию реестра контейнеров использовать для распространения артефактов Open Container Initiative (OCI):

    • Один реестр на рабочую нагрузку.
    • Один реестр на кластер с несколькими рабочими нагрузками в реестре.
    • Один реестр для всех кластеров в целевой зоне с несколькими рабочими нагрузками и кластерами в одном реестре.
    • Один реестр для всех кластеров в нескольких целевых зонах с несколькими рабочими нагрузками и кластерами в одном реестре.

  • Определите область для политик реестра контейнеров в Политике Azure:

    • Настройте политику на уровне подписки, чтобы требовать, чтобы все узлы в целевой зоне использовали определенный реестр.
    • Разработайте более детализированную политику на уровне группы ресурсов.
    • Разработайте более широкую политику на уровне группы управления.

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

  • Определите стандарт именования и тегов , который будет применяться ко всем ресурсам контейнеров, развернутых в Azure. Как минимум, стандарт должен включать:
    • Имена рабочих нагрузок: Рабочая нагрузка или рабочие нагрузки, поддерживаемые каждым кластером.
    • Ресурсы кластера: Повышение прав на выравнивание ресурсов кластера поверх предыдущих рекомендаций.
    • Оператор узла: Какая команда отвечает за операции узла.
  • Реализуйте политику, чтобы требовать определенный реестр артефактов OCI, основанный на топологии реестра контейнеров вашей организации.

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