大家好，我是小碗湯，今天分享一篇6張圖深入理解GitOps，內(nèi)容硬核，建議兄弟們收藏~

在使用 K8s 的云原生應(yīng)用中，Serverless，Devops 工具以及大量其他云技術(shù)。通常，基礎(chǔ)設(shè)施代碼和應(yīng)用程序代碼是分開和單獨(dú)部署的，從而會(huì)導(dǎo)致系統(tǒng)狀態(tài)和配置漂移、不穩(wěn)定、錯(cuò)誤配置變更等問題。

GitOps 將 Git 與 GitOps Operator 工具結(jié)合在一起，它們通常都在 K8s 中，使 Git 為開發(fā)人員提供更高效、更安全、更集中的版本控制，是 K8s 的集中式操作模型、可以更快發(fā)布版本。

---

今天，容器化已經(jīng)成為在開發(fā)、測(cè)試和生產(chǎn)環(huán)境中運(yùn)行應(yīng)用程序的標(biāo)準(zhǔn)方式。因此，容器編排已經(jīng)成為部署過程中不可或缺的一部分。

容器在一個(gè)獨(dú)立的實(shí)例中運(yùn)行應(yīng)用程序及其所有依賴項(xiàng)，類似于 VM，但更輕量。它們與運(yùn)行它們的主機(jī)共享操作系統(tǒng)內(nèi)核存儲(chǔ)和網(wǎng)絡(luò)。容器可以在持續(xù)集成和持續(xù)部署過程中，保證操作系統(tǒng)、依賴項(xiàng)和應(yīng)用程序不變。

目前為止，Docker 仍是最流行的容器運(yùn)行時(shí)。當(dāng)多個(gè)容器同時(shí)運(yùn)行時(shí)，我們需要編排。可以在單個(gè)或少量 docker 服務(wù)器上部署許多容器，但管理網(wǎng)絡(luò)，存儲(chǔ)，容器編排，這就是 K8s 發(fā)揮作用的地方。

K8s 是一種編排解決方案，它抽象了運(yùn)行多個(gè)容器的復(fù)雜性，甚至是在多個(gè)集群中運(yùn)行這些容器的復(fù)雜性。它接管了成百上千個(gè)容器的計(jì)算、網(wǎng)絡(luò)和存儲(chǔ)，但它依賴這些底層基礎(chǔ)設(shè)施。

對(duì) CI/CD 流程的理解

在進(jìn)入GitOps的核心概念之前，先了解一下容器和k8s是如何兼容CI/CD Pipeline的。

標(biāo)準(zhǔn)CI/ CD流程

上圖顯示了一個(gè)標(biāo)準(zhǔn)的持續(xù)集成和交付過程。這個(gè)過程可能相當(dāng)復(fù)雜，便于理解，我們盡量保持簡單。

這里首先由開發(fā)人員提交代碼并將其推送到版本控制系統(tǒng)(通常是 git)。

創(chuàng)建一個(gè) pull 請(qǐng)求合并到主分支。一旦代碼被合并，它就會(huì)觸發(fā)自動(dòng)構(gòu)建，將這些提交的更改合并到一起。

構(gòu)建發(fā)生在 CI 服務(wù)器上，如果構(gòu)建和測(cè)試一切順利，則構(gòu)建應(yīng)用程序的容器鏡像，并將其推送到容器注冊(cè)中心。這個(gè)過程被稱為持續(xù)集成。

代表應(yīng)用程序不同版本的容器鏡像存儲(chǔ)在注冊(cè)表中，以便部署在不同的環(huán)境中進(jìn)行測(cè)試。作為持續(xù)集成的擴(kuò)展，這些步驟被稱為持續(xù)交付。

當(dāng)測(cè)試通過時(shí)，可以觸發(fā)應(yīng)用程序新版本的自動(dòng)化生產(chǎn)部署。

CI/CD 過程中可能涉及多個(gè)手動(dòng)步驟，但是當(dāng)隨著時(shí)間推移，開發(fā)過程變得成熟時(shí)，可能會(huì)取消手動(dòng)干預(yù)，這稱為持續(xù)部署。

