GitOps 常用工具盤點

在本文中，我將回顧一些我比較喜歡的 GitOps^[1] 工具，這些工具目前在Kubernetes中可用。

在我看來，Kubernetes 的優(yōu)勢主要在于它的聲明式性質(zhì)與控制循環(huán)相結(jié)合，并通過這些控制循環(huán)持續(xù)監(jiān)控集群的活動狀態(tài)，確保它與 etcd^[2] 中存儲的期望狀態(tài)保持一致。這種方式非常強大，但同時其數(shù)據(jù)庫也被限制為etcd(etcd僅提供了有限的可觀察性)，并影響到了集群變更時的責(zé)任性和審計性。另外一個缺點是將etcd和代碼倉庫作為兩個SOT(sources of truth)，有可能會導(dǎo)致配置漂移，造成管理上的困難。

開發(fā)者使用代碼倉庫這種安全且可追溯的方式來保存代碼，并開發(fā)出了 Workflows^[3] 這種方式來高效地管理中央倉庫，不同的團(tuán)隊可以并行工作，且不會產(chǎn)生過多的沖突，同時保證對所有變更進(jìn)行審核，并支持追溯和回滾。

如果我們能夠從圍繞 Git 倉庫創(chuàng)建的流程中獲得這些優(yōu)勢，并將它們擴展到基礎(chǔ)設(shè)施或是 kubernetes 中，那不是很好嗎？

首先聊一下什么是 GitOps，以及如何將其應(yīng)用到 Kubernetes，然后再看一下在 kubernetes 中實現(xiàn)的 GitOps 聲明式工具，最后回顧一些 GitOps 友好的工具，即它們是以代碼的形式實現(xiàn)和聲明的工具。

什么是 GitOps？

GitOps 的目的是將 etcd 的這種聲明式特性擴展到(保存代碼的) Git 倉庫，并作為 SSOT(single source of truth)。通過這種方式，我們可以利用 Git 帶來的優(yōu)勢，如代碼監(jiān)視、歷史變更、快速回滾、可追溯性等等。

GitOps 的核心觀點是使用包含當(dāng)前期望的(生產(chǎn)環(huán)境基礎(chǔ)設(shè)施的)聲明式描述的 GIt 倉庫，并通過自動化流程來確保生產(chǎn)環(huán)境與倉庫中的期望狀態(tài)保持一致。如果你想要部署一個新的應(yīng)用或更新一個現(xiàn)有的應(yīng)用，只需要更新相應(yīng)的倉庫即可(自動化流程會處理后續(xù)的事情)。這就像在生產(chǎn)中使用巡航控制來管理應(yīng)用程序一樣。

GitOps 不僅限于 Kubernetes，實際上它還可以通過將 基礎(chǔ)設(shè)施作為代碼^[4] 保存到GIt倉庫中來將應(yīng)用代碼延伸到基礎(chǔ)設(shè)施中，這通常是通過 Terraform^[5] 這樣的工具進(jìn)行普及的。聲明式基礎(chǔ)設(shè)施既代碼^[6] 在實現(xiàn)GitOps中扮演著一個重要的作用，但不僅限于此。GitOps圍繞Git構(gòu)建了整個生態(tài)系統(tǒng)和工具，并將其應(yīng)用到基礎(chǔ)設(shè)施，僅僅在Git中使用Terraform并不能保證基礎(chǔ)設(shè)施的狀態(tài)能夠與生產(chǎn)環(huán)境保持一致，還需要持續(xù)運行Terraform命令(trrraform apply)來監(jiān)控實時版本的變化，以及在流水線中實現(xiàn)手動審批等功能。

GitOps 的理念是持續(xù)監(jiān)控集群的狀態(tài)并與 Git 倉庫進(jìn)行對比，在配置不一致時立即采取相應(yīng)的動作，防止發(fā)生配置漂移。除此之外，你還可以獲得 Git 帶來的好處，如通過代碼監(jiān)視進(jìn)行手動審批。

對于我來說，這些理念是革命性的，如正確使用，可以讓組織更多關(guān)注功能特性，并減少自動化腳本的編寫工作。這種觀念可以延申到軟件開發(fā)的其他領(lǐng)域，如可以將文檔存儲在代碼中，以此來跟蹤歷史變更，并保證文檔的及時更新；或使用 ADRs^[7] 來跟蹤架構(gòu)決策。

Kubernetes 中的 Gitops

