通过

你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

常见问题解答 - 已启用 Azure Arc 的 Kubernetes 和 GitOps

  • 项目

本文介绍有关已启用 Azure Arc 的 Kubernetes 和 GitOps 的常见问题解答。

已启用 Azure Arc 的 Kubernetes 和 Azure Kubernetes 服务 (AKS) 之间有何区别？

AKS 是 Azure 提供的托管 Kubernetes 服务。 AKS 通过将大量的复杂性和运营开销卸载到 Azure，简化了在 Azure 中部署托管 Kubernetes 群集的过程。 由于 Kubernetes 主节点由 Azure 管理，因此你只需要管理和维护代理节点。

借助已启用 Azure Arc 的 Kubernetes，可通过将 Kubernetes 群集连接到 Azure 来扩展 Azure 的管理功能（例如 Azure Monitor 和 Azure Policy）。 维护基础 Kubernetes 群集本身。

是否需要将在 Azure 上运行的 AKS 群集连接到 Azure Arc？

大多数方案不需要将 Azure Kubernetes 服务 (AKS) 群集连接到 Azure Arc。 你可能想要连接群集，以在群集上运行某些已启用 Azure Arc 的服务，例如应用服务和数据服务。 可以使用已启用 Azure Arc 的 Kubernetes 的自定义位置功能完成此操作。

我应该将 Azure Local 上的 AKS 或 Azure Stack Edge 连接到 Azure Arc 吗？

通过将 Azure Local 上的 AKS 或 Azure Stack Edge 连接到 Azure Arc，可在 Azure 资源管理器中为群集提供资源表示形式。 此资源表示形式可以将群集配置、Azure Monitor 和 Azure Policy (Gatekeeper) 等功能扩展到连接的 Kubernetes 群集。

对于 Azure Stack Edge、Azure Local 上的 AKS（>= 2021 年 4 月更新）或 Windows Server 2019 Datacenter 上的 AKS（>= 2021 年 4 月更新），免费包含 Kubernetes 配置。

如何处理过期的已启用 Azure Arc 的 Kubernetes 资源？

与已启用 Azure Arc 的 Kubernetes 群集关联的系统分配的托管标识仅由 Azure Arc 代理用于与 Azure Arc 服务通信。 与此系统分配的托管标识关联的证书的有效期为 90 天，代理会在第 46 天到第 90 天之间尝试续订此证书。 为避免托管标识证书过期，请确保群集在第 46 天和第 90 天之间至少联机一次，以便可以续订证书。

如果托管标识证书过期，则该资源被视为 Expired，并且所有 Azure Arc 功能（例如配置、监视和策略）都将停止在群集上运行。

若要检查给定群集的托管标识证书何时到期，请运行以下命令：

az connectedk8s show -n <name> -g <resource-group>

在输出中，managedIdentityCertificateExpirationTime 的值指示托管标识证书将在何时过期（该证书的 90D 标记）。

如果 managedIdentityCertificateExpirationTime 的值指示过去的时间戳，则上述输出中的 connectivityStatus 字段将设置为 Expired。 在这种情况下，若要使 Kubernetes 群集再次使用 Azure Arc，请执行以下操作：

  1. 删除群集上已启用 Azure Arc 的 Kubernetes 资源和代理。

    az connectedk8s delete -n <name> -g <resource-group>

  2. 通过在群集上部署代理重新创建已启用 Azure Arc 的 Kubernetes 资源。

    az connectedk8s connect -n <name> -g <resource-group>

注意

az connectedk8s delete 还会删除群集上的配置和群集扩展。 运行 az connectedk8s connect 后，请手动或使用 Azure Policy 在群集上重新创建配置和群集扩展。

如果我已在使用 CI/CD 管道，是否仍可使用已启用 Azure Arc 的 Kubernetes 或 AKS 和 GitOps 配置？

是的，你仍可以在通过 CI/CD 管道接收部署的群集上使用配置。 与传统 CI/CD 管道相比，GitOps 配置具有一些额外的优势。

偏移协调

在管道运行期间，CI/CD 管道仅应用一次更改。 但是，群集上的 GitOps 运算符会持续轮询 Git 存储库，以获取群集上的 Kubernetes 资源的所需状态。 如果 GitOps 运算符发现资源的所需状态与群集上资源的实际状态不同，则会对此偏移进行协调。

大规模应用 GitOps

CI/CD 管道对于事件驱动的 Kubernetes 群集部署（例如，推送到 Git 存储库）很有用。 但是，若要将相同的配置部署到所有 Kubernetes 群集，则需要手动将每个 Kubernetes 群集的凭据配置到 CI/CD 管道。

对于已启用 Azure Arc 的 Kubernetes，由于 Azure 资源管理器会管理你的 GitOps 配置，因此可以在订阅或资源组范围内，使用 Azure Policy 在所有已启用 Azure Arc 的 Kubernetes 和 AKS 资源中自动创建相同的配置。 此功能甚至适用于在策略分配后创建的已启用 Azure Arc 的 Kubernetes 和 AKS 资源。

此功能在整个 Kubernetes 群集清单中应用基准配置（例如网络策略、角色绑定和 Pod 安全策略），以满足合规性和治理要求。

群集合规性

每个 GitOps 配置的合规性状态都会报告回 Azure。 这使你可以跟踪任何失败的部署。

已启用 Azure Arc 的 Kubernetes 是否会将任何客户数据存储在群集区域之外？

将客户数据存储到一个区域的功能目前仅适用于亚太地区的东南亚区域（新加坡）和巴西地区的巴西南部区域（圣保罗州）。 对于其他所有区域，客户数据存储在以下地域。 这适用于已启用 Azure Arc 的开放式服务网格，以及已启用 Azure Arc 的 Kubernetes 中支持的 Azure Key Vault 机密提供程序扩展。 有关其他群集扩展，请参阅其文档，了解其如何存储客户数据。 有关详细信息，请参阅信任中心。

后续步骤