適用於 Azure Kubernetes Service 的 GitOps

Azure Kubernetes Service (AKS)

GitHub

GitOps 是一組用來操作和管理軟體系統的原則。 本文說明使用 GitOps 原則操作和管理 Azure Kubernetes Services （AKS） 叢集的技術。

Flux、Argo CD、OPA Gatekeeper、Kubernetes 和 Git 標誌是其各自公司的商標。 使用這些標記時不會隱含任何背書。

架構

您可以搭配 AKS 使用的兩個 GitOps 運算子是 Flux 和 Argo CD。 它們都 已畢業的雲端原生運算基礎 （NCF） 專案 ，而且廣泛使用。 下列案例顯示使用方式。

案例 1：具有 Flux 和 AKS 的 GitOps

說明 Flux v2、GitHub 和 AKS 的 GitOps 工作流程的圖表。 在左側，開發人員將組態變更提交至 GitHub 存放庫。 在中心，AKS 叢集中的 Flux 運算子會監視存放庫的變更。 當 Flux 偵測到設定漂移時，它會從 GitHub 提取最新的設定。 在右側，Flux 會協調存放庫中所需的狀態與 AKS 叢集中的實際狀態，並視需要套用更新。 此圖顯示從開發人員到 GitHub、Flux 和最後到 AKS 叢集的組態變更流程，並強調以提取為基礎的持續對帳程式。

下載此架構的 Visio 檔案。

案例 1 的資料流程

Flux 是與 AKS 原生整合的 叢集延伸模組 。 叢集延伸模組提供平臺，可在 AKS 叢集上安裝和管理解決方案。 您可以使用 Azure 入口網站、Azure CLI 或基礎結構即程式代碼 （IaC） 腳本，例如 Terraform 或 Bicep 腳本，啟用 Flux 作為 AKS 的延伸模組。 您也可以使用 Azure 原則，在 AKS 叢集上大規模套用 Flux v2 組態。 如需詳細資訊，請參閱 使用 Flux v2 組態和 Azure 原則大規模部署應用程式。

Flux 可以將 Kubernetes 指令清單、Helm 圖表和 Kustomization 檔案部署到 AKS。 Flux 是以輪詢為基礎的程式，因此它可以偵測、提取和協調設定變更，而不需向組建代理程序公開叢集端點。

在此案例中，Kubernetes 系統管理員可以變更 Kubernetes 設定物件，例如秘密和 ConfigMaps，並將變更直接認可至 GitHub 存放庫。

下列資料流程對應至上一個圖表：

1. 開發人員會將設定變更認可至 GitHub 存放庫。

2. Flux 會偵測 Git 存放庫中的組態漂移，並提取組態變更。

3. Flux 會協調 Kubernetes 叢集中的狀態。

案例 1 的替代方案

• 您可以搭配其他 Git 存放庫使用 Flux，例如 Azure DevOps、GitLab 和 Bitbucket。

• Flux Bucket API 不使用 Git 儲存庫，而是定義一個生成構件的來源，專門針對像 Amazon S3 和 Google Cloud Storage 之類的儲存解決方案中的物件。 您也可以使用具有 S3 相容 API 的解決方案。 兩個範例是 MinIO 和阿里雲物件儲存服務 （OSS），但還有其他解決方案。

• 您也可以將 Flux 設定為產生成品的來源 Azure Blob 儲存體 容器。 如需詳細資訊，請參閱 具有 AKS 和已啟用 Azure Arc 的 Kubernetes 的 GitOps Flux v2 設定。

• Flux v2 允許單獨的團隊將工作負載部署到單個共享 Kubernetes 集群中，從而支持多租戶。 多個代表不同租用戶的 Git 儲存庫可以同步到叢集。 為了確保小組之間的工作負載隔離，每個小組在 AKS 叢集內可能都有自己的命名空間或命名空間，這些命名空間會透過 Kubernetes 角色型存取控制 （RBAC） 原則來限制存取。

• Flux 可以使用一個叢集來管理相同叢集或其他叢集中的應用程式。 具有 Flux 運算子的中樞 AKS 叢集負責管理將應用程式和基礎結構工作負載透過 GitOps 持續傳遞到多個衛星 AKS 叢集。

案例 2：搭配 Flux、GitHub 和 AKS 使用 GitOps 來實作 CI/CD

顯示 GitOps、Flux、GitHub 和 AKS 的 CI/CD 工作流程的圖表。 在左側，開發人員在整合開發環境 （IDE） 中編寫應用程式程式碼並將其提交到 GitHub 儲存庫。 GitHub Actions 會從程式碼建置容器映像，並將它推送至 Azure Container Registry。 GitHub Actions 會使用新的映像版本更新存放庫中的 Kubernetes 資訊清單檔案。 在中心，AKS 叢集中的 Flux 運算子會監視存放庫的變更。 當 Flux 偵測到更新的資訊清單時，它會提取設定，並將新的應用程式版本部署至 AKS 叢集。 此圖顯示從開發人員到 GitHub、透過 CI/CD 自動化到 Flux，最後到 AKS 叢集的程式碼和設定流程，並強調自動化的提取型部署程式。