Kubernetes 從一開始就有控制循環(huán)的想法，這意味著 Kunernetes 總是會監(jiān)控集群的狀態(tài)來保證達(dá)到期望狀態(tài)。例如，使運行的副本數(shù)與期望的副本數(shù)匹配。將 GitOps 的理念延申到應(yīng)用，這樣就可以將服務(wù)定義為代碼，例如，通過定義 Helm^[8] Charts，并使用一個通過K8s提供的功能來監(jiān)控App狀態(tài)的工具來調(diào)整對應(yīng)的集群狀態(tài)，即，更新了代碼倉庫，或更新了生產(chǎn)集群的 helm chart。這才是真正的持續(xù)部署。其中的核心原則是，應(yīng)用部署和生命周期管理應(yīng)該是自動化的、可審計并易于理解的。

每個環(huán)境都應(yīng)該有一個代碼倉庫，用于定義給定集群的期望狀態(tài)。然后 Kubernetes Operators 會持續(xù)監(jiān)控特定分支(通常是master分支)，并在探測到 Git 發(fā)生變更后，將此次變更傳遞到集群，并更新etcd中的狀態(tài)。在這種方式中，etcd只作為一個數(shù)據(jù)庫，且不是唯一的SOT?？梢栽诎暶魇終ubernetes基礎(chǔ)設(shè)施的Git倉庫中定義應(yīng)用的Helm chart。此外，還可以鏈接存儲庫，這樣一個存儲庫可以監(jiān)視另一個存儲庫，以此類推。Kubernetes GitOps工具可以監(jiān)控其他倉庫(如Helm Chart倉庫)的狀態(tài)，這樣你的集群環(huán)境倉庫中無需包含Helm Chart，只需要一條到Helm 倉庫的連接，并使用該鏈接監(jiān)控其變更即可，這樣當(dāng)你發(fā)布的一個新的chart時，后續(xù)會將該chart自動部署到集群。通過這種方式自動執(zhí)行端到端的聲明式CI/CD流水線。

聲明式 GitOps 工具

如果考慮 Kubernetes 上的 GitOps，就需要討論那些在 Kubernetes 上實現(xiàn)了 GitOps 原則的工具(負(fù)責(zé)監(jiān)控 Git 的狀態(tài)，并將其同步到集群)。

ArgoCD

在我看來，Kubernetes 上最好的 GitOps 工具就是 ArgoCD^[9] 。ArgoCD 是Argo生態(tài)系統(tǒng)的一部分，該生態(tài)系統(tǒng)包含了很多很好的工具，后續(xù)會進(jìn)行討論。

使用 ArgoCD，可以在代碼庫中定義每個環(huán)境的所有配置。Argo CD 會在特定的目標(biāo)環(huán)境中自動部署所需的應(yīng)用狀態(tài)。

Argo CD 作為一個 kubernetes controller，持續(xù)監(jiān)控運行的應(yīng)用，并將當(dāng)前的活動狀態(tài)與所需的目標(biāo)狀態(tài)(如 Git repo 中描述的狀態(tài))進(jìn)行比較。Argo CD 會報告并呈現(xiàn)這種差異，并通過自動或手動的方式將實時狀態(tài)同步到期望的目標(biāo)狀態(tài)。

**ArgoCD **有一個非常棒的 UI，支持 SSO，它是安全、可擴展且易于使用的。

Flux

Flux^[10] 是除 ArgoCD 外另一個非常有名項目。最近的版本包含很多改進(jìn)，功能上非常接近 ArgoCD，F(xiàn)lux 是 CNCF 孵化項目。

GitOps 工具

在本節(jié)中，回顧一下我比較喜歡的 GitOps 友好的(即基于 CRD 的)工具。

helm

Helm 無需多言，它是 Kubernetes 上最著名的包管理器，當(dāng)然，你應(yīng)該像在編程語言中使用包一樣，在K8s中使用包管理器。Helm 允許使用 Charts 的方式打包應(yīng)用，將復(fù)雜的應(yīng)用抽象為可重用的簡單組件，便于定義、安裝和升級。

它還提供了一個強大的模板引擎，Helm 已經(jīng)很成熟，它包含很多預(yù)定義的charts，支持性強，使用方便。

