當下最熱門的 GitOps,你了解嗎?
- 2020 年 2 月 21 日
- 筆記

GitOps 的概念最初來源於 Weaveworks 的聯合創始人 Alexis 在 2017 年 8 月發表的一篇部落格 GitOps – Operations by Pull Request。文章介紹了 Weaveworks 的工程師如何以 Git 作為事實的唯一真實來源,部署、管理和監控基於 Kubernetes 的 SaaS 應用。
隨後,Weaveworks 在其網站上發表了一系列介紹 GitOps 應用案例和最佳實踐的文章,對 GitOps 進行推廣。同時,市場上也出現了一批擁抱 GitOps 模式的工具和產品,如 Jenkins X、Argo CD、Weave Flux 等。而 KubeCon EU 2019 中關於 GitOps 的討論 GitOps and Best Practices for Cloud Native CICD,則讓 GitOps 進入到了更多人的視野當中。
本文將以上述資料為基礎,重點介紹如下內容:
- 什麼是 GitOps?
- 推模式和拉模式
- GitOps 的主要優勢
- GitOps 關鍵工具
什麼是 GitOps?
GitOps 是一種快速、安全的方法,可供開發或運維人員維護和更新運行在 Kubernetes 或其他聲明式編排框架中的複雜應用。
GitOps 四項原則
以聲明的方式描述整個系統
藉助 Kubernetes、Terraform 等工具,我們只需要聲明系統想要達到的目標狀態,工具會驅動系統向目標狀態逼近。聲明意味著系統狀態由一組事實而不是一組指令保證,方便進行維護。當我們將聲明資訊存儲在 Git 中後,系統狀態便具備了唯一的事實來源。這樣,我們可以輕鬆地部署和回滾應用。更重要的是,當災難發生時,群集的基礎架構也能夠可靠且快速地再現。
系統的目標狀態通過 Git 進行版本控制
通過將系統的目標狀態存儲在具有版本控制功能的系統中,並作為唯一的事實來源,我們能夠從中派生和驅動一切。
- 通過 pull request 發起對目標狀態的變更申請,狀態變化清晰呈現,變更 review 簡單明了。
- 系統的每一次變更都對應著一條 git commit,變更行為可審計。
- 回滾操作只需要使用git revert命令把目標狀態恢復到前一個狀態。
對目標狀態的變更批准後將自動應用到系統
一旦將聲明的狀態保存在 Git 中,下一步就是允許對該狀態的任何變更都能自動地應用於系統,這樣可以極大地提升產品交付速度。更重要的是,GitOps 採用拉模式更新系統狀態,將做什麼和怎麼做分開,這樣能夠更加有效地劃分出系統的安全邊界。
驅動收斂 & 上報偏離
GitOps 中包含一個操作的回饋和控制循環。它將持續地比較系統的實際狀態和 Git 中的目標狀態,如果在預期時間內狀態仍未收斂,便會觸發告警並上報差異。同時,該循環讓系統具備了自愈能力。自愈不僅僅意味著節點或 pod 失敗, 這些由 Kubernetes 處理,在更廣泛的角度,它能修正一些非預期的操作造成的系統狀態偏離。下圖展示了 GitOps 按控制論思想構建的閉環控制系統。

GitOps 的簡潔定義
進一步,可以將 GitOps 總結成以下兩點:
- An operating model for Kubernetes and other cloud native technologies, providing a set of best practices that unify deployment, management and monitoring for containerized clusters and applications.
- A path towards a developer experience for managing applications; where end-to-end CICD pipelines and git workflows are applied to both operations, and development.
推模式和拉模式
本章將介紹交付流水線中的推模式和拉模式,並解釋為何 GitOps 選用拉模式來構建流水線。
CI/CD 流水線
目前大多數 CI/CD 工具都基於推模式建交付流水線。程式碼被合併到主分支後會觸發 CI 系統進行構建和一系列的測試,並將新生成的鏡像推送至鏡像倉庫,最後再通過 kubectl set image、helm upgrade、ksonnet apply 等方式將新版本直接應用到系統,整個流程如下圖所示。

