已啟用 Azure Arc 的 Kubernetes CI/CD 和 GitOps 專業領域

Kubernetes 是雲端原生建構，需要雲端原生方法來進行部署和作業。 使用 GitOps 時，您會在儲存在 Git 存放庫中的檔案中宣告應用程式型部署所需的狀態。 應用程式具有需要執行的 Kubernetes 物件，其中包括部署、Horizontal-Pod-Autoscalers、Services 和 Config 地圖。 Kubernetes 運算子會在叢集中執行，並持續協調每個叢集的狀態與 Git 存放庫中所宣告的所需狀態。 這些操作員會從 Git 存放庫提取檔案，並將所需的狀態套用至您的叢集。 運算子也會持續確保叢集維持在預期狀態。

實作 GitOps 可讓您：

• 改善 Kubernetes 叢集狀態和設定的整體可見度。
• 透過 Git 變更歷程記錄，對叢集進行變更的簡單稽核和版本歷程記錄，其中顯示變更的人員、進行這些變更的時機，以及原因。
• 自動更正叢集可能發生的漂移。
• 透過 Git 還原或 Git 回復命令，將 Kubernetes 設定復原至舊版。 災害復原案例的叢集部署重新建立也變得快速、直接的程式，因為 Kubernetes 所需的叢集設定會儲存在 Git 中。
• 藉由減少具有叢集部署許可權所需的服務帳戶數目，以改善安全性。
• 實作 CI/CD 管線，以將應用程式部署至您的叢集。

已啟用 Azure Arc 的 Kubernetes 上的 GitOps 會使用實 作 Flux 的延伸模組，這是熱門的開放原始碼工具集。 Flux 是一個操作員，可將叢集中的 GitOps 組態部署自動化。 Flux 可為常見檔案來源 (Git 存放庫、Helm 封存庫、貯體) 和範本類型 (YAML、Helm 和 Kustomize) 提供支援。 Flux 也支援多租使用者和部署相依性管理以及其他功能。

架構

下圖說明概念參考架構，其中強調叢集中的 Flux 叢集延伸模塊安裝布建、已啟用 Azure Arc 的 Kubernetes 叢集和 GitOps Flow 的 GitOps 組態程式。

Flux v2 叢集延伸模組布建程式：

GitOps 組態程式：

顯示應用程式更新的 GitOps Flow：

設計考量

規劃實作已啟用 Azure Arc 的 Kubernetes GitOps 時，請檢閱下列設計考慮。

組態

請考慮 Kubernetes 叢集中的不同組態層級，以及佈建這些層級時所涉及的責任。

設定層

• 將應用程式及其相關 Kubernetes 物件部署至叢集所需的應用程式設定，例如部署、服務、HPA 和 ConfigMap 資源。 應用程式設定通常會套用至命名空間層級的 GitOps 設定，因此只需要在單一命名空間內設定應用程式元件。
• 建立 Kubernetes 物件的全叢集設定，例如 Namespaces、ServiceAccounts、Roles 和 RoleBindings，以及其他全叢集原則。
• 全叢集元件，例如輸入控制器、監視和安全性堆疊，以及跨叢集運作的各種代理程式。

職責

• 應用程式開發人員負責推送其原始程式碼、觸發組建，以及建立容器映像。
• 應用程式操作員負責維護應用程式存放庫、組態、環境變數、應用程式特定的 helm 圖表、Kustomizations 等。
  • 使用 Azure CLI 套用 Flux 設定
  • Flux2 helm 和 kustomize 範例
• 叢集操作員負責設定叢集基準。 他們通常與設定全叢集元件和原則有關。 他們會維護包含命名空間、服務帳戶、RoleBinding、CRD、全叢集原則、輸入元件等常見基礎結構工具的 Git 存放庫目錄或目錄。

存放庫結構

選擇 Git 存放庫結構時，請考量取捨。 您選擇的結構會定義 Kubernetes 叢集狀態，其中包含應用程式和整個叢集的元件。 根據您識別的責任和角色而定，請務必考慮不同存放庫結構選項所需的任何必要共同作業或所需的小組獨立性。

您可以針對程式代碼存放庫使用任何您想要的分支策略，因為它只會由持續整合 （CI） 程式使用。

針對您的 GitOps 設定存放庫，請根據貴組織的商務需求、大小和工具，考慮下列策略：

• 單一存放庫 (每個環境的分支)：
  • 讓您可以最靈活地控制代表環境的每個分支的 Git 策略和權限。
  • 缺點是環境之間沒有共用通用設定，因為 Kustomize 之類的工具不適用於 Git 分支。