Helm 可以很好地集成到 ArgoCD 或 Flux，后者可以監(jiān)控 Helm 倉庫的變化，并在發(fā)布新的 charts 時進(jìn)行部署。實現(xiàn)思路是將 ArgoCD 或 Flux 指向 Helm 倉庫，并指定一個特定的版本或通配版本。如果使用通配版本，一旦發(fā)布了新的版本，就會進(jìn)行自動部署。你可以使用主版本或次版本的方式進(jìn)行命名。我通常傾向于將應(yīng)用打包到 charts 中，將其作為 CI/CD 的一部分進(jìn)行構(gòu)建，并讓 ArgoCD 監(jiān)控特定的倉庫。這種關(guān)注點分離允許開發(fā)者在獨立于環(huán)境的倉庫中管理應(yīng)用，并讓 ArgoCD 選擇在哪個環(huán)境中部署哪個 charts。你可以使用多個 Helm 倉庫并根據(jù)不同的環(huán)境推送變更。例如，在合并一個 PR 后，可以執(zhí)行一次 "bronce" 構(gòu)建，該構(gòu)建會將 Helm chart 發(fā)布到一個名為 "bronce" 的倉庫中。dev 環(huán)境的 ArgoCD 倉庫指向 "bronce" 倉庫，并在可用時部署新版本。staging 環(huán)境的 ArgoCD 倉庫會指向名為 "silver" 倉庫，而 production 環(huán)境則指向名為 "gold" 的倉庫。當(dāng)需要向 staging 或 production 環(huán)境推送某些內(nèi)容時，CI/CD 只需將該 chart 發(fā)布到下一個倉庫即可。

ArgoCD 可以覆蓋任何環(huán)境的特定 Helm 值。

Kustomize^[11] 是一個新的 helm 的替代品，它不需要模板引擎，而使用了一個 overlay 引擎，之上有基本定義和 overlays 。

Argo Workflows 和 Argo Events

在 Kubernetes 中，你可能需要運行批量任務(wù)或復(fù)雜的工作流，作為數(shù)據(jù)處理流程、異步處理或 CI/CD 的一部分。除此之外，你可能需要運行驅(qū)動微服務(wù)來響應(yīng)特定的事件，如文件上傳或發(fā)送消息到某個隊列。為了實現(xiàn)這些功能，可以使用 Argo Workflows^[12] 和 Argo Events^[13] 。

雖然它們是獨立的項目，但趨向于部署到一起。

Argo Workflows 是一個類似 Apache Airflow^[14] 的編排引擎，但天然適用于Kubernetes。它使用CRDs來定義復(fù)雜的workflows(使用YAML表示的steps或 DAGs^[15] 來表達(dá)工作流)。它還有個不錯的UI，支持重試機制，定時任務(wù)，輸入輸出跟蹤等。你可以使用它來編排數(shù)據(jù)處理流水線和批量任務(wù)等。

有時你可能希望將流水線與異步服務(wù)(如 Kafka、隊列、webhook 或底層存儲服務(wù))集成到一起。例如，你可能希望對上傳文件到S3這樣的事件做出響應(yīng)，此時你可以使用 Argo Events。

上述兩種工具為需要 CI/CD 流水線提供了簡單且強大的解決方案，可以在 Kubernetes 上運行 CI/CD 流水線。

由于所有 workflows 定義都可以打包到 Helm charts 中，因此 Argo Workflows 可以很好地集成到 ArgoCD。

對于 ML 流水線，可以使用 Kubeflow^[16] 實現(xiàn)相同的目的。

對于 CI/CD 流水線，可以使用 Tekton^[17] 。

Istio

Istio^[18] 是市面上最著名的 服務(wù)網(wǎng)格^[19] ，它是開源的，且非常流行。由于服務(wù)網(wǎng)格內(nèi)容龐大，因此這里不會討論細(xì)節(jié)，但如果你在構(gòu)建微服務(wù)，有可能你會需要一個服務(wù)網(wǎng)格來管理通信、可觀測性、錯誤處理、安全以及(作為微服務(wù)架構(gòu)一部分的)其他交叉方面。使用服務(wù)網(wǎng)格可以避免因為重復(fù)的邏輯而污染微服務(wù)的代碼。

簡而言之，一個服務(wù)網(wǎng)格就是一個特定的基礎(chǔ)設(shè)施層，你可以在上面添加應(yīng)用，它允許透明地添加可觀測性、流量管理和安全，而無需自己實現(xiàn)這些功能。

Istio 使用 CRDs 來實現(xiàn)其所有功能，因此可以將virtual services、gateways、policies等作為代碼打包在Helm charts中，并使用ArgoCD或Flux來讓Istio變得GitOps友好(雖然不是那么強大)。

還可以使用 Linkerd^[20] 或 Consul^[21] 替代Istio。

