Гибридное управление и развертывание Azure Arc для кластеров Kubernetes

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

Архитектура

Скачайте файл Visio для этой архитектуры.

Рабочий процесс

Архитектура состоит из следующих аспектов:

• Kubernetes с поддержкой Azure Arc. Подключите и настройте кластеры Kubernetes внутри или за пределами Azure с помощью Kubernetes с поддержкой Azure Arc. При присоединении кластера Kubernetes к Azure Arc он назначает идентификатор Azure Resource Manager и управляемое удостоверение.
• Служба Azure Kubernetes. Кластеры Kubernetes в Azure позволяют снизить сложность и эксплуатационные расходы на управление кластерами Kubernetes.
• Локальный кластер Kubernetes. Присоединение кластеров Kubernetes с сертификацией Cloud Native Computing Foundation (CNCF), размещенных в локальных или сторонних облачных средах.
• Политика Azure. Развертывание политик и управление ими для кластеров Kubernetes с поддержкой Arc.
• Azure Monitor. Наблюдайте и отслеживайте кластеры Kubernetes с поддержкой Arc.

Компоненты

• Azure Arc — это мост, который расширяет платформу Azure, что позволяет создавать приложения и службы, которые могут выполняться в центрах обработки данных, в пограничных средах и в многооблачных средах.
• Служба Azure Kubernetes (AKS) — это управляемая служба для развертывания и масштабирования кластеров Kubernetes.
• Политика Azure позволяет достичь соответствия облачным решениям в режиме реального времени в масштабе с согласованным управлением ресурсами.
• Azure Monitor обеспечивает сквозную наблюдаемость для приложений, инфраструктуры и сети.

Подробности сценария

Azure Arc можно использовать для регистрации кластеров Kubernetes, размещенных за пределами Microsoft Azure. Затем вы можете использовать средства Azure для управления этими кластерами вместе с кластерами, размещенными в Служба Azure Kubernetes (AKS).

Потенциальные варианты использования

Типичные способы использования этой архитектуры:

• Управление локальными кластерами и кластерами Kubernetes, размещенными в AKS, для инвентаризации, группировки и тегов.
• Использование Azure Monitor для мониторинга кластеров Kubernetes в гибридных средах.
• Использование Политика Azure для развертывания и применения политик для кластеров Kubernetes в гибридных средах.
• Использование Политика Azure для развертывания и применения GitOps.

Рекомендации

В следующих разделах представлены рекомендации, которые применяются к большинству сценариев. Корпорация Майкрософт рекомендует следовать за ними, если у вас нет необходимости переопределить их.

Регистрация кластера

Вы можете зарегистрировать любой активный кластер CNCF Kubernetes. Для доступа к кластеру и роли администратора кластера в кластере требуется файл kubeconfig , чтобы развернуть агенты Kubernetes с поддержкой Arc. Интерфейс командной строки Azure используется для выполнения задач регистрации кластера. Пользователь или субъект-служба, используемые для команды az login и az connectedk8s connect , требуют разрешения на чтение и запись для типа ресурса Microsoft.Kubernetes/connectedClusters. Кластер Kubernetes — роль подключения Azure Arc имеет эти разрешения и может использоваться для назначений ролей в субъекте-пользователе или субъекте-службе. Helm 3 требуется для подключения кластера, использующего расширение connectedk8s. Для установки расширений интерфейса командной строки Kubernetes с поддержкой Azure Arc требуется azure CLI версии 2.3 или более поздней.

Агенты Azure Arc для Kubernetes

Kubernetes с поддержкой Azure Arc состоит из нескольких агентов (также называемых операторами), которые выполняются в кластере, развернутом в пространстве имен Azure-arc :

• deployment.apps/config-agent. Просматривает подключенный кластер для ресурсов конфигурации системы управления версиями, применяемых к кластеру, и обновляет состояние соответствия.
• deployment.apps/controller-manager. Является оператором для операторов, т. е. управляет взаимодействием между компонентами Azure Arc.
• deployment.apps/metrics-agent. Собирает метрики из других агентов Arc, чтобы обеспечить оптимальную производительность этих агентов.
• deployment.apps/cluster-metadata-operator. Собирает метаданные кластера, версию кластера, количество узлов и версию агента Azure Arc.
• deployment.apps/resource-sync-agent. Синхронизирует ранее упомянутые метаданные кластера с Azure.
• deployment.apps/clusteridentityoperator. Поддерживает сертификат управляемого удостоверения службы (MSI), используемый другими агентами для взаимодействия с Azure.
• deployment.apps/flux-logs-agent. Собирает журналы из операторов flux, развернутых в рамках конфигурации системы управления версиями.
• deployment.apps/extension-manager. Устанавливает и управляет жизненным циклом диаграмм расширения Helm.
• deployment.apps/kube-azure-ad-proxy. Используется для проверки подлинности запросов, отправляемых в кластер с помощью Cluster Connect.
• deployment.apps/clusterconnect-agent. Обратный прокси-агент, который позволяет функции подключения кластера предоставлять доступ к серверу API кластера. Это необязательный компонент, развернутый только в том случае, если функция подключения кластера включена в кластере.
• deployment.apps/guard. Сервер веб-перехватчика проверки подлинности и авторизации, используемый для управления доступом на основе ролей Microsoft Entra (RBAC). Это необязательный компонент, развернутый только в том случае, если функция azure-rbac включена в кластере.