下載此架構的 Visio 檔案。

案例 2 的資料流程

此案例是一般 Web 應用程式的提取式 DevOps 管線。 管線會使用 GitHub Actions 進行建置。 針對部署，它會使用 Flux 作為 GitOps 操作員來提取和同步處理應用程式。

下列資料流程對應至上一個圖表：

1. 應用程式程式碼是使用整合開發環境 （IDE） 來開發，例如 Visual Studio Code。

2. 應用程式程式代碼會認可至 GitHub 存放庫。

3. GitHub Actions 會從應用程式程式代碼建置容器映射，並將容器映像推送至 Azure Container Registry。

4. GitHub Actions 會使用來自 Container Registry 中容器影像版本號的當前影像版本，來更新 Kubernetes 資訊清單部署檔案。

5. Flux 運算子會偵測 Git 存放庫中的設定漂移，並提取組態變更。

6. Flux 會使用指令清單檔案將應用程式部署至 AKS 叢集。

案例 3：使用 Argo CD、GitHub 儲存庫和 AKS 的 GitOps

顯示 Argo CD、GitHub 和 AKS 的 GitOps 工作流程的圖表。 在左側，Kubernetes 管理員編輯組態檔並將其提交到 GitHub 儲存庫。 在中心，AKS 叢集中的 Argo CD 會監視存放庫的變更。 當 Argo CD 偵測到更新的設定時，它會提取變更，並將所需的狀態與 AKS 叢集中的實際狀態協調。 此圖表醒目提示從系統管理員到 GitHub、然後到 Argo CD，最後到 AKS 叢集的設定流程，並強調以提取為基礎的持續協調程式，以及 Argo CD 作為管理應用程式狀態的控制器的角色。

下載此架構的 Visio 檔案。

案例 3 的資料流程

您可以在 AKS 中啟用 Argo CD 作為叢集延伸模組。 在此案例中，Kubernetes 系統管理員可以變更 Kubernetes 設定物件，例如秘密和 ConfigMaps，並將變更直接認可至 GitHub 存放庫。

下列資料流程對應至上一個圖表：

1. Kubernetes 系統管理員會在 YAML 檔案中進行設定變更，並將變更認可至 GitHub 存放庫。

2. Argo CD 會從 Git 存放庫提取變更。

3. Argo CD 會協調 AKS 叢集的組態變更。

Argo CD 不需要自動將所需的目標狀態同步至 AKS 叢集。 它會實作為持續監視執行中應用程式的 Kubernetes 控制器。 它會將 AKS 叢集目前的即時狀態與 Git 存放庫中指定的所需目標狀態進行比較。 Argo CD 報告並可視化差異，並提供自動或手動將實時狀態同步回所需目標狀態的工具。

Argo CD 提供瀏覽器型使用者介面。 您可以使用它來新增應用程式組態、觀察叢集的同步處理狀態，以及針對叢集起始同步處理。 您也可以使用 Argo CD 命令列來執行這些工作。 使用者介面和命令行介面都提供功能來檢視組態變更的歷程記錄，以及復原至舊版。

根據預設，Argo CD 使用者介面和 API 伺服器不會公開。 若要存取它們，建議您 建立具有內部IP位址的輸入控制器。 或者，您可以使用 內部負載平衡器 來公開它們。

案例 3 的替代方案

任何與 Git 相容的存放庫，包括 Azure DevOps，都可以作為組態來源存放庫。

案例 4：搭配 Argo CD、GitHub Actions 和 AKS 使用 GitOps 來實作 CI/CD

使用 GitOps 搭配 Argo CD、GitHub 和 AKS 的 CI/CD 工作流程圖表。 在左側，開發人員編寫應用程式程式碼並將其提交到 GitHub 儲存庫。 GitHub Actions 會建置容器映像，將它推送至 Container Registry，並使用新的映像版本更新存放庫中的 Kubernetes 資訊清單檔案。 在中心，AKS 叢集中的 Argo CD 會監視存放庫的變更、提取更新的設定，並將新的應用程式版本部署至 AKS 叢集。 此圖展示程式碼和設定流程的流動，從開發人員到 GitHub，再透過 CI/CD 自動化到 Argo CD，最終到 AKS 叢集，重點突出自動化的拉取式部署過程。

下載此架構的 Visio 檔案。

案例 4 的資料流程

此案例是一般 Web 應用程式的提取式 DevOps 管線。 管線會使用 GitHub Actions 進行建置。 針對部署，它會使用Argo CD作為 GitOps 操作員來提取和同步處理應用程式。

下列資料流程對應至上一個圖表：

1. 應用程式程式代碼是使用 Visual Studio Code 之類的 IDE 所開發。

2. 應用程式程式代碼會認可至 GitHub 存放庫。

3. GitHub Actions 會從應用程式程式碼建置容器映像，並將容器映像推送至 Container Registry。

