常見問題集 - 已啟用 Azure Arc 的 Kubernetes 和 GitOps

  • 發行項

本文說明已啟用 Azure Arc 的 Kubernetes 和 GitOps 的常見問題。

已啟用 Azure Arc 的 Kubernetes 與 Azure Kubernetes Service (AKS) 有何差異？

AKS 是 Azure 提供的受控 Kubernetes 供應項目。 AKS 會藉由將大部分的複雜性和作業額外負荷卸載至 Azure，以簡化在 Azure 中部署受控 Kubernetes 叢集的作業。 由於 Kubernetes 主要節點是由 Azure 管理，因此您只需管理及維護代理程式節點。

已啟用 Azure Arc 的 Kubernetes 可藉由將 Kubernetes 叢集連線至 Azure，讓您擴充 Azure 的管理功能 (例如 Azure 監視器和 Azure 原則)。 您要維護基礎 Kubernetes 叢集本身。

我是否需要將在 Azure 上執行的 AKS 叢集連線至 Azure Arc？

目前，大多數場景不需要將 Azure Kubernetes 服務 (AKS) 叢集連線到 Azure Arc。 您可能想要連接叢集以在該叢集上執行某些已啟用 Azure Arc 的服務 (例如 App Services 和 Data Services)。 這可以使用已啟用 Azure Arc 的 Kubernetes 的自訂位置功能來完成。

我是否應該將 Azure Stack Edge 上的 AKS-HCI 叢集和 Kubernetes 叢集連線到 Azure Arc？

將 Azure Stack Edge 上的 AKS-HCI 叢集或 Kubernetes 叢集連線至 Azure Arc，可在 Azure Resource Manager 中向叢集提供資源表示法。 此資源表示法可將叢集設定、Azure 監視器和 Azure 原則 (閘道管理員) 等功能擴充至已連線的 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 原則，在叢集上重新建立設定和叢集擴充功能。

如果我已經使用 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 Resource Manager 會管理您的 GitOps 設定，因此在訂用帳戶或資源群組的範圍內，您可以使用 Azure 原則，跨所有已啟用 Azure Arc 的 Kubernetes 和 AKS 資源自動建立相同的設定。 這項功能甚至適用於在指派原則後所建立的已啟用 Azure Arc 的 Kubernetes 和 AKS 資源。

這項功能會在整個 Kubernetes 叢集詳細目錄套用基準設定 (例如，網路原則、角色繫結和 Pod 安全性原則)，以符合合規性和治理需求。

叢集合規性

每個 GitOps 設定的合規性狀態都會回報到 Azure。 這可讓您追蹤任何失敗的部署。

已啟用 Azure Arc 的 Kubernetes 是否會將任何客戶資料儲存在叢集所在區域外？

將客戶資料儲存在單一區域中的功能，目前僅適用於亞太地區的東南亞區域 (新加坡)，以及巴西地區的巴西南部 (聖保羅州) 區域。 至於其他所有區域，客戶資料會儲存在地區中。 這適用於已啟用 Azure Arc 的 Open Service Mesh 以及已啟用 Azure Arc 的 Kubernetes 中支援的 Azure Key Vault 秘密提供者擴充功能。 若為其他叢集擴充功能，請參閱其文件以了解其如何儲存客戶資料。 如需詳細資訊，請參閱信任中心。

下一步