6张图，带你深入理解GitOps，真硬核！
大家好，我是小碗湯，今天分享一篇6張圖深入理解GitOps，內容硬核，建議兄弟們收藏~
在使用 K8s 的云原生應用中，Serverless，Devops 工具以及大量其他云技術。通常，基礎設施代碼和應用程序代碼是分開和單獨部署的，從而會導致系統狀態和配置漂移、不穩定、錯誤配置變更等問題。
GitOps 將 Git 與 GitOps Operator 工具結合在一起，它們通常都在 K8s 中，使 Git 為開發人員提供更高效、更安全、更集中的版本控制，是 K8s 的集中式操作模型、可以更快發布版本。
今天，容器化已經成為在開發、測試和生產環境中運行應用程序的標準方式。因此，容器編排已經成為部署過程中不可或缺的一部分。
容器在一個獨立的實例中運行應用程序及其所有依賴項，類似于 VM，但更輕量。它們與運行它們的主機共享操作系統內核存儲和網絡。容器可以在持續集成和持續部署過程中，保證操作系統、依賴項和應用程序不變。
目前為止，Docker 仍是最流行的容器運行時。當多個容器同時運行時，我們需要編排。可以在單個或少量 docker 服務器上部署許多容器，但管理網絡，存儲，容器編排，這就是 K8s 發揮作用的地方。
K8s 是一種編排解決方案，它抽象了運行多個容器的復雜性，甚至是在多個集群中運行這些容器的復雜性。它接管了成百上千個容器的計算、網絡和存儲，但它依賴這些底層基礎設施。
對 CI/CD 流程的理解
在進入GitOps的核心概念之前，先了解一下容器和k8s是如何兼容CI/CD Pipeline的。
標準CI/ CD流程上圖顯示了一個標準的持續集成和交付過程。這個過程可能相當復雜，便于理解，我們盡量保持簡單。
這里首先由開發人員提交代碼并將其推送到版本控制系統(通常是 git)。
創建一個 pull 請求合并到主分支。一旦代碼被合并，它就會觸發自動構建，將這些提交的更改合并到一起。
構建發生在 CI 服務器上，如果構建和測試一切順利，則構建應用程序的容器鏡像，并將其推送到容器注冊中心。這個過程被稱為持續集成。
代表應用程序不同版本的容器鏡像存儲在注冊表中，以便部署在不同的環境中進行測試。作為持續集成的擴展，這些步驟被稱為持續交付。
當測試通過時，可以觸發應用程序新版本的自動化生產部署。
CI/CD 過程中可能涉及多個手動步驟，但是當隨著時間推移，開發過程變得成熟時，可能會取消手動干預，這稱為持續部署。
在持續交付過程中，在k8s中設置預期的狀態，然后根據鏡像創建單個容器。但是容器鏡像在本質上是不可變的，所以當我們需要更新已部署的應用程序時，需要使用新代碼和所有依賴項創建一個新的容器鏡像。
為了獲得所需的狀態，k8s從遠程注冊表獲取鏡像并達到期望狀態。我們需要為它提供一組k8s配置清單，這些配置清單描述應用程序將如何運行。這些YAML清單引用容器鏡像來標識部署的應用程序版本，還包含其他配置，如：副本實例數、健康檢查、安全和自動伸縮等。
配置漂移問題
K8s 將嘗試根據YAML中的定義，向期望狀態接近，它也將響應之后的用戶請求來更改所需狀態。
這可以使用不依賴于YAML清單的命令(kubectl 命令)來完成。這些命令會改變期望狀態，配置開始偏離YAML清單中已經定義的內容。
讓我們用一個例子來理解它:
這里簡化了 CI/CD 過程，以關注在一段時間內配置漂移問題是如何發生的。
從v1版本的應用程序部署到k8s集群開始。
我們已經定義的 CI/CD 流程，用于按照我們預期的狀態(DSC 1)將配置應用到集群。
現在，應用程序在集群中以定義的期望狀態(DSC 1)運行了一段時間，但最終出現了一些操作問題。
例如：由于流量突然增加，應用數量需要在節點級擴容，或一些安全配置需要立即應用到集群。為此，需使用必要的命令改變配置，改變已部署的應用程序。如下面所示圖：
最終，在生產環境中長時間運行應用程序后，應用程序的版本 2 (App Version 2)已經準備好了新特性，并上傳工作負載清單以引用較新的鏡像。
同樣，我們的 CI/CD 將負責應用更新后的YAML清單，并且我們將依賴 K8s 在期望的狀態下優雅地處理更改。
但理想狀態是什么？是更新后的清單引用了新的容器鏡像嗎？
它是我們在動態集群中所做的必要更改和新的工作負載清單的合并嗎？
K8s 認為理想狀態應該是什么？
這個問題的答案是：K8s 會根據要求合并配置更改，但是集群的狀態將不再準確反映我們開始時使用的 YAML 配置清單。
什么是 GitOps?
配置漂移可能是一個嚴重的問題，我們最好管理配置的完整性，以便在 K8s 中配置的內容準確地反映預期。
GitOps 就為了解決這個問題。它可以用來有效地管理配置，并幫助實現可靠和自動化的部署。
GITOPS是依賴于軟件自動化建立期望狀態的云原生應用程序的操作模型模式，其使用版本控制系統，作為提供自動連續交付的真實來源。
所以 GitOps 通常描述的是期望的狀態配置，并將其存儲在版本控制系統中，它管理在期望狀態下的變化。然后通過自動化代理(如 Flux 或 Argo CD)將這個期望的狀態應用到目標環境(k8s，但不一定)，然后根據版本控制系統中可用的內容持續監視系統的實際狀態。
自動化代理可以是外部的，也可以在系統內運行。他們連續監測系統，并觀察配置漂移的行為，做一些操作（可以配置為發出警報，或者以自動化的方式進行修復）。
GitOps 的部署策略
GitOps 的部署策略可以用推模型或拉模型來實現，下面我們試著去理解這兩種模型。
Push Model
在本文開頭，我們討論了標準的 CI/CD 過程是怎樣的，即開發人員將代碼推送到 VCS，然后通過 pull request 觸發 CI 構建。從那里產生的 docker 文件作為 CI 過程的結果，存儲在注冊表。在 CD 過程中部署到 K8s 集群，如下步驟 1,3,4,5 和 6 所示。
Push部署策略Push 部署策略
GitOps 的 Push 部署策略非常類似于 CI/CD 流程，只是清單文件包含了定義 K8 服務器需要創建對象的配置。Manifest 文件也在 VCS 中管理，可以是同一個 VCS，也可以是單獨的存儲庫。
正如我們上面討論的，部署和監控應用程序的自動化過程可以是外部的，也可以是內部的，對于 Push 部署策略，它是外部的，通常由同一個 CI 服務器管理。CI 服務器可以執行kubectl apply命令，將 manifest 應用到集群中。
Pull Model
在GitOps Pull場景中，自動化不是從集群外部操作，而是在集群內部部署一個代理。它作為Kubernetes Operator運行，能夠跟蹤包含 K8s 清單的 VSC 倉庫。
Pull部署策略Pull 部署策略
當它在集群中運行時，它知道集群的實際狀態。如果它檢測到 VCS 中包含的真實源與集群中的實際狀態之間存在差異，它就會采取行動。要么發出告警，要么試圖通過與 VCS 的內容同步來調和差異。還可以將代理配置為以新鏡像的形式，監視遠程容器注冊表中應用程序代碼的新版本。然后代理能夠在 VCS 中更新清單，并基于新鏡像觸發新的自動部署。
由于 Pull 部署策略需要K8s Operator來執行操作，我們需要為此尋找特定的工具。雖然有多種可用的工具，但其中兩個是最受歡迎的，CNCF 也推薦了它們。例如Flux[1]和ArgoCD[2]。可以在官網中獲得更多細節。
本文是對 GitOps 的理解，以及它如何解決配置漂移問題，來實現系統的高級治理。深入研究 GitOps 工具，看它們是如何實現的，將在后續文章中做分析。
本文翻譯自：https://reurl.cc/OpqNqX，版權歸原作者所有
歡迎小伙伴們投稿原創文章~
投稿格式：markdown格式的md文件
投稿郵箱: pub@kubeinfo.cn
參考資料
[1]
Flux: https://fluxcd.io/
[2]ArgoCD: https://argo-cd.readthedocs.io/en/stable/
點個在看你最好看
總結
以上是生活随笔為你收集整理的6张图，带你深入理解GitOps，真硬核！的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 如何在并发中给 HttpClient 设
- 下一篇： 解读最新的 Xamarin 更新