4. GitHub Actions 會使用來自 Container Registry 中容器影像版本號的當前影像版本，來更新 Kubernetes 資訊清單部署檔案。

5. Argo CD 會從 Git 存放庫提取。

6. Argo CD 會將應用程式部署至 AKS 叢集。

案例 4 的替代方案

任何與 Git 相容的存放庫，包括 Azure DevOps，都可以作為組態來源存放庫。

案例詳細資料

GitOps 是一組用來操作和管理軟體系統的原則。

• 它會使用原始檔控制作為系統的單一事實來源。

• 它將版本控制、協作、合規性以及持續整合和持續部署 （CI/CD） 等開發實踐應用於基礎設施自動化。

• 您可以將它套用至任何軟體系統。

GitOps 通常用於 Kubernetes 叢集管理和應用程式傳遞。

根據 GitOps 原則，GitOps 管理系統的理想狀態必須符合下列條件：

• 宣告式： GitOps 管理的系統必須以宣告方式表示其所需的狀態。 宣告通常會儲存在 Git 存放庫中。

• 版本化且不可變： 所需的狀態會以強制執行不變性和版本設定的方式儲存，並保留完整的版本歷程記錄。

• 自動拉動： 軟體代理程式會自動從來源提取所需的狀態宣告。

• 持續協調： 軟體代理程式會持續觀察實際的系統狀態，並嘗試套用目標狀態。

在 GitOps 中， IaC 使用程式碼來宣告基礎結構元件（例如虛擬機器 （VM）、網路和防火牆）的所需狀態。 此程式代碼是受版本控制且可稽核的程序代碼。

Kubernetes 使用資訊清單以宣告方式描述從叢集狀態到應用程式部署的所有內容。 適用於 Kubernetes 的 GitOps 會將叢集基礎結構所需的狀態置於版本控制之下。 叢集中的元件 （通常稱為 運算子） 會持續同步宣告式狀態。 這種方法可讓您檢閱和稽核影響叢集的程式代碼變更。 它透過支援最小權限原則 （PoLP） 來增強安全性。

GitOps 代理程式會持續將系統狀態與儲存在程式代碼存放庫中所需的狀態協調。 某些 GitOps 代理程式可以還原在叢集外部執行的作業，例如手動建立 Kubernetes 物件。 例如， 准入控制器會在 建立、更新及刪除作業期間對物件強制執行原則。 您可以使用它們來確保只有在來源存放庫中的部署程式代碼變更時，部署才會變更。

您可以將原則管理和強制執行工具與 GitOps 結合，以強制執行原則，並提供建議原則變更的意見反應。 您可以為個別小組設定通知，讓他們隨時瞭解目前的 GitOps 狀態。 例如，您可以傳送部署成功和對帳失敗的通知。

GitOps 作為單一事實來源

GitOps 提供叢集狀態的一致性和標準化，並有助於增強安全性。 您也可以使用 GitOps 來確保跨多個叢集的一致狀態。 例如，GitOps 可以在主要和災害復原 （DR） 叢集或叢集伺服器陣列之間套用相同的設定。

若要強制執行 GitOps 作為變更叢集狀態的唯一方法，請限制對叢集的直接存取。 若要設定此設定，請使用 Azure 角色型存取控制 （Azure RBAC）、許可控制器或其他工具。

使用 GitOps 啟動初始設定

有時需要 AKS 叢集部署作為基準設定的一部分。 例如，您可能需要在部署應用程式工作負載之前部署共用服務或系統層級組態。 這些共用服務可以設定下列附加元件和工具：

• AKS 附加元件，例如 Microsoft Entra 工作負載識別碼 及 Azure Key Vault Provider for Secrets Store CSI Driver

• 合作夥伴工具，例如 Prisma Cloud Defender

• 開放原始碼工具，例如 Kubernetes 事件驅動自動調整 （KEDA）、ExternalDNS 和 Cert-manager

您可以啟用 Flux 作為在建立 AKS 叢集時所套用的延伸模組。 Flux 接著可以將基準組態啟動至叢集。 AKS 叢集的基準架構建議您使用 GitOps 進行引導。 如果您使用 Flux 延伸模組，則可以在部署之後立即啟動叢集。

其他 GitOps 工具和附加元件

您可以將所述的案例延伸至其他 GitOps 工具。 Jenkins X 是另一個 GitOps 工具，提供整合至 Azure 的指示。 您可以使用 Flagger 之類的漸進式傳遞工具，逐步轉移透過 GitOps 部署的生產工作負載。

潛在使用案例

此解決方案有利於想要部署應用程式和 IaC 並維護所有變更稽核追蹤的組織。

GitOps 簡化了開發人員的容器管理，從而提高了生產力。 開發人員可以繼續使用熟悉的工具，例如 Git 來管理更新和新功能。

考量

這些考量能實作 Azure Well-Architected Framework 的支柱，這是一組指導原則，可以用來改善工作負載的品質。 如需詳細資訊，請參閱 Well-Architected Framework。

