通过

已启用 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/SourceControlConfigurations、Microsoft.KubernetesConfiguration/Extensions、Microsoft.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 响应进行比较。

后续步骤