• 單一存放庫 (每個環境的目錄)：
  • 您可以使用 Kustomize 之類的工具來實作此方法，其可讓您為 Kubernetes 物件定義基底組態，以及一組會覆寫基底中組態的環境成品（亦即修補程式）。
  • 這種方法可以減少每個環境的重複 YAML 檔案，但也可減少環境之間的設定區隔。 對存放庫進行單一變更可能會同時影響所有環境，因此必須完全瞭解並小心瞭解基底目錄變更的效果。
• 多個存放庫 (每個存放庫都提供特定用途)：
  • 這可用來分隔每個應用程式、小組、層或租使用者的組態存放庫。
  • 這可讓小組擁有更獨立的控制權，但會遠離在單一存放庫中定義系統狀態的原則，以改善對叢集部署的集中設定、可見度和控制。
  • 針對多租使用者需求，應考慮設定多個存放庫。 提供角色型存取控制 (RBAC) 和內建的安全性，可限制指派給特定存放庫的小組/租使用者可以套用的設定，例如只允許部署到特定命名空間。

如需更多建構存放庫的方式，請參閱 Flux 指南。

應用程式和平台設定

平臺操作員和應用程式操作員有數個選項來管理 Kubernetes 組態：

• 代表您所部署之每個 Kubernetes API 物件的 YAML 規格的原始 Kubernetes YAML 檔案，都適用於單一環境。 使用原始 YAML 檔案的缺點是，當您開始納入多個環境時，自定義會變得困難，因為您需要複製 YAML 檔案，而且沒有很好的重複使用方法。
• Helm 是 Kubernetes 物件的套件管理工具。 這是叢集操作員可用來安裝第三方現成應用程式的有效選項。 請確定您不會將範本化作為內部應用程式的組態管理工具使用，因為隨著範本成長，管理可能會變得很複雜。
  • 如果使用 Helm，Flux 會包含 Helm 控制器，可讓您使用 Kubernetes 指令清單以宣告方式管理 Helm Chart 版本。 您可以建立 HelmRelease 物件來管理該程式。
• Kustomize 是 Kubernetes 原生組態管理工具，引進了自定義應用程式組態的無範本方式。
  • 如果使用 Kustomize，Flux 會包含 Kustomize 控制器，專門針對以 Kubernetes 指令清單定義的基礎結構和工作負載執行持續傳遞管線，並使用 Kustomize 組合。 您可以建立 Kustomization 物件來管理該程式。
• 使用已啟用 Azure Arc 的 Kubernetes，您不需要自行管理元件的生命週期和支援，您可以使用 Microsoft 管理及支援的可用延伸模組 清單。 這些擴充功能是透過 Azure Resource Manager 管理。 其中一些延伸模組，例如 Azure 金鑰保存庫 秘密提供者，具有 開放原始碼 替代方案。 在延伸程式外部管理元件可讓您更充分掌控元件，但也需要更多的支援和生命週期管理額外負荷。

持續整合和持續傳遞 （CI/CD） 流程

下列各節提供應用程式管線和元件更新程序的考慮。

應用程式管線

• 請考慮您需要包含在 CI 程式中的應用程式建置、測試和驗證。 這些可以包含安全性、整合和效能相關的 Linting 和測試，您需要此專案才能為環境部署建立候選版 （RC）。
• 您可以使用傳統的推送部署方法，直接從部署管線呼叫 Kubernetes API，以橋接 CI 管線中的組建容器映像與其叢集中的部署之間的差距。

若要避免對 GitOps 存放庫進行手動設定修改，您可以執行 CD 管線作為服務帳戶，此帳戶具有開啟提取要求的許可權，或直接將新的容器映像變更認可至組態存放庫。 這些變更也可以布建應用程式所需的所有 YAML 物件。

下列程式圖說明與支援 GitOps 之變更併入的傳統應用程式 CI 程式。

全叢集元件更新程式

• 叢集操作員需要管理整個叢集的元件，因此這很可能是來自用來部署應用程式和服務的CD管線。 請考慮定義叢集操作員特定的升級程式，以確保變更能夠順暢地從某個環境轉換到另一個環境。
• 如果您需要將相同的 GitOps 組態大規模套用至已啟用 Azure Arc 的 Kubernetes 叢集，請考慮套用 Azure 原則，以自動安裝 Flux 擴充功能，並將 GitOps 設定套用至現有的已啟用 Azure Arc 的 Kubernetes 叢集，或套用至已上線至 Azure Arc 的新叢集。

更新組態時，您可能會想要確認變更已成功套用至您想要的環境。 您可以在 Flux 中定義通知，以與您的 CI/CD 工具、電子郵件或 ChatOps 工具整合，並自動傳送有關成功變更和部署失敗的警示。 您也可以透過 k8s 組態 CLI 和 ARM API，在 Azure 入口網站 中找到部署狀態資訊。