可靠性

可靠性有助於確保您的應用程式可以符合您對客戶的承諾。 如需詳細資訊，請參閱可靠性的設計檢閱檢查清單。

如果叢集無法使用，則應該使用 GitOps 作為建立新叢集的一部分。 它會使用 Git 存放庫作為 Kubernetes 組態和應用程式邏輯的單一事實來源。 它可以建立叢集設定和應用程式部署並將其套用為縮放單位，並可以建立 部署戳記 模式。

安全性

安全性可提供針對蓄意攻擊和濫用寶貴數據和系統的保證。 如需詳細資訊，請參閱安全性的設計檢閱檢查清單。

使用 GitOps 方法，個別開發人員或系統管理員不會直接存取 Kubernetes 叢集以套用變更或更新。 相反地，使用者會將變更推送至 Git 存放庫，而 GitOps 運算子 （例如 Flux 或 Argo CD） 會讀取變更，並將其套用至叢集。 此方法遵循最低許可權的安全性最佳做法，不授與 DevOps 小組對 Kubernetes API 的寫入許可權。 在診斷或疑難解答案例中，您可以依案例來授與叢集許可權一段時間。

除了設定存放庫許可權之外，請考慮在與 AKS 叢集同步處理的 Git 存放庫中實作下列安全性措施：

• 分支保護： 保護代表 Kubernetes 叢集狀態的分支，使其無法直接推送變更。 使用提取要求 （PR） 進行變更，並讓至少一個其他人檢閱每個 PR。 也使用 PR 進行自動檢查。

• 公關點評： 要求 PR 至少有一名審查者來執行四眼原則。 您也可以使用 GitHub 程式代碼擁有者功能來定義負責檢閱存放庫中特定檔案的個人或小組。

• 不可變的歷程記錄： 只允許在現有變更之上的新認可。 不可變的歷程記錄對於稽核目的特別重要。

• 進一步的安全性措施： 要求您的 GitHub 使用者啟用雙因素驗證。 只允許已簽署的提交以防止變更。

成本優化

成本優化著重於減少不必要的費用，並提升營運效率的方式。 如需詳細資訊，請參閱成本最佳化的設計檢閱檢查清單。

• AKS 免費層提供免費的叢集管理。 成本僅限於 AKS 用來裝載節點的計算、記憶體和網路資源。 AKS 免費層不包含服務等級協定 （SLA），也不建議用於生產工作負載。

• GitHub 提供免費服務，但若要使用進階安全性相關功能，例如程式碼擁有者或必要的檢閱者，您需要團隊方案。 如需詳細資訊，請參閱 GitHub 定價。

• Azure DevOps 提供免費方案，您可以用於某些場景。

• 使用 Azure 定價計算機來預估成本。

卓越營運

卓越營運涵蓋部署應用程式並使其持續在生產環境中執行的作業流程。 如需詳細資訊，請參閱卓越營運的設計檢閱檢查清單。

GitOps 可以提升DevOps生產力。 最有用的功能之一是能夠透過執行 Git 操作快速回滾那些行為不如預期的變更。 提交圖表仍包含所有提交，因此可以幫助進行回顧分析。

GitOps 小組通常會管理相同應用程式的多個環境。 通常會有數個階段的應用程式部署到不同的 Kubernetes 叢集或命名空間。 Git 存放庫是單一事實來源，會顯示目前部署至叢集的應用程式版本。

部署案例

如需部署這五個案例的詳細資訊，請參閱下列資源：

• 場景 1： 如需如何使用 GitOps 搭配 Flux v2 將應用程式部署至 AKS 的指引，請參閱 教學課程：搭配 Flux v2 使用 GitOps 部署應用程式。 如需如何使用 Flux 擴充功能啟動 AKS 叢集部署的範例，請參閱 AKS 基準的參考實作。

• 場景 2：如需如何在 AKS 上搭配 Flux v2 使用 GitOps 來部署應用程式和實作 CI/CD 的指引，請參閱教學課程：使用 GitOps 實作 CI/CD （Flux v2）。

• 場景 3 和 4： 如需如何使用 Argo CD 和 AKS 部署範例工作負載的逐步指引，請參閱 AKS 基準自動化中的提取型 CI/CD 案例。

參與者

本文由 Microsoft 維護。 下列參與者撰寫本文。

主要作者：

• 弗朗西斯·西米·納扎雷斯 |主要雲端解決方案架構師

若要查看非公開的 LinkedIn 個人檔案，請登入 LinkedIn。

下一步

• 使用 GitOps 搭配 Flux v2 部署應用程式
• 使用 GitOps 搭配 Argo CD 部署應用程式
• 使用 GitOps 實作 CI/CD （Flux v2）
• Argo CD 檔
• Flux CD 檔
• 使用 Jenkins X 的 GitOps
• 什麼是 Azure RBAC？

相關資源

• AKS 叢集的基準架構
• 多區域叢集的 AKS 基準
• AKS 上的 DevSecOps
• 適用於 IaC 的 DevSecOps

