Share via

常见问题解答 - 已启用 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 Stack Edge 上的 AKS-HCI 群集和 Kubernetes 群集连接到 Azure Arc？

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

如果已启用 Azure Arc 的 Kubernetes 群集位于 Azure Stack Edge、Azure Stack HCI 上的 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 的所有区域，客户数据都存储在异地。 这适用于已启用 Azure Arc 的 Kubernetes 支持的 Azure Key Vault 机密提供程序扩展。 有关详细信息，请参阅信任中心。

后续步骤