安全性考量

規劃實作已啟用 Azure Arc 的 Kubernetes 的 GitOps 時，請檢閱下列安全性考慮。

存放庫驗證

• 您可以使用公用或私人 Git 存放庫搭配 GitOps，但由於 Kubernetes 組態的敏感性本質，我們建議您使用需要 SSH 金鑰或 API 金鑰驗證的私人存放庫。 只要 Kubernetes 叢集可以存取 Git 存放庫，GitOps 也會使用只能在專用網記憶體取的 Git 存放庫，但此設定會限制您使用雲端式 Git 提供者的能力，例如 Azure Repos 或 GitHub。
• HTTPS 和 SSH 通訊協定都提供可靠且安全的連線，可用來連線到原始檔控制工具。 不過，HTTPS 通常更容易設定，並使用很少要求您在防火牆中開啟更多埠的埠。

存放庫和分支安全性

• 在設定存放庫上設定分支許可權和原則。 當您的 Git 存放庫成為 Kubernetes 部署的核心部分時，請務必設定許可權來控制誰可以在分支中讀取和更新程式代碼，並實作原則來強制執行小組的程式代碼質量和變更管理。 否則，您的 GitOps 工作流程可以寄送不符合您組織標準的程式代碼。
• 提取要求 （PR） 管線可以與您的分支原則搭配使用，視需要驗證 YAML 組態和/或部署測試環境。 蓋茨有助於消除設定錯誤，並增加部署安全性和信賴度。
• 指派訪問許可權時，請考慮組織中的哪些用戶應該具有存放庫讀取許可權、PR 建立存取權，以及PR核准存取權。

秘密管理

• 請避免在 Git 存放庫中儲存純文字或 base64 編碼的秘密。 相反地，請考慮使用外部秘密提供者，例如 Azure 金鑰保存庫。 Azure 金鑰保存庫 Secrets Store CSI 驅動程式提供者可讓您使用 CSI 磁碟區，將 Azure 密鑰保存庫整合為秘密存放區與 Azure Kubernetes Service （AKS） 叢集。 此服務可透過已啟用 Azure Arc 的 Kubernetes 擴充功能取得。 HashiCorp Vault 是第三方受控秘密提供者替代方案。
• 管理秘密的另一個替代方式是使用 Bitnami 的 Sealed Secrets，該秘密是從公開和私鑰的概念運作。 這可讓操作員使用 Git 中的公鑰來儲存單向加密的秘密，此密鑰只能透過私鑰進行解密，而該私鑰是由在叢集中執行的 SealedSecrets 控制器所使用。

設計建議

規劃實作已啟用 Azure Arc 的 Kubernetes 的 GitOps 時，請檢閱下列設計建議。

下圖包含參考架構，說明使用已啟用 Azure Arc 的 Kubernetes Flux 擴充功能實作 GitOps 程式所需的責任、存放庫和管線。

儲存機制

設計中包含三個 Git 存放庫：

• 應用程式程式代碼存放庫
  • 此存放庫會儲存應用程式程式代碼和任何管線定義和組態腳本。
  • 使用容易瞭解並限制不想要長時間執行的分支數目的開發分支策略。
• 應用程式組態存放庫
  • 此存放庫會儲存應用程式組態，包括 Kubernetes 物件，例如 Config 地圖、部署、服務和 HPA 物件。 使用每個應用程式的不同目錄來建構此存放庫。 Flux 會將此存放庫和目標分支的變更同步至您的叢集。
  • 併入工具，讓應用程式開發人員和操作員更容易為每個環境建置初始組態。 應用程式操作員應該定義 Kubernetes 特定的應用程式元件，以使用 Helm 之類的套件管理員或 Kustomize 等組態工具，讓設定更簡單。
  • 建立分支來代表每個環境類型。 這可讓您更精細地控制每個特定環境的變更，例如非生產環境與生產環境。
  • 當應用程式部署至特定命名空間時，請使用 GitOps 組態內的命名空間範圍功能，只對特定命名空間強制執行組態。
• 全叢集組態存放庫
  • 定義全叢集元件，例如輸入控制器、命名空間、RBAC、監視和安全性堆疊，以進行叢集操作員管理。 Flux 會將此存放庫和目標分支的變更同步處理到您的叢集。
  • 使用代表不同元件的不同目錄來建構此存放庫。
  • 建立分支來代表每個環境類型。 這可讓您更精細地控制每個特定環境的變更，例如非生產環境與生產環境。
  • 叢集操作員應該使用 Helm 之類的套件管理員，或 Kustomize 重疊等設定工具，讓設定更簡單。

