常见问题解答 - 已启用 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 机密提供程序扩展。 有关详细信息,请参阅信任中心

后续步骤