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

Azure Arc

Служба Azure Kubernetes (AKS)

Azure Monitor

Политика Azure

Управление доступом на основе ролей в Azure

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

Архитектура

На этой схеме архитектуры показаны различные службы Azure и их функциональные возможности. Два значка, представляющие кластеры Kubernetes с поддержкой Azure Arc, находятся в разделе, который помечен локально. Четыре значка, представляющие Azure Monitor, политику Azure и службу Azure Kubernetes (AKS), находятся в разделе, который называется Azure. Значок AKS отображается два раза. Стрелки указывают подключение между разделом Azure и двумя кластерами Kubernetes с поддержкой Azure Arc в локальном разделе. Стрелки также указывают на подключение между политикой Azure, кластерами как в локальной среде, так и в разделах Azure, а также в Azure Monitor.

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

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

Следующий рабочий процесс соответствует предыдущей схеме:

• Kubernetes с поддержкой Azure Arc: Подключите и настройте кластеры Kubernetes внутри или за пределами Azure с помощью Kubernetes с поддержкой Azure Arc. При присоединении кластера Kubernetes к Azure Arc он назначает идентификатор Azure Resource Manager и управляемое удостоверение.

• Служба Azure Kubernetes (AKS): Кластеры Kubernetes в Azure позволяют снизить сложность и эксплуатационные расходы на управление кластерами Kubernetes.

• Локальный кластер Kubernetes: Присоединение кластеров Kubernetes с сертификацией Cloud Native Computing Foundation (CNCF), размещенных в локальных или не microsoft облачных средах.

• Политика Azure: Развертывание политик и управление ими для кластеров Kubernetes с поддержкой Azure Arc.

• Azure Monitor: Наблюдайте и отслеживайте кластеры Kubernetes с поддержкой Azure Arc.

Компоненты

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

• AKS — это управляемая служба для развертывания и масштабирования кластеров Kubernetes.

• Политика Azure позволяет достичь соответствия облачным решениям в режиме реального времени в масштабе с согласованным управлением ресурсами.

• Azure Monitor обеспечивает сквозную наблюдаемость для приложений, инфраструктуры и сети.

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

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

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

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

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

• Использование Azure Monitor для мониторинга кластеров Kubernetes в гибридных средах.

• Использование политики Azure для развертывания и применения политик для кластеров Kubernetes в гибридных средах.

• Использование политики Azure для развертывания и применения GitOps.

• Максимальное увеличение инвестиций в локальную единицу обработки графики (GPU) путем обучения и развертывания рабочих процессов машинного обучения Azure.

• Использование управляемой службы Azure Monitor для Prometheus и Managed Grafana для отслеживания и визуализации рабочих нагрузок Kubernetes.

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

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

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

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

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

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

• Проверяет deployment.apps/config-agent подключенный кластер для ресурсов конфигурации системы управления версиями, применяемых к кластеру, и обновляет состояние соответствия.

• Это deployment.apps/controller-manager оператор операторов, которые оркеструет взаимодействие между компонентами Azure Arc.

• Собирает deployment.apps/metrics-agent метрики из других агентов Azure Arc, чтобы обеспечить оптимальную работу этих агентов.

• Собирает deployment.apps/cluster-metadata-operator метаданные кластера, включая версию кластера, количество узлов и версию агента Azure Arc.

• Он deployment.apps/resource-sync-agent синхронизирует ранее упомянутые метаданные кластера с Azure.

• Он deployment.apps/clusteridentityoperator поддерживает сертификат управляемого удостоверения службы, используемый другими агентами для взаимодействия с Azure.

• Собирает deployment.apps/flux-logs-agent журналы из операторов flux, развернутых в рамках конфигурации системы управления версиями.

• Устанавливает deployment.apps/extension-manager и управляет жизненным циклом диаграмм helm расширения.

• Проверка deployment.apps/kube-aad-proxy подлинности для запросов, отправленных в кластер с помощью функции подключения кластера AKS.

• Это deployment.apps/clusterconnect-agent агент обратного прокси-сервера, который позволяет функции подключения кластера предоставлять доступ к серверу API кластера. Это необязательный компонент, развернутый только в том случае, если функция подключения кластера включена в кластере.