雖然這樣的方式自動化程度很高,但對它進行審視後會發現如下問題:
- 跨越安全邊界共享秘鑰 – 在推模式下,為了讓 CI 系統能夠自動地部署應用,需要將集群的訪問秘鑰共享給它。雖然可以通過一些措施進行防護,但畢竟還是將秘鑰暴露在了可信度較低的安全上下文中。這種做法擴大了攻擊面,會給系統帶來潛在的安全風險。
- 回滾操作複雜 – 如果通過 CI 任務完成一次部署後,系統出現異常,你將如何知道應該回滾到哪一個版本?你可能需要仔細查看構建日誌才能找到答案。
- 難以快速重建集群 – 在集群完全崩潰的情況下進行重建,如何確定需要部署的每個應用的版本?你可能需要重新跑一遍 CI 任務。
GitOps 流水線
GitOps 基於拉模式構建交付流水線。此時,開發人員發布一個新功能的流程如下:
- 通過 pull request 向主分支提交包含新功能的程式碼。
- 程式碼審核通過後將被合併至主分支。
- 合併行為將觸發 CI 系統進行構建和一系列的測試,並將新生成的鏡像推送至鏡像倉庫。
- GitOps 檢測到有新的鏡像,會提取最新的鏡像標記,然後同步到 Git 配置倉庫的清單中。
- GitOps 檢測到集群狀態過期,會從配置倉庫中拉取更新後的清單,並將包含新功能的鏡像部署到集群里。
通過為不同的集群創建各自的子目錄或分支,可以輕鬆地將該模式拓展到多集群環境。

接下來讓我們看看 GitOps 流水線如何解決推式流水線中存在的那些問題。
- 部署在集群內部的 GitOps 模組負責更新集群,這樣就避免了集群 API 和秘鑰的跨邊界暴露。更重要的是,流水線中每個邏輯單元的寫操作都被限定在了安全邊界以內,職責劃分清晰。
- 由於每一次變更都對應著一條 git commit,回滾操作只需要簡單的把目標狀態恢復到前一個狀態。
- 由於在 Git 的配置倉庫中保留了集群的目標狀態,如果集群完全崩潰,可以基於倉庫中的清單快速重建集群。
GitOps 的主要優勢
經過上面兩章的介紹,可以將 GitOps 的優勢總結如下:
- 提高生產力 – 採用集成了回饋控制循環的持續部署流水線可以大大提升新功能的發布速度。
- 提升開發者體驗 – 開發者可以使用熟悉的工具 Git 去發布新功能,而無需了解複雜的部署交付流程。新入職的員工可以在幾天內快速上手,從而提高工作效率。
- 行為可審計 – 使用 Git 工作流管理集群,天然能夠獲得所有變更的審計日誌,滿足合規性需求,提升系統的安全與穩定性。
- 更高的可靠性 – 藉助 Git 的還原(revert)、分叉(fork)功能,可以實現穩定且可重現的回滾。由於整個系統的描述都存放在 Git 中,我們有了唯一的真實來源,這能大大縮短集群完全崩潰後的恢復時間。
- 一致性和標準化 – 由於 GitOps 為基礎設置、應用程式、Kubernetes 插件的部署變更提供了統一的模型,因此我們可以在整個組織中實現一致的端到端工作流。不僅僅是 CI/CD 流水線由 pull request 驅動,運維任務也可以通過 Git 完全重現。
- 更強的安全保證 – 得益於 Git 內置的安全特性,保障了存放在 Git 中的集群目標狀態聲明的安全性。
GitOps 關鍵工具
GitOps 的概念來源於 Weaveworks,但它並沒有和特定的公司或工具綁定。下面列出了一些實現 GitOps 模式可選用的工具。
- Infrastructure as Code & Configuration as Code
- Terraform
- CloudFormation
- ROS
- Kubernetes
- Chef
- Ansible
- 版本控制工具
- GitLab
- Bitbucket
- 敏感資訊管理
- Sealed Secrets
- SOPS
- Vault
- 狀態比較工具
- Kubediff
- 交付流水線
- Jenkins X
- Argo CD
- Weave Flux
- Spinnaker
總結
Flickr 的工程師 John Allspaw 和 Paul Hammond 在 Velocity Conf 2009 上發表的演講 10+ Deploys Per Day: Dev and Ops Cooperation at Flickr 開啟了 DevOps 時代的序幕。它是人們追求以更高的頻率發布高品質的軟體的必然產物。
進入雲原生時代後,產品的基礎設施、系統架構和運維方式都發生了很大變化。為此,GitOps 對 DevOps 理念進行了擴展,它吸收了 DevOps 文化中協作、試驗、快速回饋、持續改進等思想,並以 Git 作為事實的來源和鏈接的橋樑,旨在簡化雲原生時代基礎設施和應用程式的部署與管理方式,實現產品更快、更頻繁、更穩定的交付。
參考資料
- GitOps – Operations by Pull Request
- Feedback and Control – an Essential GitOps Component
- What DevOps is to the Cloud, GitOps is to Cloud Native
來源:segmentfault 原文:http://t.cn/AiTLDq6K 題圖:來自Google圖片搜索 版權:本文版權歸原作者所有 投稿:歡迎投稿,郵箱: [email protected]