在持續(xù)交付過程中，在k8s中設(shè)置預(yù)期的狀態(tài)，然后根據(jù)鏡像創(chuàng)建單個(gè)容器。但是容器鏡像在本質(zhì)上是不可變的，所以當(dāng)我們需要更新已部署的應(yīng)用程序時(shí)，需要使用新代碼和所有依賴項(xiàng)創(chuàng)建一個(gè)新的容器鏡像。

為了獲得所需的狀態(tài)，k8s從遠(yuǎn)程注冊(cè)表獲取鏡像并達(dá)到期望狀態(tài)。我們需要為它提供一組k8s配置清單，這些配置清單描述應(yīng)用程序?qū)⑷绾芜\(yùn)行。這些YAML清單引用容器鏡像來標(biāo)識(shí)部署的應(yīng)用程序版本，還包含其他配置，如：副本實(shí)例數(shù)、健康檢查、安全和自動(dòng)伸縮等。

配置漂移問題

K8s 將嘗試根據(jù)YAML中的定義，向期望狀態(tài)接近，它也將響應(yīng)之后的用戶請(qǐng)求來更改所需狀態(tài)。

這可以使用不依賴于YAML清單的命令(kubectl 命令)來完成。這些命令會(huì)改變期望狀態(tài)，配置開始偏離YAML清單中已經(jīng)定義的內(nèi)容。

讓我們用一個(gè)例子來理解它:

這里簡化了 CI/CD 過程，以關(guān)注在一段時(shí)間內(nèi)配置漂移問題是如何發(fā)生的。

從v1版本的應(yīng)用程序部署到k8s集群開始。

我們已經(jīng)定義的 CI/CD 流程，用于按照我們預(yù)期的狀態(tài)(DSC 1)將配置應(yīng)用到集群。

現(xiàn)在，應(yīng)用程序在集群中以定義的期望狀態(tài)(DSC 1)運(yùn)行了一段時(shí)間，但最終出現(xiàn)了一些操作問題。

例如：由于流量突然增加，應(yīng)用數(shù)量需要在節(jié)點(diǎn)級(jí)擴(kuò)容，或一些安全配置需要立即應(yīng)用到集群。為此，需使用必要的命令改變配置，改變已部署的應(yīng)用程序。如下面所示圖：

最終，在生產(chǎn)環(huán)境中長時(shí)間運(yùn)行應(yīng)用程序后，應(yīng)用程序的版本 2 (App Version 2)已經(jīng)準(zhǔn)備好了新特性，并上傳工作負(fù)載清單以引用較新的鏡像。

同樣，我們的 CI/CD 將負(fù)責(zé)應(yīng)用更新后的YAML清單，并且我們將依賴 K8s 在期望的狀態(tài)下優(yōu)雅地處理更改。

但理想狀態(tài)是什么？是更新后的清單引用了新的容器鏡像嗎？

它是我們?cè)趧?dòng)態(tài)集群中所做的必要更改和新的工作負(fù)載清單的合并嗎？

K8s 認(rèn)為理想狀態(tài)應(yīng)該是什么？

這個(gè)問題的答案是：K8s 會(huì)根據(jù)要求合并配置更改，但是集群的狀態(tài)將不再準(zhǔn)確反映我們開始時(shí)使用的 YAML 配置清單。

什么是 GitOps?

配置漂移可能是一個(gè)嚴(yán)重的問題，我們最好管理配置的完整性，以便在 K8s 中配置的內(nèi)容準(zhǔn)確地反映預(yù)期。

GitOps 就為了解決這個(gè)問題。它可以用來有效地管理配置，并幫助實(shí)現(xiàn)可靠和自動(dòng)化的部署。

GITOPS是依賴于軟件自動(dòng)化建立期望狀態(tài)的云原生應(yīng)用程序的操作模型模式，其使用版本控制系統(tǒng)，作為提供自動(dòng)連續(xù)交付的真實(shí)來源。

所以 GitOps 通常描述的是期望的狀態(tài)配置，并將其存儲(chǔ)在版本控制系統(tǒng)中，它管理在期望狀態(tài)下的變化。然后通過自動(dòng)化代理(如 Flux 或 Argo CD)將這個(gè)期望的狀態(tài)應(yīng)用到目標(biāo)環(huán)境(k8s，但不一定)，然后根據(jù)版本控制系統(tǒng)中可用的內(nèi)容持續(xù)監(jiān)視系統(tǒng)的實(shí)際狀態(tài)。