Дополнительные сведения см. в статье "Подключение кластера Kubernetes с поддержкой Azure Arc".

Мониторинг кластеров с помощью аналитики контейнеров Azure Monitor

Мониторинг контейнеров является критически важной задачей. Аналитика контейнеров Azure Monitor предоставляет широкий интерфейс мониторинга для кластеров ядра AKS и AKS. Вы также можете настроить аналитику контейнеров Azure Monitor для мониторинга кластеров Kubernetes с поддержкой Azure Arc, размещенных за пределами Azure. Это обеспечивает комплексный мониторинг кластеров Kubernetes в azure, локальных и сторонних облачных средах.

Аналитика контейнеров Azure Monitor обеспечивает видимость производительности, собирая метрики памяти и процессора из контроллеров, узлов и контейнеров, метрик, доступных в Kubernetes с помощью интерфейса программирования приложений метрик (API). Также собираются журналы контейнеров. После включения мониторинга из кластеров Kubernetes метрики и журналы автоматически собираются для вас контейнерной версией агента Log Analytics. Метрики записываются в хранилище метрик, а данные журнала записываются в хранилище журналов, связанном с рабочей областью Log Analytics. Дополнительные сведения о аналитике контейнеров Azure Monitor см. в обзоре аналитики контейнеров Azure Monitor.

Вы можете включить аналитику контейнеров Azure Monitor для одного или нескольких развертываний Kubernetes с помощью скрипта PowerShell или скрипта Bash.

Чтобы включить мониторинг кластеров Kubernetes с поддержкой Arc, см. статью "Включение мониторинга кластера Kubernetes с поддержкой Azure Arc"

Использование Политика Azure для включения развертывания приложений на основе GitOps

Используйте Политика Azure для принудительного применения каждого ресурса Microsoft.Kubernetes/connectedclusters или ресурса Microsoft.ContainerService/managedClusters с определенными ресурсами Microsoft.KubernetesConfiguration/fluxConfiguration. Например, можно применить базовую конфигурацию к одному или нескольким кластерам или развернуть определенные приложения в нескольких кластерах. Чтобы использовать Политика Azure, выберите определение из встроенных определений Политика Azure для Kubernetes с поддержкой Azure Arc, а затем создайте назначение политики.

При создании назначения политики задайте область для группы ресурсов Или подписки Azure. Также задайте параметры созданной функции fluxConfiguration . При создании назначения подсистема политик определит все подключенные ресурсыCluster или managedCluster, расположенные в пределах области, а затем примените к каждому элементу fluxConfiguration.

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

Дополнительные сведения см. в статье "Развертывание приложений в масштабе с помощью конфигураций Flux версии 2 и Политика Azure".

Развертывание приложений с помощью GitOps

GitOps — это практика объявления требуемого состояния конфигурации Kubernetes (развертываний, пространств имен и т. д.) в исходном репозитории, таких как репозиторий Git или Helm, контейнеры или Хранилище BLOB-объектов Azure. За этим следует опрос и развертывание этих конфигураций на основе извлечения в кластер с помощью оператора.

Подключение между кластером и одним или несколькими исходными репозиториями включается путем развертывания расширения microsoft.flux в кластере. Свойства ресурса fluxConfiguration представляют, где и как ресурсы Kubernetes должны передаваться из исходного репозитория в кластер. Данные fluxConfiguration хранятся в неактивных данных в базе данных Azure Cosmos DB, чтобы обеспечить конфиденциальность данных.

Агент flux-config, работающий в кластере, отвечает за просмотр новых или обновленных ресурсов расширения fluxConfiguration в ресурсе Kubernetes с поддержкой Azure Arc, для развертывания приложений из исходного репозитория и распространения обновлений, внесенных в fluxConfiguration. Вы даже можете создать несколько ресурсов fluxConfiguration с помощью области пространства имен в одном кластере Kubernetes с поддержкой Azure Arc для достижения многотенантности.

Исходный репозиторий может содержать любые допустимые ресурсы Kubernetes, включая пространства имен, ConfigMaps, deployments и DaemonSets. Он также может содержать диаграммы Helm для развертывания приложений. Распространенные сценарии репозитория источников включают определение базовой конфигурации для организации, которая может включать общие роли и привязки RBAC, агенты мониторинга, агенты ведения журнала и службы на уровне кластера.

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

