你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站,请访问 https://docs.azure.cn。
已启用 Azure Arc 的 Kubernetes 代理概述
已启用 Azure Arc 的 Kubernetes 提供集中式一致控制平面,可跨不同环境中的 Kubernetes 群集管理策略、治理和安全性。
将 Kubernetes 群集连接到 Azure Arc 时,Azure Arc 代理会部署到 Kubernetes 群集上。本文概述了这些代理。
将代理部署到群集
大多数本地数据中心强制实施严格的网络规则,防止在网络边界防火墙上进行入站通信。 已启用 Azure Arc 的 Kubernetes 不需要使用防火墙上的入站端口,因此可以在这些限制下正常运行。 Azure Arc 代理需要与网络终结点的固定列表进行出站通信。
此图提供了 Azure Arc 组件的高级视图。 本地数据中心或不同云中的 Kubernetes 群集通过 Azure Arc 代理连接到 Azure。 此连接允许使用管理工具和 Azure 服务在 Azure 中管理群集。 还可以通过脱机管理工具访问群集。
将 Kubernetes 群集连接到 Azure Arc 涉及以下高级步骤:
在你选择的基础结构(VMware vSphere、Amazon Web Services、Google Cloud Platform 或任何云原生计算基金会 (CNCF) 认证的 Kubernetes 发行版)上创建 Kubernetes 群集。 在将群集连接到 Azure Arc 之前,群集必须已存在。
开始为群集注册 Azure Arc。 此过程在群集上部署代理 Helm 图表。 此后,群集节点向 Microsoft 容器注册表发起出站通信,并拉取所需的映像用于在
azure-arc
命名空间中创建以下代理:Agent 说明 deployment.apps/clusteridentityoperator
已启用 Azure Arc 的 Kubernetes 目前仅支持系统分配的标识。 clusteridentityoperator
发起首次出站通信。 此首次通信将提取由其他代理用来与 Azure 通信的托管服务标识 (MSI) 证书。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/flux-logs-agent
从在源代码管理配置过程中部署的 Flux operator 收集日志。 deployment.apps/extension-manager
安装扩展 Helm chart 并管理其生命周期。 deployment.apps/kube-aad-proxy
用于通过群集连接对发送到群集的请求进行身份验证。 deployment.apps/clusterconnect-agent
使群集连接功能可提供对群集的 apiserver
的访问权限的反向代理程序。 可选组件,仅在启用了群集连接功能时才部署。deployment.apps/guard
用于 Microsoft Entra RBAC 的身份验证和授权 Webhook 服务器。 可选组件,仅在群集上启用了 Azure RBAC 时才部署。 在所有已启用 Azure Arc 的 Kubernetes 代理 Pod 均处于
Running
状态后,验证群集是否已连接到 Azure Arc。你应会看到:- Azure 资源管理器中已启用 Azure Arc 的 Kubernetes
connectedClusters
资源。 Azure 将此资源作为客户管理的 Kubernetes 群集的投影进行跟踪,而不是跟踪实际的 Kubernetes 群集本身。 - 群集元数据(例如 Kubernetes 版本、代理版本和节点数)以元数据的形式显示在已启用 Azure Arc 的 Kubernetes 资源上。
- Azure 资源管理器中已启用 Azure Arc 的 Kubernetes
有关将代理部署到群集的详细信息,请参阅快速入门:将现有 Kubernetes 群集连接到 Azure Arc。
跨 Azure 区域移动已启用 Arc 的 Kubernetes 群集
在某些情况下,你可能希望将已启用 Arc 的 Kubernetes 群集移动到另一区域。 例如,你可能希望部署仅在特定区域可用的功能或服务,或者出于内部治理要求或容量规划考虑,而需要更改区域。
将连接的群集移动到新区域时,需删除源区域中的 connectedClusters
Azure 资源管理器资源,然后部署代理以在目标区域中重新创建 connectedClusters
资源。 对于群集中的源代码管理配置、Flux 配置和扩展,需要保存有关资源的详细信息,然后在新的群集资源中重新创建子资源。
在开始之前,请确保目标区域支持已启用 Azure Arc 的 Kubernetes 资源 (Microsoft.Kubernetes/connectedClusters
) 和任何需要的已启用 Azure Arc 的 Kubernetes 配置资源(Microsoft.KubernetesConfiguration/SourceControlConfigurations
、Microsoft.KubernetesConfiguration/Extensions
、Microsoft.KubernetesConfiguration/FluxConfigurations
)。
执行 LIST 获取源群集(待移动群集)中的所有配置资源并保存响应主体:
- Microsoft.KubernetesConfiguration/SourceControlConfigurations
- Microsoft.KubernetesConfiguration/Extensions
- Microsoft.KubernetesConfiguration/FluxConfigurations
注意
对配置资源运行 LIST/GET 不会返回
ConfigurationProtectedSettings
。 对于这种情况,只能保存原始请求正文,并在新区域中创建资源时重用它们。从底层 Kubernetes 群集中删除旧的 Arc 部署。
通过网络访问底层 Kubernetes 群集,连接新区域中的该群集。
验证 Arc 连接群集是否在新区域中成功运行:
- 运行
az connectedk8s show -n <connected-cluster-name> -g <resource-group>
并确保connectivityStatus
值为Connected
。 - 运行
kubectl get deployments,pods -n azure-arc
以验证所有代理是否都已成功部署。
- 运行
使用保存的响应主体,在目标群集上重新创建通过 LIST 命令从源群集获取的每个配置资源。 若要确认,请将目标群集中所有配置资源的 LIST 结果与源群集的原始 LIST 响应进行比较。
后续步骤
- 参考快速入门将 Kubernetes 群集连接到 Azure Arc。
- 查看发行说明以查看有关最新代理版本的详细信息。
- 了解升级已启用 Azure Arc 的 Kubernetes 代理。
- 详细了解如何在群集与 Git 存储库之间创建连接,作为已启用 Azure Arc 的 Kubernetes 中的配置资源。