• Это deployment.apps/guard сервер веб-перехватчика проверки подлинности и авторизации, используемый для управления доступом на основе ролей Microsoft Entra (RBAC). Это необязательный компонент, развернутый только в том случае, если Azure RBAC включен в кластере.

• Собирает deployment.apps/extension-events-collector журналы, связанные с управлением жизненным циклом расширений. Он объединяет эти журналы в события, соответствующие каждой операции, например создание, обновление и удаление.  

• Собирает deployment.apps/logcollector данные телеметрии платформы, чтобы обеспечить работоспособность платформы.

Дополнительные сведения см. в статье "Подключение существующего кластера 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 для мониторинга Kubernetes.

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

Дополнительные сведения см. в разделе "Включение мониторинга для кластеров Kubernetes".

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

Используйте политику Azure, чтобы убедиться, что каждый ресурс или Microsoft.ContainerService/managedClusters ресурс с поддержкой Microsoft.Kubernetes/connectedclusters GitOps применяется Microsoft.KubernetesConfiguration/fluxConfigurations к нему. Например, можно применить базовую конфигурацию к одному или нескольким кластерам или развернуть определенные приложения в нескольких кластерах. Чтобы использовать политику Azure, выберите определение из встроенных определений политики Azure для Kubernetes с поддержкой Azure Arc , а затем создайте назначение политики. При создании назначения политики задайте область для группы ресурсов Или подписки Azure. Также задайте параметры для созданного fluxConfiguration объекта. При создании назначения подсистема политик Azure определяет все connectedCluster или 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, развертывает приложения из исходного репозитория и распространяет все обновления, внесенные в ресурс fluxConfigurationKubernetes. Вы можете создать несколько fluxConfiguration ресурсов с помощью namespace области в одном кластере Kubernetes с поддержкой Azure Arc для обеспечения многотенантности.

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

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

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

Запуск машинного обучения

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

Мониторинг рабочих нагрузок Kubernetes с помощью управляемого Prometheus и Grafana

Azure Monitor предоставляет управляемую службу для развертываний Prometheus и Grafana, чтобы воспользоваться этими популярными средствами мониторинга Kubernetes. Эта управляемая служба позволяет использовать эти средства без необходимости управлять и обновлять развертывания самостоятельно. Чтобы проанализировать метрики Prometheus, используйте обозреватель метрик с PromQL.

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

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

Конечная точка (DNS)	Описание
https://management.azure.com:443	Требуется для подключения агента к Azure и регистрации кластера.
https://[region].dp.kubernetesconfiguration.azure.com:443	Конечная точка плоскости данных для агента для отправки сведений о состоянии и получения сведений о конфигурации, где [регион] представляет регион Azure, на котором размещен экземпляр AKS.
https://docker.io:443	Требуется для извлечения образов контейнеров.
https://github.com:443, git://github.com:9418	Примеры репозиториев GitOps размещаются на сайте GitHub. Агент конфигурации требует подключения к указанной конечной точке Git.
https://login.microsoftonline.com:443, , https://<region>.login.microsoft.comlogin.windows.net	Требуется для извлечения и обновления маркеров Azure Resource Manager.
https://mcr.microsoft.com:443 https://*.data.mcr.microsoft.com:443	Требуется агентам Azure Arc для извлечения образов контейнеров.

Полный список 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. Эта практика полезна в конвейерах непрерывной интеграции и непрерывной доставки, таких как Azure Pipelines и GitHub Actions. Дополнительные сведения см. в статье "Создание субъекта-службы с поддержкой Azure Arc".

• Чтобы упростить управление субъектом-службой, можно использовать управляемые удостоверения в AKS. Однако кластеры должны создаваться с помощью управляемого удостоверения. Существующие кластеры, включая Azure и локальные кластеры, нельзя перенести на управляемые удостоверения. Для получения дополнительной информации см. статью об использовании управляемой идентичности в AKS.

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

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

Общие рекомендации по затратам см. в разделе "Принципы проектирования оптимизации затрат".

Операционное превосходство

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

• Перед настройкой кластеров Kubernetes с поддержкой Azure Arc просмотрите ограничения подписки Azure Resource Manager и ограничения группы ресурсов , чтобы спланировать количество кластеров.

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

Соавторы

Корпорация Майкрософт поддерживает эту статью. Следующие авторы написали эту статью.

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

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

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

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

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

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

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

