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

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

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

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

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

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

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

3、保障部署安全

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

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

4、輕量化審批程序

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

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

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

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

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

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

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

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

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

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

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

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

9、開(kāi)箱即用的備份

由于你的環(huán)境狀態(tài)存儲(chǔ)在Git中，如果Kubernetes上的etcd發(fā)生了什么事情，你也永遠(yuǎn)不會(huì)丟失數(shù)據(jù)。因?yàn)樗悄慵籂顟B(tài)的自然備份。

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

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

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

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

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