GitOps 是一組用來操作和管理軟體系統的原則。 本文說明使用 GitOps 原則操作和管理 Azure Kubernetes Services （AKS） 叢集的技術。

Flux、Argo CD、OPA Gatekeeper、Kubernetes 和 Git 標誌是其各自公司的商標。 使用這些標記時不會隱含任何背書。

架構

您可以搭配 AKS 使用的兩個 GitOps 運算子是 Flux 和 Argo CD。 它們都 已畢業的雲端原生運算基礎 （NCF） 專案 ，而且廣泛使用。 下列案例顯示使用方式。

案例 1：具有 Flux 和 AKS 的 GitOps

說明 Flux v2、GitHub 和 AKS 的 GitOps 工作流程的圖表。 在左側，開發人員將組態變更提交至 GitHub 存放庫。 在中心，AKS 叢集中的 Flux 運算子會監視存放庫的變更。 當 Flux 偵測到設定漂移時，它會從 GitHub 提取最新的設定。 在右側，Flux 會協調存放庫中所需的狀態與 AKS 叢集中的實際狀態，並視需要套用更新。 此圖顯示從開發人員到 GitHub、Flux 和最後到 AKS 叢集的組態變更流程，並強調以提取為基礎的持續對帳程式。

下載此架構的 Visio 檔案。

案例 1 的資料流程

Flux 是與 AKS 原生整合的 叢集延伸模組 。 叢集延伸模組提供平臺，可在 AKS 叢集上安裝和管理解決方案。 您可以使用 Azure 入口網站、Azure CLI 或基礎結構即程式代碼 （IaC） 腳本，例如 Terraform 或 Bicep 腳本，啟用 Flux 作為 AKS 的延伸模組。 您也可以使用 Azure 原則，在 AKS 叢集上大規模套用 Flux v2 組態。 如需詳細資訊，請參閱 使用 Flux v2 組態和 Azure 原則大規模部署應用程式。

Flux 可以將 Kubernetes 指令清單、Helm 圖表和 Kustomization 檔案部署到 AKS。 Flux 是以輪詢為基礎的程式，因此它可以偵測、提取和協調設定變更，而不需向組建代理程序公開叢集端點。

在此案例中，Kubernetes 系統管理員可以變更 Kubernetes 設定物件，例如秘密和 ConfigMaps，並將變更直接認可至 GitHub 存放庫。

下列資料流程對應至上一個圖表：

1. 開發人員會將設定變更認可至 GitHub 存放庫。

2. Flux 會偵測 Git 存放庫中的組態漂移，並提取組態變更。

3. Flux 會協調 Kubernetes 叢集中的狀態。

案例 1 的替代方案

• 您可以搭配其他 Git 存放庫使用 Flux，例如 Azure DevOps、GitLab 和 Bitbucket。

• Flux Bucket API 不使用 Git 儲存庫，而是定義一個生成構件的來源，專門針對像 Amazon S3 和 Google Cloud Storage 之類的儲存解決方案中的物件。 您也可以使用具有 S3 相容 API 的解決方案。 兩個範例是 MinIO 和阿里雲物件儲存服務 （OSS），但還有其他解決方案。

• 您也可以將 Flux 設定為產生成品的來源 Azure Blob 儲存體 容器。 如需詳細資訊，請參閱 具有 AKS 和已啟用 Azure Arc 的 Kubernetes 的 GitOps Flux v2 設定。

• Flux v2 允許單獨的團隊將工作負載部署到單個共享 Kubernetes 集群中，從而支持多租戶。 多個代表不同租用戶的 Git 儲存庫可以同步到叢集。 為了確保小組之間的工作負載隔離，每個小組在 AKS 叢集內可能都有自己的命名空間或命名空間，這些命名空間會透過 Kubernetes 角色型存取控制 （RBAC） 原則來限制存取。

• Flux 可以使用一個叢集來管理相同叢集或其他叢集中的應用程式。 具有 Flux 運算子的中樞 AKS 叢集負責管理將應用程式和基礎結構工作負載透過 GitOps 持續傳遞到多個衛星 AKS 叢集。

案例 2：搭配 Flux、GitHub 和 AKS 使用 GitOps 來實作 CI/CD

顯示 GitOps、Flux、GitHub 和 AKS 的 CI/CD 工作流程的圖表。 在左側，開發人員在整合開發環境 （IDE） 中編寫應用程式程式碼並將其提交到 GitHub 儲存庫。 GitHub Actions 會從程式碼建置容器映像，並將它推送至 Azure Container Registry。 GitHub Actions 會使用新的映像版本更新存放庫中的 Kubernetes 資訊清單檔案。 在中心，AKS 叢集中的 Flux 運算子會監視存放庫的變更。 當 Flux 偵測到更新的資訊清單時，它會提取設定，並將新的應用程式版本部署至 AKS 叢集。 此圖顯示從開發人員到 GitHub、透過 CI/CD 自動化到 Flux，最後到 AKS 叢集的程式碼和設定流程，並強調自動化的提取型部署程式。