• Дизайн гибридной архитектуры
• Гибридные параметры Azure

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

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

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

Архитектура

На этой схеме архитектуры показаны различные службы Azure и их функциональные возможности. Два значка, представляющие кластеры Kubernetes с поддержкой Azure Arc, находятся в разделе, который помечен локально. Четыре значка, представляющие Azure Monitor, политику Azure и службу Azure Kubernetes (AKS), находятся в разделе, который называется Azure. Значок AKS отображается два раза. Стрелки указывают подключение между разделом Azure и двумя кластерами Kubernetes с поддержкой Azure Arc в локальном разделе. Стрелки также указывают на подключение между политикой Azure, кластерами как в локальной среде, так и в разделах Azure, а также в Azure Monitor.

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

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

Следующий рабочий процесс соответствует предыдущей схеме:

• Kubernetes с поддержкой Azure Arc: Подключите и настройте кластеры Kubernetes внутри или за пределами Azure с помощью Kubernetes с поддержкой Azure Arc. При присоединении кластера Kubernetes к Azure Arc он назначает идентификатор Azure Resource Manager и управляемое удостоверение.

• Служба Azure Kubernetes (AKS): Кластеры Kubernetes в Azure позволяют снизить сложность и эксплуатационные расходы на управление кластерами Kubernetes.

• Локальный кластер Kubernetes: Присоединение кластеров Kubernetes с сертификацией Cloud Native Computing Foundation (CNCF), размещенных в локальных или не microsoft облачных средах.

• Политика Azure: Развертывание политик и управление ими для кластеров Kubernetes с поддержкой Azure Arc.

• Azure Monitor: Наблюдайте и отслеживайте кластеры Kubernetes с поддержкой Azure Arc.

Компоненты

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

• AKS — это управляемая служба для развертывания и масштабирования кластеров Kubernetes.

• Политика Azure позволяет достичь соответствия облачным решениям в режиме реального времени в масштабе с согласованным управлением ресурсами.

• Azure Monitor обеспечивает сквозную наблюдаемость для приложений, инфраструктуры и сети.

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

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

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

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

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

• Использование Azure Monitor для мониторинга кластеров Kubernetes в гибридных средах.

• Использование политики Azure для развертывания и применения политик для кластеров Kubernetes в гибридных средах.

• Использование политики Azure для развертывания и применения GitOps.

• Максимальное увеличение инвестиций в локальную единицу обработки графики (GPU) путем обучения и развертывания рабочих процессов машинного обучения Azure.

• Использование управляемой службы Azure Monitor для Prometheus и Managed Grafana для отслеживания и визуализации рабочих нагрузок Kubernetes.

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

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

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

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

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

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

• Проверяет deployment.apps/config-agent подключенный кластер для ресурсов конфигурации системы управления версиями, применяемых к кластеру, и обновляет состояние соответствия.

• Это deployment.apps/controller-manager оператор операторов, которые оркеструет взаимодействие между компонентами Azure Arc.

• Собирает deployment.apps/metrics-agent метрики из других агентов Azure Arc, чтобы обеспечить оптимальную работу этих агентов.

• Собирает deployment.apps/cluster-metadata-operator метаданные кластера, включая версию кластера, количество узлов и версию агента Azure Arc.

• Он deployment.apps/resource-sync-agent синхронизирует ранее упомянутые метаданные кластера с Azure.

• Он deployment.apps/clusteridentityoperator поддерживает сертификат управляемого удостоверения службы, используемый другими агентами для взаимодействия с Azure.

• Собирает deployment.apps/flux-logs-agent журналы из операторов flux, развернутых в рамках конфигурации системы управления версиями.

• Устанавливает deployment.apps/extension-manager и управляет жизненным циклом диаграмм helm расширения.

• Проверка deployment.apps/kube-aad-proxy подлинности для запросов, отправленных в кластер с помощью функции подключения кластера AKS.

• Это deployment.apps/clusterconnect-agent агент обратного прокси-сервера, который позволяет функции подключения кластера предоставлять доступ к серверу API кластера. Это необязательный компонент, развернутый только в том случае, если функция подключения кластера включена в кластере.

• Это deployment.apps/guard сервер веб-перехватчика проверки подлинности и авторизации, используемый для управления доступом на основе ролей Microsoft Entra (RBAC). Это необязательный компонент, развернутый только в том случае, если Azure RBAC включен в кластере.