Argo Rollouts

上面已經(jīng)提到過，你可以使用 Kubernetes 來運行使用Argo Workflows 或類似工具的 CI/CD 流水線。下一步邏輯上是執(zhí)行持續(xù)部署，但在現(xiàn)實場景中，由于其風(fēng)險較高，因此大部分公司只做了持續(xù)交付，這意味著他們可以實現(xiàn)自動化，但仍然采用手動方式進(jìn)行審批和校驗，這類手動步驟的根因是這些團(tuán)隊無法完全信任其自動化。

那么該如何構(gòu)建這種信任度來避免使用腳本，進(jìn)而實現(xiàn)從代碼到生產(chǎn)的完全自動化。答案是：可觀測性。你需要關(guān)注資源的指標(biāo)，并通過采集所有的數(shù)據(jù)來精確地傳達(dá)應(yīng)用的狀態(tài)，即使用一組指標(biāo)來構(gòu)建信任度。如果 Prometheus 中包含所有的數(shù)據(jù)，那么就可以實現(xiàn)自動化部署，因為此時你可以根據(jù)指標(biāo)來實現(xiàn)滾動更新應(yīng)用。

簡單地說，你可以使用 K8s 提供的開箱即用的高級部署技術(shù)-- 滾動升級。我們需要使用金絲雀部署來實現(xiàn)漸進(jìn)式發(fā)布，目的是將流量逐步路由到新版本的應(yīng)用，等待指標(biāo)采集，然后進(jìn)行分析并于預(yù)先定義的規(guī)則進(jìn)行匹配。如果檢查正常，則增加流量；如果發(fā)現(xiàn)問題，則回滾部署。

在 Kubernetes 上可以使用 Argo Rollouts^[22] 來實現(xiàn)金絲雀發(fā)布。

Argo Rollouts 是一個 Kubernetes controller，它使用一組 CRDs 來提供高級部署能力，如藍(lán)綠、金絲雀、金絲雀分析、實驗等，并向Kubernetes提供漸進(jìn)式交付功能。

雖然像 Istio 這樣的服務(wù)網(wǎng)格可以提供金絲雀發(fā)布，但Argo Rollouts簡化了處理流程，且以開發(fā)者為中心。除此之外，Argo Rollouts還可以集成到任何服務(wù)網(wǎng)格中。

Argo Rollouts 是 GitOps 友好的，且能很好地與 Argo Workflows 和 ArgoCD 進(jìn)行集成。使用這三種工具可以為部署創(chuàng)建一個非常強大的聲明式工具集。

Flagger^[23] 和Argo Rollouts非常類似，可以很好地與 Flux^[24] 進(jìn)行集成，因此如果你正在使用Flux，可以考慮使用Flagger。

Crossplane

Crossplane^[25] 是我最近喜歡的K8s工具，它填補了Kubernetes的一個關(guān)鍵空白：像管理K8s資源一樣管理第三方服務(wù)。這意味著，你可以使用YAML中定義的K8s資源，像在K8s中配置數(shù)據(jù)庫一樣配置AWS RDS或GCP cloud SQL等云供應(yīng)商的數(shù)據(jù)庫。

有了 Crossplane，就不需要使用不同的工具和方法來分離基礎(chǔ)設(shè)施和代碼。你可以使用 K8s 資源定義所有內(nèi)容。通過這種方式，你無需去學(xué)習(xí)并分開保存像 Terraform^[26] 這樣的工具。

Crossplane 是一個開源的 Kubernetes 擴展，可以讓平臺團(tuán)隊組合來自多個供應(yīng)商的基礎(chǔ)設(shè)施，并為應(yīng)用團(tuán)隊提供更高級別的自服務(wù) APIs(而無需編碼任何代碼)。

Crossplane 擴展了 Kubernetes 集群，使用 CRDs 來提供基礎(chǔ)設(shè)施或管理云服務(wù)。再者，相比于 Terraform 這樣的工具，它可以完全實現(xiàn)自動部署。Crossplane 使用現(xiàn)成的 K8s 能力，如使用控制循環(huán)來持續(xù)監(jiān)控集群，并自動檢測配置漂移。例如，如果定義了一個可管理的數(shù)據(jù)庫實例，后續(xù)有人手動進(jìn)行了變更，Crossplane 會自動檢測該問題，并將其設(shè)置回先前的值。它將基礎(chǔ)設(shè)施作為代碼并按照 GitOps 原則來執(zhí)行。

