Kubernetes允許我們單純地使用宣告性的配置檔案來管理我們的應用部署和其他基礎設施元件（例如，我們現在都是YAML開發者）。這使我們能夠把所有這些檔案放到Git倉庫中，然後把它掛到流水線上（Jenkins、GitLab等），流水線會把這些變化應用到叢集上，然後就有了GitOps。如果你還不瞭解GitOps是什麼，可以檢視我們之前釋出過的文章：GitOps初階指南：將DevOps擴充套件至K8S
為了使工作正常進行，我們必須確保改變叢集的唯一方法是在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本身增加額外的負擔。