• Собирает deployment.apps/extension-events-collector журналы, связанные с управлением жизненным циклом расширений. Он объединяет эти журналы в события, соответствующие каждой операции, например создание, обновление и удаление.  

• Собирает deployment.apps/logcollector данные телеметрии платформы, чтобы обеспечить работоспособность платформы.

Дополнительные сведения см. в статье "Подключение существующего кластера 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 для мониторинга Kubernetes.

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

Дополнительные сведения см. в разделе "Включение мониторинга для кластеров Kubernetes".

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

Используйте политику Azure, чтобы убедиться, что каждый ресурс или Microsoft.ContainerService/managedClusters ресурс с поддержкой Microsoft.Kubernetes/connectedclusters GitOps применяется Microsoft.KubernetesConfiguration/fluxConfigurations к нему. Например, можно применить базовую конфигурацию к одному или нескольким кластерам или развернуть определенные приложения в нескольких кластерах. Чтобы использовать политику Azure, выберите определение из встроенных определений политики Azure для Kubernetes с поддержкой Azure Arc , а затем создайте назначение политики. При создании назначения политики задайте область для группы ресурсов Или подписки Azure. Также задайте параметры для созданного fluxConfiguration объекта. При создании назначения подсистема политик Azure определяет все connectedCluster или 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, развертывает приложения из исходного репозитория и распространяет все обновления, внесенные в ресурс fluxConfigurationKubernetes. Вы можете создать несколько fluxConfiguration ресурсов с помощью namespace области в одном кластере Kubernetes с поддержкой Azure Arc для обеспечения многотенантности.

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

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

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

Запуск машинного обучения

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

Мониторинг рабочих нагрузок Kubernetes с помощью управляемого Prometheus и Grafana

Azure Monitor предоставляет управляемую службу для развертываний Prometheus и Grafana, чтобы воспользоваться этими популярными средствами мониторинга Kubernetes. Эта управляемая служба позволяет использовать эти средства без необходимости управлять и обновлять развертывания самостоятельно. Чтобы проанализировать метрики Prometheus, используйте обозреватель метрик с PromQL.

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

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

Конечная точка (DNS)	Описание
https://management.azure.com:443	Требуется для подключения агента к Azure и регистрации кластера.
https://[region].dp.kubernetesconfiguration.azure.com:443	Конечная точка плоскости данных для агента для отправки сведений о состоянии и получения сведений о конфигурации, где [регион] представляет регион Azure, на котором размещен экземпляр AKS.
https://docker.io:443	Требуется для извлечения образов контейнеров.
https://github.com:443, git://github.com:9418	Примеры репозиториев GitOps размещаются на сайте GitHub. Агент конфигурации требует подключения к указанной конечной точке Git.
https://login.microsoftonline.com:443, , https://<region>.login.microsoft.comlogin.windows.net	Требуется для извлечения и обновления маркеров Azure Resource Manager.
https://mcr.microsoft.com:443 https://*.data.mcr.microsoft.com:443	Требуется агентам Azure Arc для извлечения образов контейнеров.

Полный список 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. Эта практика полезна в конвейерах непрерывной интеграции и непрерывной доставки, таких как Azure Pipelines и GitHub Actions. Дополнительные сведения см. в статье "Создание субъекта-службы с поддержкой Azure Arc".

• Чтобы упростить управление субъектом-службой, можно использовать управляемые удостоверения в AKS. Однако кластеры должны создаваться с помощью управляемого удостоверения. Существующие кластеры, включая Azure и локальные кластеры, нельзя перенести на управляемые удостоверения. Для получения дополнительной информации см. статью об использовании управляемой идентичности в AKS.

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

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

Общие рекомендации по затратам см. в разделе "Принципы проектирования оптимизации затрат".

Операционное превосходство

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

• Перед настройкой кластеров Kubernetes с поддержкой Azure Arc просмотрите ограничения подписки Azure Resource Manager и ограничения группы ресурсов , чтобы спланировать количество кластеров.

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

Соавторы

Корпорация Майкрософт поддерживает эту статью. Следующие авторы написали эту статью.

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

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

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

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

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

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

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

• Дизайн гибридной архитектуры
• Гибридные параметры Azure

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

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