你当前正在访问 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 中管理群集。 还可以通过脱机管理工具访问群集。

图表显示了已启用 Azure Arc 的 Kubernetes 代理的体系结构概述。

将 Kubernetes 群集连接到 Azure Arc 涉及以下高级步骤:

  1. 在你选择的基础结构(VMware vSphere、Amazon Web Services、Google Cloud Platform 或任何云原生计算基金会 (CNCF) 认证的 Kubernetes 发行版)上创建 Kubernetes 群集。 在将群集连接到 Azure Arc 之前,群集必须已存在。

  2. 开始为群集注册 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 时才部署。
  3. 在所有已启用 Azure Arc 的 Kubernetes 代理 Pod 均处于 Running 状态后,验证群集是否已连接到 Azure Arc。你应会看到:

    • Azure 资源管理器中已启用 Azure Arc 的 Kubernetes connectedClusters 资源。 Azure 将此资源作为客户管理的 Kubernetes 群集的投影进行跟踪,而不是跟踪实际的 Kubernetes 群集本身。
    • 群集元数据(例如 Kubernetes 版本、代理版本和节点数)以元数据的形式显示在已启用 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/SourceControlConfigurationsMicrosoft.KubernetesConfiguration/ExtensionsMicrosoft.KubernetesConfiguration/FluxConfigurations)。

  1. 执行 LIST 获取源群集(待移动群集)中的所有配置资源并保存响应主体:

    注意

    对配置资源运行 LIST/GET 不会返回 ConfigurationProtectedSettings。 对于这种情况,只能保存原始请求正文,并在新区域中创建资源时重用它们。

  2. 从底层 Kubernetes 群集中删除旧的 Arc 部署。

  3. 通过网络访问底层 Kubernetes 群集,连接新区域中的该群集

  4. 验证 Arc 连接群集是否在新区域中成功运行:

    1. 运行 az connectedk8s show -n <connected-cluster-name> -g <resource-group> 并确保 connectivityStatus 值为 Connected
    2. 运行 kubectl get deployments,pods -n azure-arc验证所有代理是否都已成功部署
  5. 使用保存的响应主体,在目标群集上重新创建通过 LIST 命令从源群集获取的每个配置资源。 若要确认,请将目标群集中所有配置资源的 LIST 结果与源群集的原始 LIST 响应进行比较。

后续步骤