Crossplane 可以與 ArgoCD 配合起來，監(jiān)控源代碼，并保證代碼庫是唯一的信任源(SOT)，代碼中的任何變更都會傳遞到集群以及外部云服務(wù)。

如果沒有 Crossplane，你可以在 K8s 服務(wù)中實現(xiàn) GitOps，但無法在沒有額外處理的前提下實現(xiàn)云服務(wù)的GitOps。

Kyverno

Kubernetes 為敏捷自治團(tuán)隊提供了極大的靈活性，但能力越大責(zé)任越大。必須有一套最佳實踐和規(guī)則來保證部署的一致性和連貫性，并使工作負(fù)載遵循公司要求的策略和安全。

Kyverno^[27] 是一種為 Kubernetes 設(shè)計的策略引擎，它可以像管理 Kubernetes 資源一樣管理策略，不需要使用新的語言來編寫策略。Kyverno 策略可以校驗、修改和生成 Kubernetes 資源。

Kyverno 策略是一組規(guī)則，每條規(guī)則包含一個 match 子句，一條 exclude 子句和 validate, mutate 或 generate 中的某條子句。一條規(guī)則定義中只可以包含一個 validate, mutate 或 generate 子節(jié)點。

你可以配置任何有關(guān)最佳實踐、網(wǎng)絡(luò)或安全的策略。例如，可以強制所有包含標(biāo)簽的服務(wù)或所有容器運行在非 root 權(quán)限下。策略可以應(yīng)用到整個集群或特定的命名空間中。你可以選擇是否期望對策略進(jìn)行審計或強制它們阻止用戶部署資源。

Kubevela

Kubernetes 的一個問題是開發(fā)者需要知道并對平臺和集群配置有所了解。很多開發(fā)者抱怨 K8s 的抽象級別太低，因此在那些只關(guān)心編寫和交付應(yīng)用的開發(fā)者中間出現(xiàn)了爭議。

Open Application Model (OAM^[28] ) 可以解決這個問題，它的理念是圍繞應(yīng)用創(chuàng)建一個更高級別的抽象，其獨立于底層運行時。。

通過關(guān)注應(yīng)用而非容器或編排器。OAM 帶來了模塊化、可擴展和可移植的設(shè)計，通過更高級別且一致的 API 對應(yīng)用程序部署進(jìn)行建模。

Kubevela^[29] 是OMA模型的一種實現(xiàn)。KubeVela是運行時無關(guān)，且可擴展的，但最重要的是，它以應(yīng)用程序為中心。在Kubevela 中，應(yīng)用程序是以Kubernetes資源實現(xiàn)的一等公民。需要區(qū)分集群運維人員(平臺團(tuán)隊)和開發(fā)者(應(yīng)用團(tuán)隊)的區(qū)別。集群運維人員通過定義 components(構(gòu)成應(yīng)用程序的可部署/可提供的實體，如 helm charts)和 traits 來管理集群和不同的環(huán)境。開發(fā)者通過組裝components 和traits來定義應(yīng)用。

• 平臺團(tuán)隊：將平臺能力作為 components 或 traits 以及目標(biāo)環(huán)境規(guī)范進(jìn)行建模和管理。
• 應(yīng)用團(tuán)隊：選擇一個環(huán)境，組裝需要的 components 和 traits，并將其部署到目標(biāo)環(huán)境中。

KubeVela 是 CNCF 的沙盒項目，目前正處于初始階段，在不久的將來，它可以改變開發(fā)者使用 Kubernetes 的方式，使他們能夠更加關(guān)注應(yīng)用本身。但我對 OAM 在現(xiàn)實世界中的適用性有一些擔(dān)憂，由于一些像系統(tǒng)程序、ML 或大數(shù)據(jù)處理之類的服務(wù)，它們在很大程度上取決于底層細(xì)節(jié)，這種情況就很難融入 OAM 模型。

Schema Hero

軟件開發(fā)中另一種常見的的處理流程是在使用關(guān)系型數(shù)據(jù)庫時，需要管理 schema 的演進(jìn)。

SchemaHero^[30] 是一個開源數(shù)據(jù)庫的schema遷移工具，可以將schema定義轉(zhuǎn)化為可以在任何環(huán)境運行的遷移腳本。它使用了Kubernetes的聲明特性來管理數(shù)據(jù)庫schema的遷移。你可以指定期望的狀態(tài)，并讓 SchemaHero 管理剩下的工作。

Bitnami Sealed Secrets