自動(dòng)化代理可以是外部的，也可以在系統(tǒng)內(nèi)運(yùn)行。他們連續(xù)監(jiān)測(cè)系統(tǒng)，并觀察配置漂移的行為，做一些操作（可以配置為發(fā)出警報(bào)，或者以自動(dòng)化的方式進(jìn)行修復(fù)）。

GitOps 的部署策略

GitOps 的部署策略可以用推模型或拉模型來實(shí)現(xiàn)，下面我們?cè)囍ダ斫膺@兩種模型。

Push Model

在本文開頭，我們討論了標(biāo)準(zhǔn)的 CI/CD 過程是怎樣的，即開發(fā)人員將代碼推送到 VCS，然后通過 pull request 觸發(fā) CI 構(gòu)建。從那里產(chǎn)生的 docker 文件作為 CI 過程的結(jié)果，存儲(chǔ)在注冊(cè)表。在 CD 過程中部署到 K8s 集群，如下步驟 1,3,4,5 和 6 所示。

Push部署策略

Push 部署策略

GitOps 的 Push 部署策略非常類似于 CI/CD 流程，只是清單文件包含了定義 K8 服務(wù)器需要?jiǎng)?chuàng)建對(duì)象的配置。Manifest 文件也在 VCS 中管理，可以是同一個(gè) VCS，也可以是單獨(dú)的存儲(chǔ)庫。

正如我們上面討論的，部署和監(jiān)控應(yīng)用程序的自動(dòng)化過程可以是外部的，也可以是內(nèi)部的，對(duì)于 Push 部署策略，它是外部的，通常由同一個(gè) CI 服務(wù)器管理。CI 服務(wù)器可以執(zhí)行kubectl apply命令，將 manifest 應(yīng)用到集群中。

Pull Model

在GitOps Pull場(chǎng)景中，自動(dòng)化不是從集群外部操作，而是在集群內(nèi)部部署一個(gè)代理。它作為Kubernetes Operator運(yùn)行，能夠跟蹤包含 K8s 清單的 VSC 倉庫。

Pull部署策略

Pull 部署策略

當(dāng)它在集群中運(yùn)行時(shí)，它知道集群的實(shí)際狀態(tài)。如果它檢測(cè)到 VCS 中包含的真實(shí)源與集群中的實(shí)際狀態(tài)之間存在差異，它就會(huì)采取行動(dòng)。要么發(fā)出告警，要么試圖通過與 VCS 的內(nèi)容同步來調(diào)和差異。還可以將代理配置為以新鏡像的形式，監(jiān)視遠(yuǎn)程容器注冊(cè)表中應(yīng)用程序代碼的新版本。然后代理能夠在 VCS 中更新清單，并基于新鏡像觸發(fā)新的自動(dòng)部署。

由于 Pull 部署策略需要K8s Operator來執(zhí)行操作，我們需要為此尋找特定的工具。雖然有多種可用的工具，但其中兩個(gè)是最受歡迎的，CNCF 也推薦了它們。例如Flux^[1]和ArgoCD^[2]?？梢栽诠倬W(wǎng)中獲得更多細(xì)節(jié)。

---

本文是對(duì) GitOps 的理解，以及它如何解決配置漂移問題，來實(shí)現(xiàn)系統(tǒng)的高級(jí)治理。深入研究 GitOps 工具，看它們是如何實(shí)現(xiàn)的，將在后續(xù)文章中做分析。

---

---

本文翻譯自：https://reurl.cc/OpqNqX，版權(quán)歸原作者所有

歡迎小伙伴們投稿原創(chuàng)文章~

投稿格式：markdown格式的md文件

投稿郵箱: pub@kubeinfo.cn

參考資料

[1]

Flux: https://fluxcd.io/

[2]

ArgoCD: https://argo-cd.readthedocs.io/en/stable/

點(diǎn)個(gè)在看你最好看

總結(jié)

以上是生活随笔為你收集整理的6张图，带你深入理解GitOps，真硬核！的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。