Дополнительные сведения см. в статье "Развертывание приложений с помощью GitOps с Flux версии 2".

Топология, сеть и маршрутизация

Для работы агентов Azure Arc требуются следующие протоколы, порты и исходящие URL-адреса:

Полный список URL-адресов в службах Azure Arc см. в статье о требованиях к сети Azure Arc.

Рекомендации

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

Надежность

Надежность гарантирует, что ваше приложение позволит вам выполнить ваши обязательства перед клиентами. Дополнительные сведения см. в разделе "Обзор основы надежности".

• В большинстве случаев расположение, выбранное при создании скрипта установки, должно быть регионом Azure, географически ближайшим к локальным ресурсам. Остальные данные хранятся в географическом регионе Azure, который содержит указанный регион, факт, который может повлиять на выбор региона, если у вас есть требования к месту расположения данных. Если сбой влияет на регион Azure, к которому подключен ваш компьютер, сбой не влияет на подключенный компьютер, но операции управления, использующие Azure, могут не завершиться. Для обеспечения устойчивости при региональном сбое лучше всего, если у вас несколько расположений, которые предоставляют географически избыточные службы, чтобы подключить компьютеры в каждом расположении к другому региону Azure. Сведения о доступных регионах см. в поддерживаемых регионах Для Kubernetes с поддержкой Azure Arc.
• Необходимо убедиться, что службы, на которые ссылаются в разделе "Архитектура ", поддерживаются в регионе, в котором развертывается Azure Arc.

Безопасность

Безопасность обеспечивает гарантии от преднамеренного нападения и злоупотребления ценными данными и системами. Дополнительные сведения см. в разделе "Общие сведения о компоненте безопасности".

• С помощью Azure RBAC можно управлять доступом к Kubernetes с поддержкой Azure Arc в azure и локальных средах, использующих удостоверения Microsoft Entra. Дополнительные сведения см. в статье "Использование Azure RBAC для авторизации Kubernetes".
• Корпорация Майкрософт рекомендует использовать субъект-службу с ограниченными привилегиями для подключения кластеров Kubernetes к Azure Arc. Эта практика полезна в конвейерах CI/CD, таких как Azure Pipelines и GitHub Actions. Дополнительные сведения см. в статье Создание подключения субъекта-службы с поддержкой Azure Arc.
• Чтобы упростить управление субъектом-службой, можно использовать управляемые удостоверения в AKS. Однако кластеры должны создаваться с помощью управляемого удостоверения, а существующие кластеры (включая Azure и локальные кластеры) нельзя перенести на управляемые удостоверения. Дополнительные сведения см. в статье Использование управляемых удостоверений в службе Kubernetes Azure.

Оптимизация затрат

Оптимизация затрат заключается в поиске способов уменьшения ненужных расходов и повышения эффективности работы. Дополнительные сведения см. в разделе Обзор критерия "Оптимизация затрат".

Общие рекомендации по затратам описаны в разделе "Принципы оптимизации затрат" в Microsoft Azure Well-Architected Framework.

Эффективность работы

Оперативное превосходство охватывает процессы операций, которые развертывают приложение и продолжают работать в рабочей среде. Дополнительные сведения см. в разделе "Общие сведения о принципах эффективности работы".

• Перед настройкой кластеров Kubernetes с поддержкой Azure Arc просмотрите ограничения подписки Azure Resource Manager и ограничения группы ресурсов, чтобы спланировать количество кластеров.
• Используйте Helm, средство упаковки с открытым кодом, чтобы установить жизненный цикл приложений Kubernetes и управлять ими. Как и диспетчеры пакетов Linux, такие как APT и Yum, используют Helm для управления диаграммами Kubernetes, которые являются пакетами предварительно настроенных ресурсов Kubernetes.

Соавторы

Эта статья поддерживается корпорацией Майкрософт. Первоначально он был написан следующими участниками.

Автор субъекта:

• Питер де Брюин | Старший менеджер по программам

Чтобы просмотреть недоступные профили LinkedIn, войдите в LinkedIn.

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

• Документация по Azure Arc
• Документация по Kubernetes с поддержкой Azure Arc
• Документация по Службе Azure Kubernetes
• Документация по службе "Политика Azure"
• Документация по Azure Monitor
• Подключение кластера Kubernetes с поддержкой Azure Arc

Связанные ресурсы

Связанные гибридные рекомендации:

• Дизайн гибридной архитектуры
• Гибридные параметры Azure
• Рекомендации по проектированию гибридных приложений

Связанные архитектуры:

• Базовая архитектура AKS в Azure Stack HCI
• Сетевая архитектура ДЛЯ AKS в Azure Stack HCI
• Оптимизация администрирования экземпляров SQL Server в локальных и многооблачных средах с помощью Azure Arc
• Корпоративный мониторинг с Azure Monitor