你当前正在访问 Microsoft Azure Global Edition 技术文档网站。如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

适用于 Kubernetes 群集的 Azure Arc 混合管理和部署

Azure Arc

Azure Kubernetes 服务 (AKS)

Azure Monitor

Azure Policy

Azure 基于角色的访问控制

本参考体系结构介绍了 Azure Arc 如何跨客户数据中心、边缘位置和多个云环境扩展 Kubernetes 群集管理和配置。

体系结构

下载此体系结构的 Visio 文件。

Workflow

以下工作流与上图相对应：

已启用 Azure Arc 的 Kubernetes： 使用已启用 Azure Arc 的 Kubernetes 在 Azure 内部或外部附加和配置 Kubernetes 群集。将 Kubernetes 群集附加到 Azure Arc 后，将获得 Azure 资源管理器 ID 和托管标识。
Azure Kubernetes 服务（AKS）： 在 Azure 中托管 Kubernetes 群集，以减少 Kubernetes 群集管理的复杂性和作开销。
本地 Kubernetes 群集： 附加本地或非Microsoft云环境中托管的经 Cloud Native Computing Foundation （CNCF）认证的 Kubernetes 群集。
Azure Policy： 为已启用 Azure Arc 的 Kubernetes 群集部署和管理策略。
Azure Monitor： 观察并监视已启用 Azure Arc 的 Kubernetes 群集。

组件数

Azure Arc 扩展了 Azure 平台，从而可以构建可在数据中心、边缘和多云环境中运行的应用程序和服务。
AKS 是用于部署和缩放 Kubernetes 群集的托管服务。
Azure Policy 使通过一致的资源治理实现大规模实时云合规性成为可能。
Azure Monitor 提供对应用程序、基础结构和网络的端到端可观测性。

方案详细信息

可以使用 Azure Arc 注册托管在 Microsoft Azure 外部的 Kubernetes 群集。然后，可以使用 Azure 工具管理这些群集和 AKS 托管的群集。

可能的用例

此体系结构的典型用途包括：

管理本地 Kubernetes 群集和 AKS 托管群集的清单、分组和标记。
使用 Azure Monitor 跨混合环境监视 Kubernetes 群集。
使用 Azure Policy 帮助跨混合环境部署和强制实施 Kubernetes 群集的策略。
使用 Azure Policy 帮助部署和强制实施 GitOps。
通过训练和部署 Azure 机器学习工作流，最大化本地图形处理单元（GPU）投资。
使用适用于 Prometheus 和 Managed Grafana 的 Azure Monitor 托管服务来监视和可视化 Kubernetes 工作负载。

建议

您可以将以下建议应用于大多数场景。除非有优先于这些建议的特定要求，否则请遵循这些建议。

群集注册

可以注册任何活动的 CNCF Kubernetes 群集。需要一个 kubeconfig 文件才能访问群集和群集上的群集管理员角色，以部署已启用 Azure Arc 的 Kubernetes 代理。使用 Azure CLI 执行群集注册任务。用于该 az login 命令 az connectedk8s connect 的用户或服务主体需要对 Microsoft.Kubernetes/connectedClusters 资源类型具有读取和写入权限。 Kubernetes 群集 - Azure Arc 载入角色拥有这些权限，可用于用户主体或服务主体的角色分配。需要 Helm 3 才能载入使用该扩展的 connectedk8s 群集。安装已启用 Azure Arc 的 Kubernetes CLI 扩展需要 Azure CLI 2.3 或更高版本。

适用于 Kubernetes 的 Azure Arc 代理

已启用 Azure Arc 的 Kubernetes 由一些在部署到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基于角色的访问控制（RBAC）的身份验证和授权 Webhook 服务器。它是仅在群集上启用 Azure RBAC 时才部署的可选组件。
收集 deployment.apps/extension-events-collector 与扩展生命周期管理相关的日志。它将这些日志聚合到对应于每个作的事件中，例如创建、升级和删除。
收集 deployment.apps/logcollector 平台遥测数据，以帮助确保平台的作运行状况。

有关详细信息，请参阅将现有 Kubernetes 群集连接到 Azure Arc。

使用 Azure Monitor 容器见解监视群集

监视容器至关重要。 Azure Monitor 容器见解为 AKS 和 AKS 引擎群集提供可靠的监视功能。还可以配置 Azure Monitor 容器见解，以监视 Azure 外部托管的已启用 Azure Arc 的 Kubernetes 群集。此配置提供跨 Azure、本地和非Microsoft云环境中的 Kubernetes 群集的全面监视。

Azure Monitor 容器见解通过从控制器、节点和容器收集内存和处理器指标来提供性能可见性。这些指标可通过指标 API 在 Kubernetes 中使用。容器日志也会被收集。从 Kubernetes 群集启用监视后，Log Analytics 代理的容器化版本会自动收集指标和日志。指标将写入指标存储区，日志数据将写入与 Log Analytics 工作区关联的日志存储区。有关详细信息，请参阅用于 Kubernetes 监视的 Azure Monitor 功能。

可以使用 PowerShell 脚本或 Bash 脚本为 Kubernetes 的一个或多个部署启用 Azure Monitor 容器见解。

有关详细信息，请参阅为 Kubernetes 群集启用监视。

使用 Azure Policy 启用基于 GitOps 的应用程序部署

使用 Azure Policy 确保每个已启用 Microsoft.Kubernetes/connectedclusters GitOps 的资源或 Microsoft.ContainerService/managedClusters 资源都应用了特定的 Microsoft.KubernetesConfiguration/fluxConfigurations 资源。例如，可以将基线配置应用于一个或多个群集，或将特定应用程序部署到多个群集。若要使用 Azure Policy，请从已启用 Azure Arc 的 Kubernetes 的 Azure Policy 内置定义中选择定义，然后创建策略分配。创建策略分配时，将范围设置为 Azure 资源组或订阅。此外，设置 fluxConfiguration 所创建的参数。创建分配后，Azure Policy 引擎会标识 connectedCluster 范围中的所有或 managedCluster 资源，然后将该 fluxConfiguration 资源应用于每个资源。

如果为每个群集使用多个源存储库，例如中央 IT 或群集作员的一个存储库以及应用程序团队的其他存储库，请使用多个策略分配激活此功能，并将每个策略分配配置为使用不同的源存储库。

有关详细信息，请参阅使用 Flux v2 配置和 Azure Policy 大规模部署应用程序。

使用 GitOps 部署应用程序

GitOps 是在源存储库中定义 Kubernetes 配置所需的状态（例如部署和命名空间）的做法。此存储库可以是 Git 或 Helm 存储库、存储桶或 Azure Blob 存储。此过程后，使用作员对这些配置的轮询和基于拉取的部署部署到群集。

通过将扩展部署到群集来 microsoft.flux 启用群集与一个或多个源存储库之间的连接。资源 fluxConfiguration 属性表示 Kubernetes 资源应从源存储库流向群集的位置和方式。数据 fluxConfiguration 以静态方式存储在 Azure Cosmos DB 数据库中，以帮助确保数据保密性。

在 flux-config 群集中运行的代理监视已启用 Azure Arc 的 Kubernetes 资源上的新扩展资源或更新 fluxConfiguration 的扩展资源，从源存储库部署应用程序，并传播对源 fluxConfiguration存储库所做的所有更新。可以使用同一已启用 Azure Arc 的 Kubernetes 群集上的作用域来创建多个 fluxConfiguration 资源 namespace ，以实现多租户。

源存储库可包含任何有效的 Kubernetes 资源，包括命名空间、ConfigMap、部署和 Daemonset。它还可以包含用于部署应用程序的 Helm 图表。常见的源存储库方案包括为组织定义基线配置，其中包括常见的 RBAC 角色和绑定、监视代理、日志记录代理和群集范围的服务。

也可以管理更大的群集集合，这些群集可以部署在异构环境中。例如，可以有一个存储库来定义组织的基线配置，然后将该配置同时应用于多个 Kubernetes 群集。你还可以将应用程序从多个源存储库部署到群集。

有关详细信息，请参阅将 GitOps 与 Flux v2 配合使用来部署应用程序。

运行机器学习

在机器学习中，可以选择 AKS（或已启用 Azure Arc 的 Kubernetes）群集作为机器学习进程的计算目标。此功能使你能够在自己的自承载（或多云）基础结构中训练或部署机器学习模型。此方法允许将本地投资与机器学习在云中提供的轻松管理相结合。

使用托管 Prometheus 和 Grafana 监视 Kubernetes 工作负荷

