你当前正在访问 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 群集管理和配置。

体系结构

体系结构图显示 Azure Arc for Kubernetes 拓扑。

下载此体系结构的 Visio 文件

工作流

该体系结构包括以下几个方面:

  • 已启用 Azure Arc 的 Kubernetes。 通过已启用 Azure Arc 的 Kubernetes,在 Azure 内部或外部附加和配置 Kubernetes 群集。 将 Kubernetes 群集附加到 Azure Arc 后,将获得 Azure 资源管理器 ID 和托管标识。
  • Azure Kubernetes 服务。 在 Azure 中托管 Kubernetes 群集,减少 Kubernetes 群集管理的复杂性和操作开销。
  • 本地 Kubernetes 群集。 附加托管在本地或第三方云环境中的云原生计算基金会 (CNCF) 认证的 Kubernetes 群集。
  • Azure Policy。 为已启用 Arc 的 Kubernetes 群集部署和管理策略。
  • Azure Monitor。 观察并监视已启用 Arc 的 Kubernetes 群集。

组件数

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

方案详细信息

可以使用 Azure Arc 注册托管在 Microsoft Azure 外部的 Kubernetes 群集。 然后,可以使用 Azure 工具来管理这些群集以及托管在 Azure Kubernetes 服务 (AKS) 中的群集。

可能的用例

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

  • 管理本地 Kubernetes 群集以及 AKS 中托管用于库存、分组和标记的群集。
  • 使用 Azure Monitor 跨混合环境监视 Kubernetes 群集。
  • 使用 Azure Policy 跨混合环境为 Kubernetes 群集部署和实施策略。
  • 使用 Azure Policy 部署和实施 GitOps。

建议

以下部分提供了适用于大多数场景的建议。 Microsoft 建议遵循它们,除非有替代它们的要求。

群集注册

可以注册任何活动的 CNCF Kubernetes 群集。 需要用 kubeconfig 文件来访问群集和群集上的 cluster-admin 角色,以便部署已启用 Arc 的 Kubernetes 代理。 使用 Azure 命令行界面 (Azure CLI) 执行群集注册任务。 用于 az login 和 az connectedk8s connect 命令的用户或服务主体需要 Microsoft.Kubernetes/connectedClusters 资源类型的读取和写入权限。 Kubernetes 群集 - Azure Arc 载入角色拥有这些权限,可用于用户主体或服务主体的角色分配。 需要 Helm 3 才能加入使用 connectedk8s 扩展的群集。 安装已启用 Azure Arc 的 Kubernetes 命令行接口扩展需要使用 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。 收集其他 Arc 代理的指标,以确保这些代理表现出最佳性能。
  • deployment.apps/cluster-metadata-operator. 收集群集元数据、群集版本、节点计数和 Azure Arc 代理版本。
  • deployment.apps/resource-sync-agent。 将前述群集元数据同步到 Azure。
  • deployment.apps/clusteridentityoperator。 维护其他代理用于与 Azure 进行通信的托管服务标识 (MSI) 证书。
  • deployment.apps/flux-logs-agent。 从在源代码管理配置过程中部署的 flux 运算符收集日志。
  • deployment.apps/extension-manager。 安装和管理扩展 Helm 图表的生命周期。
  • deployment.apps/kube-azure-ad-proxy。 用于对使用群集连接发送到群集的请求进行身份验证。
  • deployment.apps/clusterconnect-agent。 启用群集连接功能以提供对群集的 apiserver 的访问的反向代理。 它是一个可选组件,只有在群集上启用了群集连接功能时才会部署。
  • deployment.apps/guard。 用于 Microsoft Entra 基于角色的访问控制 (RBAC) 的身份验证和授权 Webhook 服务器。 它是一个可选组件,只有在群集上启用了 azure-rbac 功能时才会部署。

有关详细信息,请参阅连接已启用 Azure Arc 的 Kubernetes 群集

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

监视容器非常重要。 Azure Monitor 容器见解为 AKS 和 AKS 引擎群集提供了丰富的监视体验。 也可配置 Azure Monitor 容器见解,监视在 Azure 之外托管的已启用 Azure Arc 的 Kubernetes 群集。 这样做有助于跨 Azure、本地和第三方云环境实现对 Kubernetes 群集的全面监视。

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

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

