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

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

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

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

什么是 GitOps？

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

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

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

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

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

Kubernetes 中的 Gitops

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

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

聲明式 GitOps 工具

如果考慮 Kubernetes 上的 GitOps，就需要討論那些在 Kubernetes 上實(shí)現(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ù)會(huì)進(jìn)行討論。

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

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

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

Flux

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

GitOps 工具

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

helm

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

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

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

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

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

Argo Workflows 和 Argo Events

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

雖然它們是獨(dú)立的項(xiàng)目，但趨向于部署到一起。

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

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

上述兩種工具為需要 CI/CD 流水線提供了簡(jiǎn)單且強(qiáng)大的解決方案，可以在 Kubernetes 上運(yùn)行 CI/CD 流水線。

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

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

對(duì)于 CI/CD 流水線，可以使用 Tekton[17] 。

Istio

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

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

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

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

Argo Rollouts

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

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

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

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

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

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

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

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

Crossplane

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

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

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

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

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

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

Kyverno

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

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

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

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

Kubevela

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

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

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

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

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

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

Schema Hero

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

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

Bitnami Sealed Secrets

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

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

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

Sealed Secrets 包含兩部分：

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

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

Capsule

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

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

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

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

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

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

Capsel 是 GitOps 的，因?yàn)樗锹暶餍缘?，所有的配置都可以存?chǔ)在 Git 中。