CI/CD 和組態更新程式

CI/CD 和容器映射更新

• CI 管線
  • 開發小組應該透過流程定義 CI 管線，包括建置、Linting、測試，以及將應用程式推送至容器登錄。
• CD 管線
  • 建立CD管線，以針對您的應用程式組態存放庫執行以變更為目標的腳本。 此腳本會建立一個從目標環境來源的暫存分支、對映射標記版本進行變更、認可變更，以及針對您的目標環境分支開啟提取要求。 此 CD 管線可以有具有適當環境變數的環境階段，以正確的 GitOps 組態存放庫和分支為目標。
  • 定義環境階段的手動核准步驟，以限制所有環境的垃圾提取要求。
• 在應用程式組態存放庫上啟用分支原則，以強制執行環境的對等檢閱或核准。 這可涉及最低數目的必要檢閱，或針對較低環境自動核准。 也請考慮視需要進行第三方整合和核准，以符合貴組織的標準。

全叢集和應用程式組態更新

• 叢集運算子和應用程式操作員會各自定義其個別組態存放庫中的組態。 這些使用者不需要管線工具來推送設定。 他們會改用原生 Git 認可和 PR 程式來定義組態，並將變更推送至代表環境的分支。
• 針對新的組態定義，首先在較低環境中定義組態，例如 Dev，然後透過合併和提取要求升級至較高環境。 視需要針對特定環境進行挑選設定更新。

意見反應和警示

• 設定 Flux 通知，以在 GitOps 設定 無法同步處理或擲回錯誤時發出警示。 應用程式操作員應設定警示，以判斷應用程式部署成功且狀況良好。 叢集操作員應設定警示，以判斷整個叢集元件對帳失敗，以及 Git 存放庫發生同步處理問題時。
• 實作 GitOps 連線 或將 Flux 代理程式的意見反應整合到 CI/CD 工具。

安全性建議

• 檢閱 已啟用 Azure Arc 的 Kubernetes 叢集的治理和安全性建議 。
• 使用私人 Git 存放庫搭配驗證和授權，來定義任何組態存放庫，以避免不想要存取任何叢集組態。
  • 使用 SSH 連線 至 GitHub
  • 為 Azure DevOps 選擇正確的驗證機制
• 如果您的 Git 提供者支援 Git 存放庫，請透過 SSH 通訊協定和 SSH 金鑰存取您的 Git 存放庫。 如果 SSH 因輸出連線限制而無法使用，或如果您的 Git 提供者不支援必要的 SSH 連結庫，請使用專用的服務帳戶，並將 API 金鑰與該帳戶產生關聯，以供 Flux 使用。 如果您在使用 GitHub 時需要 SSH 的替代方案，您可以 建立個人存取權杖 以進行驗證。
• 設定符合叢集責任的分支原則和許可權。 設定核准變更的檢閱者數目下限。
• 設定 PR 管線來驗證 YAML 組態和語法，並選擇性地部署測試 Kubernetes 叢集。 設定分支原則，要求此管線在接受任何合併之前成功執行。
• 使用適用於秘密存放區 CSI 驅動程式的 Azure 金鑰保存庫 提供者來實作秘密，以便將 Azure 金鑰保存庫 整合為已啟用 Azure Arc 的 Kubernetes 叢集，並透過 CSI 磁碟區。
• Flux 延伸模組支援命名空間和叢集範圍設定。 當您的設定不應該具有單一命名空間以外的存取權時，請選擇命名空間範圍。

下一步

如需混合式和多重雲端雲端旅程的詳細資訊，請參閱下列文章。

• 檢閱 已啟用 Azure Arc 的 Kubernetes 的必要條件 。
• 檢閱 已啟用 Azure Arc 之 Kubernetes 的已驗證 Kubernetes 散發 套件。
• 瞭解如何 管理混合式和多重雲端環境。
• 若要深入瞭解已啟用 Azure Arc 的 Kubernetes GitOps：
  • 使用 Flux v2 檢閱概念 GitOps。
  • 瞭解如何搭配 Flux v2 使用 GitOps。
  • 檢閱 概念 GitOps Flux v2 CI/CD 程式。
  • 請遵循教學 課程來實作 Flux v2 CI/CD。
• 使用來自 Azure Arc Jumpstart 的 GitOps 流程體驗已啟用 Azure Arc 的 Kubernetes。
• 透過 Azure Arc 學習路徑瞭解 Azure Arc。
• 請參閱 常見問題 - 已啟用 Azure Arc 以尋找最常見問題的解答。