如需监视启用 Arc 的 Kubernetes 群集,请参阅对启用了 Azure Arc 的 Kubernetes 群集启用监视

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

使用 Azure Policy 强制每个已启用 GitOps 的 Microsoft.Kubernetes/connectedclusters 资源或 Microsoft.ContainerService/managedClusters 资源都应用了特定的 Microsoft.KubernetesConfiguration/fluxConfigurations。 例如,可以将基线配置应用于一个或多个群集,或将特定应用程序部署到多个群集。 如需使用 Azure Policy,请从已启用 Azure Arc 的 Kubernetes 的 Azure Policy 内置定义中选择定义,然后创建策略分配。

创建策略分配时,将范围设置为 Azure 资源组或订阅。 此外,为创建的 fluxConfiguration 设置参数。 创建分配时,策略引擎将识别范围之内的全部 connectedClustermanagedCluster 资源,然后将 fluxConfiguration 应用到各资源。

如果将多个源存储库用于每个群集(例如,一个存储库用于中心 IT/群集操作员,而其他存储库用于应用程序团队),则可以通过使用多个策略分配来启用此功能,并将每个策略分配配置为使用不同的源存储库。

有关详细信息,请参阅使用 Flux v2 配置和 Azure Policy 以一致的方式大规模部署应用程序

使用 GitOps 部署应用程序

GitOps 可用于在源存储库(如 Git 或 Helm 存储库、存储桶或 Azure Blob 存储)中声明 Kubernetes 配置(部署、命名空间等)的所需状态。 然后,通过使用运算符对这些配置进行基于轮询和拉取的部署。

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

在群集中运行的 flux-config 代理负责对已启用 Azure Arc 的 Kubernetes 资源上新增或更新的 fluxConfiguration 扩展资源进行监视,以便从源存储库部署应用程序并传播对 fluxConfiguration 所做的任何更新。 甚至可以在同一个已启用 Azure Arc 的 Kubernetes 群集上使用命名空间范围来创建多个 fluxConfiguration 资源,以实现多租户。

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

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

有关详细信息,请参阅使用 GitOps with Flux v2 部署应用程序

拓扑、网络和路由

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

终结点 (DNS) 说明
https://management.azure.com:443 代理需要该终结点才可连接到 Azure 并注册群集。
https://[region].dp.kubernetesconfiguration.azure.com:443 代理的数据平面终结点用于推送状态和提取配置信息,其中 [region] 表示托管 AKS 实例的 Azure 区域。
https://docker.io:443 需拉取容器映像。
https://github.com:443, git://github.com:9418 示例 GitOps 存储库托管在 GitHub 上。 配置代理需要连接到指定的任何 git 终结点。
https://login.microsoftonline.com:443 提取和更新 Azure 资源管理器令牌所需的终结点。
https://azurearcfork8s.azurecr.io: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。这种做法在 CI/CD 管道(例如 Azure Pipelines 和 GitHub Actions)中很有用。 有关详细信息,请参阅创建已启用 Azure Arc 的加入服务主体
  • 为了简化服务主体管理,可以在 AKS 中使用托管标识。 但是,必须使用托管标识创建群集,现有群集(包括 Azure 和本地群集)无法迁移到托管标识。 有关详细信息,请参阅在 Azure Kubernetes 服务中使用托管标识

成本优化

成本优化是关于寻找减少不必要的费用和提高运营效率的方法。 有关详细信息,请参阅成本优化支柱概述

在 Microsoft Azure 架构良好的框架中,成本优化原则部分介绍了一般成本注意事项。

卓越运营

卓越运营涵盖了部署应用程序并使其在生产环境中保持运行的运营流程。 有关详细信息,请参阅卓越运营支柱概述

  • 在为计算机配置已启用 Azure Arc 的 Kubernetes 群集之前,应查看 Azure 资源管理器订阅限制资源组限制,规划要连接的计算机数。
  • 使用 Helm(开放源代码打包工具)安装和管理 Kubernetes 应用程序生命周期。 与诸如 APT 和 Yum 的 Linux 包管理器类似,使用 Helm 管理 Kubernetes 图表,这些图表是预配置的 Kubernetes 资源包。

作者

本文由 Microsoft 维护, 它最初是由以下贡献者撰写的。

首席作者:

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

后续步骤

相关混合指南:

相关体系结构: