GitOps的工作原理是什么

這篇文章主要介紹“GitOps的工作原理是什么”，在日常操作中，相信很多人在GitOps的工作原理是什么問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”GitOps的工作原理是什么”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！

工作原理

GitOps秉承了DevOps的核心理念--“構建它并交付它(you built it you ship it)”。它能夠讓開發人員在自己所選的Git工具中，提出拉式請求，觸發Kubernetes集群的部署，從而使得Git成為唯一的來源。

顯然，該思想是將基于推式的管道替換為基于拉式的管道，從而使得開發人員能夠直接根據其拉式請求執行部署。而一旦開發人員執行合并或打開請求，該基礎結構就會在部署過程中觸發一系列的事件。GitOps運算符(operator)只要檢測到此類變化，就會導致另一個運算符聲明的更改，并將其部署到集群之中。例如，您可以使用如下工具棧來實現GitOps：

1. 將Bitbucket作為您的Git VCS(譯者注：Version Control System，版本控制系統)工具。

2. 用Docker存儲您的各種鏡像。

3. 用Amazon S3來存儲各種Helm圖表。

4. 用AWS Lambda拉取圖表，并提交給集群存儲庫。

5. 用Weaveworks Flux檢測集群存儲庫中的更改，并做相應的調整。

當然，在您的工具棧中，實現此類功能的實際基礎架構可能會有所不同，但是其機制卻是相似的。

如下是可以實現的GitOps工作流：

1. 使用 Bitbucket管道之類的CI(持續集成)工具，將各種Docker鏡像推送到 Quay之類的托管(hosting)工具處。

2. 各種云功能函數從主存儲bucket處，將不同的配置和 helm圖表復制到主git存儲庫中。

3. 諸如 Weaveworks Flux之類的GitOps運算符，會根據各種配置圖表去更新集群，并通過Lambda函數提取不同的helm圖表。

當然，上述技術棧中所描述的每個工具都有著對應的替代方案，開發團隊可以選擇最適合的工具，以實現DevOps的目標。例如，同屬于Atlassian套件的Jira功能就能夠輕松地與Bitbucket協同發揮作用。因此，如果一個拉式請求在Bitbucket中被創建，就會自動將Jira中的問題發送到自定義的“部署”上。這將大幅簡化從設計到發布的DevOps實踐過程。

類似地，當考慮到通過GitOps實現的持續交付機制可能出現失敗時，我們可以添加其他的監控工具，以提供急需的可見性。例如，Thundra.io可被用于監控S3觸發的AWS Lambda函數，以確保在將更改提交給集群存儲庫時，不會發生任何故障。

同理，我們也可以利用Thundra.io的集成功能，將警報發送給Opsgenie之類的報警工具，進而通知合適的值班人員，以快速解決那些由拉式請求觸發的部署所引發的任何問題。

可見，我們完全可以通過向GitOps引擎添加更多的功能，以提高GitOps實踐過程中的可靠性和便利性。

給帶來的Kubernetes的便利性

總的說來，GitOps能夠為Kubernetes的部署提供融合、冪等、確定性和自動化等方面的功能。根據Kubernetes強大的收斂機制，它將不斷嘗試去改變集群的狀態，讓各種收斂應用都具有相同的結果。而且這些都會自動而迅速地被觸發。

Kubernetes的編排器(orchestrator)會持續將各種更改應用到集群中，直到集群收斂到配置更新所定義的狀態為止，也就是要滿足開發人員或SRE人員所期望的配置狀態。這不但適用于所有的Kubernetes資源，還能夠被用到自定義資源(Custom Resource Definitions，CRD)或Kubernetes的擴展。

整個GitOps的過程始于在Git存儲庫中定義某個所需的狀態，然后Git被定位為唯一的來源。此外，我們需要保障提交過來的更改能夠與群集相配，以便標記處群集是已經收斂到了所需的狀態，還是已偏離了該狀態。

當期望狀態與實際狀態不相同時，Kubernetes中的收斂運算符會主動嘗試著補足這兩個狀態之間的差異，即：根據那些針對Git的提交，觸發更改的“差異”警報，以標識處仍然需要進一步的收斂。因此，這就意味著，所有的提交都會產生對于集群的可驗證的、且冪等的更改。當然，Kubernetes也可能按需產生回滾。就其機制而言，回滾可以被看作是進一步收斂到以前的狀態。

最后，如果系統中不再存在“差異”警報、或僅存在“聚合”警報，那么該機制就認為實際狀態已經達到了所需的狀態。實際上，我們可以使用回調、或回寫事件的方法，來設置此類聚合狀態。

至此，我們可以認識到：GitOps依賴于IAC(譯者注：基礎架構即代碼)的概念。即：以編程的方式定義了基礎架構，而基礎架構的實際狀態也會隨著發生相應的變化。這種就是我們在前文中提到的基于拉式的部署方式，它與傳統的基于推式的部署有所不同。

相關工具

如您所知，DevOps是一個廣闊的領域，它不僅僅限于軟件行業。而GitOps則只是在軟件行業朝著更加敏捷、可靠的方向發展過程中，一種新興的開發實踐。更準確地說，隨著技術趨勢的變化，開發實踐必須適應可用的技術，而GitOps是團隊和組織如何跟蹤技術發展，持續推進開發實踐的一種優秀示例。值得一提的是，諸如Weaveworks Flux之類的運算符，可以很好地幫助您在集群啟用GitOps。當然，您也可以選用Spinnaker之類的其他代替方案。

此外，考慮到持續部署可能會給生成環境帶來風險，我們可以通過添加諸如Thundra.io和Opsgenie之類的工具，來對系統進行全覆蓋性的測試，以減少風險點，保證一定的可觀察性和事件管理能力。

到此，關于“GitOps的工作原理是什么”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！