下載此架構的 Visio 檔案。

案例 2 的資料流程

此案例是一般 Web 應用程式的提取式 DevOps 管線。 管線會使用 GitHub Actions 進行建置。 針對部署，它會使用 Flux 作為 GitOps 操作員來提取和同步處理應用程式。

下列資料流程對應至上一個圖表：

1. 應用程式程式碼是使用整合開發環境 （IDE） 來開發，例如 Visual Studio Code。

2. 應用程式程式代碼會認可至 GitHub 存放庫。

3. GitHub Actions 會從應用程式程式代碼建置容器映射，並將容器映像推送至 Azure Container Registry。

4. GitHub Actions 會使用來自 Container Registry 中容器影像版本號的當前影像版本，來更新 Kubernetes 資訊清單部署檔案。

5. Flux 運算子會偵測 Git 存放庫中的設定漂移，並提取組態變更。

6. Flux 會使用指令清單檔案將應用程式部署至 AKS 叢集。

案例 3：使用 Argo CD、GitHub 儲存庫和 AKS 的 GitOps

顯示 Argo CD、GitHub 和 AKS 的 GitOps 工作流程的圖表。 在左側，Kubernetes 管理員編輯組態檔並將其提交到 GitHub 儲存庫。 在中心，AKS 叢集中的 Argo CD 會監視存放庫的變更。 當 Argo CD 偵測到更新的設定時，它會提取變更，並將所需的狀態與 AKS 叢集中的實際狀態協調。 此圖表醒目提示從系統管理員到 GitHub、然後到 Argo CD，最後到 AKS 叢集的設定流程，並強調以提取為基礎的持續協調程式，以及 Argo CD 作為管理應用程式狀態的控制器的角色。

下載此架構的 Visio 檔案。

案例 3 的資料流程

您可以在 AKS 中啟用 Argo CD 作為叢集延伸模組。 在此案例中，Kubernetes 系統管理員可以變更 Kubernetes 設定物件，例如秘密和 ConfigMaps，並將變更直接認可至 GitHub 存放庫。

下列資料流程對應至上一個圖表：

1. Kubernetes 系統管理員會在 YAML 檔案中進行設定變更，並將變更認可至 GitHub 存放庫。

2. Argo CD 會從 Git 存放庫提取變更。

3. Argo CD 會協調 AKS 叢集的組態變更。

Argo CD 不需要自動將所需的目標狀態同步至 AKS 叢集。 它會實作為持續監視執行中應用程式的 Kubernetes 控制器。 它會將 AKS 叢集目前的即時狀態與 Git 存放庫中指定的所需目標狀態進行比較。 Argo CD 報告並可視化差異，並提供自動或手動將實時狀態同步回所需目標狀態的工具。

Argo CD 提供瀏覽器型使用者介面。 您可以使用它來新增應用程式組態、觀察叢集的同步處理狀態，以及針對叢集起始同步處理。 您也可以使用 Argo CD 命令列來執行這些工作。 使用者介面和命令行介面都提供功能來檢視組態變更的歷程記錄，以及復原至舊版。

根據預設，Argo CD 使用者介面和 API 伺服器不會公開。 若要存取它們，建議您 建立具有內部IP位址的輸入控制器。 或者，您可以使用 內部負載平衡器 來公開它們。

案例 3 的替代方案

任何與 Git 相容的存放庫，包括 Azure DevOps，都可以作為組態來源存放庫。

案例 4：搭配 Argo CD、GitHub Actions 和 AKS 使用 GitOps 來實作 CI/CD

使用 GitOps 搭配 Argo CD、GitHub 和 AKS 的 CI/CD 工作流程圖表。 在左側，開發人員編寫應用程式程式碼並將其提交到 GitHub 儲存庫。 GitHub Actions 會建置容器映像，將它推送至 Container Registry，並使用新的映像版本更新存放庫中的 Kubernetes 資訊清單檔案。 在中心，AKS 叢集中的 Argo CD 會監視存放庫的變更、提取更新的設定，並將新的應用程式版本部署至 AKS 叢集。 此圖展示程式碼和設定流程的流動，從開發人員到 GitHub，再透過 CI/CD 自動化到 Argo CD，最終到 AKS 叢集，重點突出自動化的拉取式部署過程。

下載此架構的 Visio 檔案。

案例 4 的資料流程

此案例是一般 Web 應用程式的提取式 DevOps 管線。 管線會使用 GitHub Actions 進行建置。 針對部署，它會使用Argo CD作為 GitOps 操作員來提取和同步處理應用程式。

下列資料流程對應至上一個圖表：

1. 應用程式程式代碼是使用 Visual Studio Code 之類的 IDE 所開發。

2. 應用程式程式代碼會認可至 GitHub 存放庫。

3. GitHub Actions 會從應用程式程式碼建置容器映像，並將容器映像推送至 Container Registry。

