Kubernetes允許我們單純地使用聲明性的配置文件來管理我們的應用部署和其他基礎設施組件（例如，我們現在都是YAML開發者）。這使我們能夠把所有這些文件放到Git倉庫中，然后把它掛到流水線上（Jenkins、GitLab等），流水線會把這些變化應用到集群上，然后就有了GitOps。

為了使工作正常進行，我們必須確保改變集群的唯一方法是在Git倉庫上提交。GitOps并不是專門針對Kubernetes的，同樣的原理也可以應用于任何其他聲明式配置管理的環境。

可以說，很多企業已經開始采用GitOps了，但現在是業界開始充分認識到其潛力的時候。所以，讓我們深入了解一下它如此出色的原因吧！

1、存儲環境變更歷史記錄

只有通過更新相應Git倉庫中的配置，才能改變應用環境。這將創建一個完整的狀態變化的歷史記錄，包括誰做了更改和為什么更改的記錄。你可以通過正在使用的Git用戶界面來讀取歷史記錄。

2、輕松回滾到之前的狀態

一旦我們所有的變更都被存儲為Git歷史記錄，就可以很容易地將一個環境回滾到之前的任何狀態。通過還原一些commit，我們可以回到以前的工作狀態。

3、保障部署安全

一旦對集群的所有更改都通過GitOps repo，用戶和持續集成（CI）流程就不需要再訪問集群了。這大大降低了攻擊面，尤其是還可以減少對Kubernetes API的網絡訪問。

部署過程無論如何實現，都可以在集群內部運行，并從Git中拉取配置。其對API的訪問使用基于角色的訪問控制（RBAC）進行限制。這極大地提高了集群的安全性，防止任何惡意的遠程更改在API服務器上。

4、輕量化審批程序

在修改生產環境時，開發人員總是不受信任。因此在許多公司中都建立了四眼審批流程（four-eyes approval processes），不論是出于什么原因建立的審批流程，GitOps都提供了一個簡單的方法來實現它們。

具體實現方式取決于你使用的Git服務器，但重點是給開發人員在Git repo上創建拉取請求的權利，同時給另一組人審查和合并的權利。大多數Git服務器都有一個很好的UI來檢查修改和批準拉取請求——所以這個解決方案不僅便宜，而且對用戶也相當友好。

5、模塊化架構

GitOps有3個部分：Git repo、部署流程以及一個在Git repo中自動更新版本的過程。這三者可以相互獨立演化或替換。

一邊是一個組件在Git repo寫入，另一邊是一個組件在讀取。Git repo的結構成為這些組件之間的橋梁。由于這是一個相當松散的耦合，兩邊可以用不同的方式甚至不同的技術棧來實現。

6、獨立于工具的架構

第5點中提到的模塊化可以看出GitOps架構是一個可以靈活組裝最佳工具的架構。當然，任何流行的Git服務器都可以完成Git部分的工作，FluxCD或ArgoCD可以負責將repo同步到集群。JenkinsX是一個處理這個過程所有部分的工具，包括創建Git repos，并在構建新的Docker鏡像時用新版本更新它們。

7、復用現有知識

將 Git 置于部署流程的核心，可以充分利用大多數開發人員和運維人員已經掌握的 Git 知識。不需要新的工具來瀏覽部署歷史或實施審批流程。所有的流程都是用大家都熟悉的工具來完成的。

8、比較不同的環境

當你有一個從開發到用戶接受度測試（UAT）再到生產的環境鏈時，跟蹤這些環境之間的差異是一件很麻煩的事情。多虧了存儲在Git repos中的聲明式配置，它使得處理環境間差異就像比較一組YAML文件一樣簡單。

我們有非常棒的工具來做這件事，所以這將不再是一個問題。更重要的是，從頭開始創建一個新的環境，就像復制和粘貼這些文件到一個新的repo中一樣簡單。

9、開箱即用的備份

由于你的環境狀態存儲在Git中，如果Kubernetes上的etcd發生了什么事情，你也永遠不會丟失數據。因為它是你集群狀態的自然備份。

10、像應用程序代碼一樣測試你的更改

你可以用測試應用程序代碼的方式來測試環境中可能出現的破壞性變化。將更改放在一個分支上，然后在其上運行 CI 流水線。你的 CI 工具將能夠運行測試，并根據測試結果將 Git 中的 pull-request 狀態設置為綠色或紅色。一旦所有的東西都經過測試和審查，你就可以合并到master。

這聽起來非常簡單，但自動化測試是基礎設施管理中經常被忽視的任務。雖然GitOps并沒有讓它變得更容易，但至少它為你提供了與你在其他地方使用的相同的熟悉工作流程。

11、高可用部署基礎設施

部署基礎設施保持一致很重要。Git repo服務器通常已經以復制、高可用的方式進行了設置。源代碼是所有開發人員在大多數時間都需要訪問的東西，所以使用Git作為部署的源碼并不會給Git本身增加額外的負擔。
責編AJX