Compartir a través de

已启用 Azure Arc 的 Kubernetes 代理概述

Azure Arc启用的 Kubernetes提供了一个集中、一致的控制平面，用于管理不同环境中的 Kubernetes 群集的策略、治理和安全性。

在将 Kubernetes 群集连接到 Azure Arc 时，您需要在群集上部署 Azure Arc 代理。本文概述了这些 Azure Arc 代理，并提供了将它们部署到群集的高层步骤，以及在 Azure 区域之间移动已连接资源的步骤。

将代理部署到集群

大多数本地数据中心强制实施严格的网络规则，防止在网络边界防火墙上进行入站通信。 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 或任何由云原生计算基金会（CNCF）认证的 Kubernetes 发行版）上创建 Kubernetes 集群。 在将群集连接到Azure Arc之前，群集必须已存在。

  2. 启动群集Azure Arc注册。 此过程在群集上部署代理 Helm 图表。 之后，群集节点会发起到 Microsoft Artifact Registry 的出站通信，在 azure-arc 命名空间中拉取创建以下代理所需的映像：

    代理人 说明
    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 图表的生命周期。
    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 资源上。

有关将代理部署到群集的详细信息，请参阅 Quickstart：将现有 Kubernetes 群集连接到 Azure Arc。

跨Azure区域移动已启用 Arc 的 Kubernetes 群集

在某些情况下，可能需要将已启用 Arc 的 Kubernetes 群集移到另一个Azure区域。 例如，你可能想要部署仅在特定区域中可用的功能或服务，或者可能需要根据内部治理要求或容量规划注意事项更改区域。

将连接的群集移动到新区域时，删除源区域中的 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 响应进行比较。

后续步骤

  • Last updated on