4. GitHub Actions 會使用來自 Container Registry 中容器影像版本號的當前影像版本，來更新 Kubernetes 資訊清單部署檔案。

5. Argo CD 會從 Git 存放庫提取。

6. Argo CD 會將應用程式部署至 AKS 叢集。

案例 4 的替代方案

任何與 Git 相容的存放庫，包括 Azure DevOps，都可以作為組態來源存放庫。

案例詳細資料

GitOps 是一組用來操作和管理軟體系統的原則。

• 它會使用原始檔控制作為系統的單一事實來源。

• 它將版本控制、協作、合規性以及持續整合和持續部署 （CI/CD） 等開發實踐應用於基礎設施自動化。

• 您可以將它套用至任何軟體系統。

GitOps 通常用於 Kubernetes 叢集管理和應用程式傳遞。

根據 GitOps 原則，GitOps 管理系統的理想狀態必須符合下列條件：

• 宣告式： GitOps 管理的系統必須以宣告方式表示其所需的狀態。 宣告通常會儲存在 Git 存放庫中。

• 版本化且不可變： 所需的狀態會以強制執行不變性和版本設定的方式儲存，並保留完整的版本歷程記錄。

• 自動拉動： 軟體代理程式會自動從來源提取所需的狀態宣告。

• 持續協調： 軟體代理程式會持續觀察實際的系統狀態，並嘗試套用目標狀態。

在 GitOps 中， IaC 使用程式碼來宣告基礎結構元件（例如虛擬機器 （VM）、網路和防火牆）的所需狀態。 此程式代碼是受版本控制且可稽核的程序代碼。

Kubernetes 使用資訊清單以宣告方式描述從叢集狀態到應用程式部署的所有內容。 適用於 Kubernetes 的 GitOps 會將叢集基礎結構所需的狀態置於版本控制之下。 叢集中的元件 （通常稱為 運算子） 會持續同步宣告式狀態。 這種方法可讓您檢閱和稽核影響叢集的程式代碼變更。 它透過支援最小權限原則 （PoLP） 來增強安全性。

GitOps 代理程式會持續將系統狀態與儲存在程式代碼存放庫中所需的狀態協調。 某些 GitOps 代理程式可以還原在叢集外部執行的作業，例如手動建立 Kubernetes 物件。 例如， 准入控制器會在 建立、更新及刪除作業期間對物件強制執行原則。 您可以使用它們來確保只有在來源存放庫中的部署程式代碼變更時，部署才會變更。

您可以將原則管理和強制執行工具與 GitOps 結合，以強制執行原則，並提供建議原則變更的意見反應。 您可以為個別小組設定通知，讓他們隨時瞭解目前的 GitOps 狀態。 例如，您可以傳送部署成功和對帳失敗的通知。

GitOps 作為單一事實來源

GitOps 提供叢集狀態的一致性和標準化，並有助於增強安全性。 您也可以使用 GitOps 來確保跨多個叢集的一致狀態。 例如，GitOps 可以在主要和災害復原 （DR） 叢集或叢集伺服器陣列之間套用相同的設定。

若要強制執行 GitOps 作為變更叢集狀態的唯一方法，請限制對叢集的直接存取。 若要設定此設定，請使用 Azure 角色型存取控制 （Azure RBAC）、許可控制器或其他工具。

使用 GitOps 啟動初始設定

有時需要 AKS 叢集部署作為基準設定的一部分。 例如，您可能需要在部署應用程式工作負載之前部署共用服務或系統層級組態。 這些共用服務可以設定下列附加元件和工具：

• AKS 附加元件，例如 Microsoft Entra 工作負載識別碼 及 Azure Key Vault Provider for Secrets Store CSI Driver

• 合作夥伴工具，例如 Prisma Cloud Defender

• 開放原始碼工具，例如 Kubernetes 事件驅動自動調整 （KEDA）、ExternalDNS 和 Cert-manager

您可以啟用 Flux 作為在建立 AKS 叢集時所套用的延伸模組。 Flux 接著可以將基準組態啟動至叢集。 AKS 叢集的基準架構建議您使用 GitOps 進行引導。 如果您使用 Flux 延伸模組，則可以在部署之後立即啟動叢集。

其他 GitOps 工具和附加元件

您可以將所述的案例延伸至其他 GitOps 工具。 Jenkins X 是另一個 GitOps 工具，提供整合至 Azure 的指示。 您可以使用 Flagger 之類的漸進式傳遞工具，逐步轉移透過 GitOps 部署的生產工作負載。

潛在使用案例

此解決方案有利於想要部署應用程式和 IaC 並維護所有變更稽核追蹤的組織。

GitOps 簡化了開發人員的容器管理，從而提高了生產力。 開發人員可以繼續使用熟悉的工具，例如 Git 來管理更新和新功能。

考量

這些考量能實作 Azure Well-Architected Framework 的支柱，這是一組指導原則，可以用來改善工作負載的品質。 如需詳細資訊，請參閱 Well-Architected Framework。

可靠性

