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

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

可以說，很多企業(yè)已經(jīng)開始采用GitOps了，但現(xiàn)在是業(yè)界開始充分認(rèn)識到其潛力的時候。所以，讓我們深入了解一下它如此出色的原因吧!

1、存儲環(huán)境變更歷史記錄

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

2、輕松回滾到之前的狀態(tài)

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

3、保障部署安全

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

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

4、輕量化審批程序

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

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

5、模塊化架構(gòu)

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

一邊是一個組件在Git repo寫入，另一邊是一個組件在讀取。Git repo的結(jié)構(gòu)成為這些組件之間的橋梁。由于這是一個相當(dāng)松散的耦合，兩邊可以用不同的方式甚至不同的技術(shù)棧來實現(xiàn)。

6、獨立于工具的架構(gòu)

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

7、復(fù)用現(xiàn)有知識

將 Git 置于部署流程的核心，可以充分利用大多數(shù)開發(fā)人員和運維人員已經(jīng)掌握的 Git 知識。不需要新的工具來瀏覽部署歷史或?qū)嵤徟鞒獭Ｋ械牧鞒潭际怯么蠹叶际煜さ墓ぞ邅硗瓿傻摹?/p>

8、比較不同的環(huán)境

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

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

9、開箱即用的備份

由于你的環(huán)境狀態(tài)存儲在Git中，如果Kubernetes上的etcd發(fā)生了什么事情，你也永遠(yuǎn)不會丟失數(shù)據(jù)。因為它是你集群狀態(tài)的自然備份。

10、像應(yīng)用程序代碼一樣測試你的更改

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

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

11、高可用部署基礎(chǔ)設(shè)施

部署基礎(chǔ)設(shè)施保持一致很重要。Git repo服務(wù)器通常已經(jīng)以復(fù)制、高可用的方式進(jìn)行了設(shè)置。源代碼是所有開發(fā)人員在大多數(shù)時間都需要訪問的東西，所以使用Git作為部署的源碼并不會給Git本身增加額外的負(fù)擔(dān)。