Azure Monitor 为 Prometheus 和 Grafana 部署提供托管服务，以便可以利用这些常用的 Kubernetes 监视工具。通过此托管服务，无需自行管理和更新部署，即可使用这些工具。若要分析 Prometheus 的指标，请结合使用指标资源管理器和 PromQL。

拓扑、网络和路由

Azure Arc 代理需要以下协议、端口和出站 URL 才能正常运行。

终结点 (DNS)	说明
`https://management.azure.com:443`	代理需要该终结点才可连接到 Azure 并注册群集。
`https://[region].dp.kubernetesconfiguration.azure.com:443`	代理的数据平面终结点用于推送状态和提取配置信息，其中 [region] 表示托管 AKS 实例的 Azure 区域。
`https://docker.io:443`	需拉取容器映像。
%>	示例 GitOps 存储库托管在 GitHub 上。配置代理需要连接到指定的 git 终结点。
`https://login.microsoftonline.com:443`、`https://<region>.login.microsoft.com`、`login.windows.net`	提取和更新 Azure 资源管理器令牌所需的终结点。
`https://mcr.microsoft.com:443` `https://*.data.mcr.microsoft.com:443`	拉取 Azure Arc 代理的容器映像所需的终结点。

有关 Azure Arc 服务中的 URL 的完整列表，请参阅 Azure Arc 网络要求。

注意事项

这些注意事项实施 Azure 架构良好的框架的支柱原则，即一套可用于改进工作负荷质量的指导原则。有关详细信息，请参阅 Microsoft Azure 架构良好的框架。

可靠性

可靠性有助于确保应用程序能够履行对客户的承诺。有关详细信息，请参阅可靠性的设计评审清单。

在大多数情况下，创建安装脚本时选择的位置应是离本地资源最近的 Azure 区域。其余数据存储在包含你指定的区域的 Azure 地理位置中。如果具有数据驻留要求，此详细信息可能会影响所选区域。如果中断影响计算机连接到的 Azure 区域，中断不会影响连接的计算机，但使用 Azure 的管理操作可能无法完成。如果有多个位置提供地理冗余服务，请将每个位置中的计算机连接到不同的 Azure 区域。如果发生区域性服务中断，这种做法可以提高复原能力。有关详细信息，请参阅已启用 Azure Arc 的 Kubernetes 支持的区域。
应确保在部署 Azure Arc 的区域支持解决方案中的服务。

安全性

安全性提供针对故意攻击和滥用宝贵数据和系统的保证。有关详细信息，请参阅安全的设计评审清单。

可以使用 Azure RBAC 在 Azure 和本地环境中使用 Microsoft Entra 标识管理对已启用 Azure Arc 的 Kubernetes 的访问权限。有关详细信息，请参阅使用 Azure RBAC 进行 Kubernetes 授权。
Microsoft建议使用具有有限特权的服务主体将 Kubernetes 群集加入 Azure Arc。这种做法适用于持续集成和持续交付管道，例如 Azure Pipelines 和 GitHub Actions。有关详细信息，请参阅创建已启用 Azure Arc 的载入服务主体。
为了简化服务主体管理，可以在 AKS 中使用托管标识。但是，必须使用托管标识创建群集。现有群集（包括 Azure 和本地群集）无法迁移到托管标识。有关详细信息，请参阅在 AKS 中使用托管标识。

成本优化

成本优化侧重于减少不必要的开支和提高运营效率的方法。有关详细信息，请参阅成本优化的设计评审清单。

有关一般成本注意事项，请参阅成本优化设计原则。

卓越运营

卓越运营涵盖部署应用程序并使其在生产环境中运行的运营流程。有关详细信息，请参阅卓越运营的设计评审清单。

在配置已启用 Azure Arc 的 Kubernetes 群集之前，请查看 Azure 资源管理器订阅限制和资源组限制来规划群集数。
使用 Helm（一种开源打包工具）安装和管理 Kubernetes 应用程序生命周期。与 Linux 包管理器（如 APT 和 Yum）类似，使用 Helm 管理 Kubernetes 图表，这些图表是预配置的 Kubernetes 资源的包。

作者

Microsoft维护本文。以下参与者撰写了本文。

首席作者：

Pieter de Bruin | 高级项目经理

若要查看非公开的LinkedIn个人资料，请登录LinkedIn。