可靠性有助於確保您的應用程式可以符合您對客戶的承諾。 如需詳細資訊，請參閱可靠性的設計檢閱檢查清單。

如果叢集無法使用，則應該使用 GitOps 作為建立新叢集的一部分。 它會使用 Git 存放庫作為 Kubernetes 組態和應用程式邏輯的單一事實來源。 它可以建立叢集設定和應用程式部署並將其套用為縮放單位，並可以建立 部署戳記 模式。

安全性

安全性可提供針對蓄意攻擊和濫用寶貴數據和系統的保證。 如需詳細資訊，請參閱安全性的設計檢閱檢查清單。

使用 GitOps 方法，個別開發人員或系統管理員不會直接存取 Kubernetes 叢集以套用變更或更新。 相反地，使用者會將變更推送至 Git 存放庫，而 GitOps 運算子 （例如 Flux 或 Argo CD） 會讀取變更，並將其套用至叢集。 此方法遵循最低許可權的安全性最佳做法，不授與 DevOps 小組對 Kubernetes API 的寫入許可權。 在診斷或疑難解答案例中，您可以依案例來授與叢集許可權一段時間。

除了設定存放庫許可權之外，請考慮在與 AKS 叢集同步處理的 Git 存放庫中實作下列安全性措施：

• 分支保護： 保護代表 Kubernetes 叢集狀態的分支，使其無法直接推送變更。 使用提取要求 （PR） 進行變更，並讓至少一個其他人檢閱每個 PR。 也使用 PR 進行自動檢查。

• 公關點評： 要求 PR 至少有一名審查者來執行四眼原則。 您也可以使用 GitHub 程式代碼擁有者功能來定義負責檢閱存放庫中特定檔案的個人或小組。

• 不可變的歷程記錄： 只允許在現有變更之上的新認可。 不可變的歷程記錄對於稽核目的特別重要。

• 進一步的安全性措施： 要求您的 GitHub 使用者啟用雙因素驗證。 只允許已簽署的提交以防止變更。

成本優化

成本優化著重於減少不必要的費用，並提升營運效率的方式。 如需詳細資訊，請參閱成本最佳化的設計檢閱檢查清單。

• AKS 免費層提供免費的叢集管理。 成本僅限於 AKS 用來裝載節點的計算、記憶體和網路資源。 AKS 免費層不包含服務等級協定 （SLA），也不建議用於生產工作負載。

• GitHub 提供免費服務，但若要使用進階安全性相關功能，例如程式碼擁有者或必要的檢閱者，您需要團隊方案。 如需詳細資訊，請參閱 GitHub 定價。

• Azure DevOps 提供免費方案，您可以用於某些場景。

• 使用 Azure 定價計算機來預估成本。

卓越營運

卓越營運涵蓋部署應用程式並使其持續在生產環境中執行的作業流程。 如需詳細資訊，請參閱卓越營運的設計檢閱檢查清單。

GitOps 可以提升DevOps生產力。 最有用的功能之一是能夠透過執行 Git 操作快速回滾那些行為不如預期的變更。 提交圖表仍包含所有提交，因此可以幫助進行回顧分析。

GitOps 小組通常會管理相同應用程式的多個環境。 通常會有數個階段的應用程式部署到不同的 Kubernetes 叢集或命名空間。 Git 存放庫是單一事實來源，會顯示目前部署至叢集的應用程式版本。

部署案例

如需部署這五個案例的詳細資訊，請參閱下列資源：

• 場景 1： 如需如何使用 GitOps 搭配 Flux v2 將應用程式部署至 AKS 的指引，請參閱 教學課程：搭配 Flux v2 使用 GitOps 部署應用程式。 如需如何使用 Flux 擴充功能啟動 AKS 叢集部署的範例，請參閱 AKS 基準的參考實作。

• 場景 2：如需如何在 AKS 上搭配 Flux v2 使用 GitOps 來部署應用程式和實作 CI/CD 的指引，請參閱教學課程：使用 GitOps 實作 CI/CD （Flux v2）。

• 場景 3 和 4： 如需如何使用 Argo CD 和 AKS 部署範例工作負載的逐步指引，請參閱 AKS 基準自動化中的提取型 CI/CD 案例。

參與者

本文由 Microsoft 維護。 下列參與者撰寫本文。

主要作者：

• 弗朗西斯·西米·納扎雷斯 |主要雲端解決方案架構師

若要查看非公開的 LinkedIn 個人檔案，請登入 LinkedIn。

下一步

• 使用 GitOps 搭配 Flux v2 部署應用程式
• 使用 GitOps 搭配 Argo CD 部署應用程式
• 使用 GitOps 實作 CI/CD （Flux v2）
• Argo CD 檔
• Flux CD 檔
• 使用 Jenkins X 的 GitOps
• 什麼是 Azure RBAC？

相關資源

• AKS 叢集的基準架構
• 多區域叢集的 AKS 基準
• AKS 上的 DevSecOps
• 適用於 IaC 的 DevSecOps