至此，我們已經(jīng)涵蓋了很多 GitOps 工具，我們的目標(biāo)是將所有內(nèi)容保存到 Git，并使用 Kubernetes 的聲明特性來讓環(huán)境保持同步。我們可以（也應(yīng)該）在 Git 中保證 SOT，并讓自動化流程處理配置更改。

有一種資源通常難以保存到 Git 中，即 secret，如 DB 密碼或 API 密鑰。一種常見的解決方案是使用外部"保險庫"，如 AWS Secret Manager^[31] 或 HashiCorp Vault^[32] 來保存這些secret，但這樣也產(chǎn)生了沖突，你需要一個單獨的流程來處理secrets。理想情況下，我們希望通過某種方式將secrets像其他資源一樣安全地保存到Git中。

Sealed Secrets^[33] 就是用來解決這種問題的，它允許你將敏感數(shù)據(jù)通過強加密保存到Git中，Bitnami Sealed Secrets天然集成進(jìn)了Kubernetes中，可以使用Kubernetes中運行的Kubernetes controller來解密secret，而無需依賴其他組件。controller可以解密數(shù)據(jù)并創(chuàng)建原生的K8s secrets資源。通過這種方式可以將所有內(nèi)容作為代碼保存到倉庫中，進(jìn)而可以安全地執(zhí)行持續(xù)部署，不需要依賴外部資源。

Sealed Secrets 包含兩部分：

• 集群側(cè)的控制器
• 客戶端側(cè)程序：kubeseal

kubeseal 程序使用非對稱加密來對 secrets 進(jìn)行加密，且只有 controller 可以解密。這些加密的 secrets 被編碼到了 K8s 的 SealedSecret 資源中(可以保存到 Git 中)。

Capsule

很多公司使用多租戶來管理不同的客戶，這在軟件開發(fā)中很常見，但很難在 Kubernetes 中實現(xiàn)。一種方式是通過 命名空間 將集群劃分為獨立的邏輯分區(qū)，但無法完全隔離用戶，還需要引入網(wǎng)絡(luò)策略、配額等等。你可以在每個命名空間中創(chuàng)建網(wǎng)絡(luò)策略和規(guī)則，但這是一個讓人乏味的過程，且無法擴展，而且租戶無法使用多個命名空間，這是一個很大的限制。

分層命名空間^[34] 可以用來解決這些問題。方法是為每個租戶分配分配一個父命名空間，并為該租戶配置通用的網(wǎng)絡(luò)策略和配額，并允許創(chuàng)建子命名空間。這是一個很大的改進(jìn)，但在租戶層面，缺少安全性和治理方面的原生支持。此外，它還沒有達(dá)到生產(chǎn)狀態(tài)，但預(yù)計將在未來幾個月發(fā)布1.0版本。

一種常見的方式是為每個客戶創(chuàng)建一個集群，這樣做相對比較安全，并給租戶提供了所需的一切內(nèi)容，但這種方式很難管理，費用也很高。

Capsule^[35] 是一種在單個集群中為Kubernetes提供多租戶功能的工具。使用Capsule，你可以將所有租戶放到一個集群中。Capsul會為租戶提供一個"近乎"原生的體驗(雖然有一些小小的限制)，租戶可以在其集群中創(chuàng)建多個命名空間。這種方式隱藏了多租戶共享底層集群的事實。

在一個集群中，Capsule 控制器將多個命名空間聚合到一起，抽象為一個輕量級的 Kubernetes，稱為租戶，它是一組 Kubernetes 命名空間。在每個租戶中，用戶可以創(chuàng)建其命名空間并共享分配到的資源，Policy Engine 保證租戶間的隔離性。

網(wǎng)絡(luò)和安全策略、資源配額、LimitRanges、RBAC 和在租戶級別定義的其他策略由租戶中的所有命名空間自動繼承，類似于分層命名空間。然后，用戶可以自主地操作租戶，而無需集群管理員的干預(yù)。

Capsel 是 GitOps 的，因為它是聲明性的，所有的配置都可以存儲在 Git 中。

總結(jié)

在本文中，回顧了我最喜歡的 GitOps 的 Kubernetes 工具，我關(guān)注的是可以整合到任何 Kubernetes 發(fā)行版中的開源項目。通過 GitOps 的最佳實踐，你可以利用其聲明性特性在 Kubernetes 中做任何事情。

原文地址：https://itnext.io/kubernetes-gitops-tools-cf0247eb5368

參考資料