簡介

本文嘗試歸納一下最新和比較少見的Kubernetes生態(tài)工具，也是作者很喜歡和具備潛力的Kubernetes工具清單。由于所羅列的工具是基于個人的經(jīng)驗，所以為避免偏見和誤導(dǎo)，本文為每個工具提供了替代方案，讓讀者可以根據(jù)自己的需求進行比選。

[[425426]]

作者撰寫本文的目標(biāo)是描述用于不同軟件開發(fā)任務(wù)的生態(tài)工具，回答如何在Kubernetes環(huán)境中完成某個任務(wù)的問題。

K3D

K3D是作者在筆記本電腦上運行Kubernetes(K8S)集群的最優(yōu)選方式。它使用Docker部署K3S包，非常輕量級和快速。運行只需要Docker環(huán)境，資源消耗非常低，唯一不足就是不完全兼容K8s，但對于本地開發(fā)而言，基本不是問題。如果是用于測試環(huán)境，建議使用kind等其他的解決方案。Kind完全兼容K8s , 但運行速度不及K3D。

替代方案

• IoT K3S或邊緣K3S
• 全兼容K8S的Kind
• MicroK8S
• MiniKube
• *## Krew ##
• Krew是管理Kubectl插件的重要工具，可能是所有k8用戶的必用工具。Krew支持管理145個以上的生態(tài)插件，常見的應(yīng)用是安裝和管理kubens和kubectx插件。

Lens

Lens是面向K8s的SRE工程師, Ops工程師和軟件開發(fā)人員的集成開發(fā)環(huán)境?？梢赃m用于所有的Kubernetes發(fā)行版，包括物理部署和云端部署的環(huán)境。Lens具備快速，易用和實時可觀察性的特性。能夠輕易地管理多個集群，是多集群運維人員的必須工具。

替代方案

對于偏愛輕量級終端的人來說，K9s是很好的選擇,提供Kubernetes變化的持續(xù)監(jiān)視功能，并提供與觀察資源對象進行交互的操作指令。

Helm

無須多言，Helm是Kubernetes最著名的包管理器，提供等同于使用編程語言的效果，Helm支持將應(yīng)用打包到Charts中，從而實現(xiàn)將復(fù)雜的應(yīng)用程序抽象為可重用的簡單組件，易于定義、安裝和更新。Helm非常成熟、易于使用，提供強大的模板引擎，內(nèi)置大量的預(yù)定義Charts、以及具備有力的技術(shù)支持服務(wù)。

替代方案

Kustomize是一個新興和潛力的Helm替代工具，它不使用模板引擎，而是在用戶基礎(chǔ)定義之上，構(gòu)建一個疊加的引擎，實現(xiàn)與模板引擎相同的功能。

ArgoCD

我認(rèn)為GitOps是過去十年中的最佳創(chuàng)意之一。在軟件開發(fā)中，我們需要使用單一的可信源來跟蹤構(gòu)建軟件所需的所有動態(tài)組件，而Git是解決這個需求的完美工具。其想法是提供一個Git庫，存儲內(nèi)容包含了應(yīng)用程序代碼和所需生產(chǎn)環(huán)境狀態(tài)的基礎(chǔ)設(shè)施(IaC)聲明性描述,以及使環(huán)境匹配到要求狀態(tài)的自動化過程。

GitOps:基于聲明式基礎(chǔ)設(shè)施的版本化CI/CD。棄用腳本，開啟交付。 ——Kelsey Hightower

盡管可以使用Terraform或類似的工具實現(xiàn)基礎(chǔ)設(shè)施即代碼(IaC)。但還不能夠在生產(chǎn)Git中，實現(xiàn)所期望的狀態(tài)同步。需要一種方法持續(xù)監(jiān)控環(huán)境，并確保不會出現(xiàn)配置漂移。使用Terraform工具時，用戶須編寫腳本來運行生產(chǎn)環(huán)境的狀態(tài)檢查，并檢查是否與Terraform的配置狀態(tài)相匹配，但這種方式乏味，且難以維護的。

Kubernetes是基于全過程控制環(huán)的思想構(gòu)建，意味著Kubernetes能夠全天候監(jiān)視集群的狀態(tài)，以確保它處于預(yù)期的狀態(tài)。例如，K8s實際運行的副本數(shù)就等于配置的副本數(shù)量。GitOps思路還將這種模式延伸到應(yīng)用程序，實現(xiàn)支持用戶將服務(wù)定義為代碼。例如，通過定義Helm Charts，并使用某個工具利用k8的功能來監(jiān)控應(yīng)用程序的狀態(tài)，并相應(yīng)地調(diào)整集群狀態(tài)。換句話說，如果更新了代碼庫或helm chart，生產(chǎn)集群也能夠相應(yīng)地自動更新，做到真正的持續(xù)部署。

應(yīng)用部署和應(yīng)用全生命周期管理的核心原則就應(yīng)該是自動化、可審計和易于理解。作者認(rèn)為這是個具備變革性的想法，如果實現(xiàn)得當(dāng)，將會使企業(yè)更多地關(guān)注業(yè)務(wù)功能，較少地考慮自動化腳本編寫，這個概念還可以延伸到軟件開發(fā)的其他領(lǐng)域，例如，您可以在代碼中包含開發(fā)文檔，實現(xiàn)文檔的歷史變更跟蹤和文檔及時更新，或者使用ADRs來跟蹤架構(gòu)決策。

在作者看來，Kubernetes中最好的GitOps工具是ArgoCD，他是Argo生態(tài)的一部分(Argo生態(tài)還包括其他的優(yōu)秀工具，稍后還將討論提及)。ArgoCD功能支持用戶在代碼庫中存儲每一種環(huán)境，并為上述每個環(huán)境定義所有的配置，能夠在特定的目標(biāo)環(huán)境內(nèi)，自動部署所需的應(yīng)用程序狀態(tài)。ArgoCD 技術(shù)架構(gòu)如下圖所示：

ArgoCD的運行實現(xiàn)類似于kubernetes控制器，它持續(xù)監(jiān)控正在運行的應(yīng)用程序，并執(zhí)行實時狀態(tài)與期望狀態(tài)的對比(配置存儲在Git庫)。Argo CD提供狀態(tài)差異的報告和可視化展示，并支持自動或手動將應(yīng)用狀態(tài)同步為預(yù)期狀態(tài)。

替代方案

• Flux 最新發(fā)布的版本有很多的改進，提供了非常相似的功能。

Argo WorkMows和Argo Events

Kubernetes環(huán)境存在批處理作業(yè)或復(fù)雜工作流程的運行需要，應(yīng)用場景可能是數(shù)據(jù)管道、異步進程或CI/CD的部分或全部。除此之外，可能還需要運行基于事件驅(qū)動的微服務(wù)，來響應(yīng)某些事件。例如文件上傳或向消息隊列發(fā)送消息等。對于上述需求，可以采用Argo WorkMows和Argo Events工具。盡管是2個獨立的項目，但實際使用中，經(jīng)常成對部署應(yīng)用。

Argo WorkMows是類似于Apache AirFlow的編排引擎，是Kubernetes的原生引擎工具。它使用自定義的CRD,采用分步配置或原生YAML有向無環(huán)圖來定義復(fù)雜的WorkMows。它提供了友好的用戶界面、重試機制、計劃性作業(yè)、輸入和輸出跟蹤等功能，支撐用戶編排數(shù)據(jù)管道、批處理作業(yè)等。

用戶有時可能想將自有的應(yīng)用管道與Kafka流引擎、消息隊列、webhook或者深度存儲服務(wù)等異步服務(wù)整合應(yīng)用。例如對S3文件上傳事件作出反應(yīng)。為此可以使用Argo Events。

上述兩種工具的結(jié)合為用戶CI/CD在內(nèi)的所有管道需求，提供了一個簡單而強大的解決方案，允許用戶在Kubernetes環(huán)境中原生地運行CI/CD管道。

替代方案

• KubeMow，適用于ML目的的管道
• Tekton，適用于CI/CD 管道

Kaniko

前面提到如何使用Argo WorkMows在Kubernetes環(huán)境中運行原生的CI/CD管道，其中一個常見任務(wù)是構(gòu)建Docker映像，這在Kubernetes中的構(gòu)建過程實際上就是使用宿主機的Docker引擎運行容器鏡像本身，過程非常乏味。

使用Kaniko的基本原則是用戶必須使用Kaniko，而不是Docker構(gòu)建鏡像。Kaniko不依賴于Docker守護進程，完全是在用戶空間根據(jù)Dockerfile的內(nèi)容逐行執(zhí)行命令來構(gòu)建鏡像。這就使得在一些無法安全，快速獲取 docker進程環(huán)境下(例如標(biāo)準(zhǔn)的Kubernetes Cluster)也能夠構(gòu)建容器鏡像。同時，Kaniko消除了在K8S集群中構(gòu)建映像的所有問題。

Istio

Istio是市面上最著名和受歡迎的開源服務(wù)網(wǎng)格工具。無需細(xì)說服務(wù)網(wǎng)格的概念(這個話題很大)。如果用戶正在準(zhǔn)備構(gòu)建或正在構(gòu)建微服務(wù),且需要一個服務(wù)網(wǎng)格來管理服務(wù)通訊、服務(wù)可觀察性,錯誤處理,安全控制、以及微服務(wù)架構(gòu)跨平面通信等功能?？梢圆捎梅?wù)網(wǎng)格避免邏輯重復(fù)導(dǎo)致單個微服務(wù)的代碼污染。Istio的技術(shù)架構(gòu)如下圖所示：

簡而言之，服務(wù)網(wǎng)格是一個可以添加到應(yīng)用程序中的專用基礎(chǔ)設(shè)施層。它允許用戶在無需編寫代碼的情況下，可以透明地添加可觀察性、流量管理和安全性等功能。對于具備熟練運行Istio和使用Istio運行微服務(wù)的用戶，Kubernetes已經(jīng)多次被證明是最佳的運行平臺。Istio還可以將k8s集群擴展到VM等其他服務(wù)環(huán)境，為用戶構(gòu)建混合環(huán)境，有利于用戶將應(yīng)用遷移到Kubernetes。

替代方案

• Linkerd是一種更輕或更快的服務(wù)網(wǎng)格。Linkerd的初衷就是為了安全而研發(fā)，提供包括默認(rèn)啟動mTLS、采用
• Rust構(gòu)建數(shù)據(jù)平面、采用內(nèi)存安全語言以及定期安全審計等功能。
• Consul為任何運行時和云服務(wù)商構(gòu)建的服務(wù)網(wǎng)格，非常適合跨K8s和公有云的混合部署。非常適合不是純Kubernetes負(fù)荷運行的組織。

Argo Rollouts

如前文所述，在Kubernetes環(huán)境中，我們可以使用Argo WorkMows或類似工具來運行CI/CD管道，使用Kaniko來構(gòu)建容器映像。而接下來的邏輯步驟是繼續(xù)進行持續(xù)部署。接下來的步驟在現(xiàn)實場景下由于風(fēng)險高而是極具挑戰(zhàn)性。這也是大多數(shù)公司止步于持續(xù)交付的主要原因，同時也意味著這些公司具有自動化,手工審批和手工校驗的過程步驟，導(dǎo)致現(xiàn)狀的原因主要是團隊還不完全信任他們的自動化。

那么如何建立必要的信任，從而擺脫所有的手工腳本，實現(xiàn)從源代碼到生產(chǎn)部署的完全自動化呢?答案是:可觀察性。需要投入更多的資源集中在指標(biāo)觀測上，并收集能夠準(zhǔn)確表示應(yīng)用狀態(tài)的所有數(shù)據(jù)，達到通過一系列指標(biāo)來建立信任的目的。假設(shè)在Prometheus中擁有所有的指標(biāo)數(shù)據(jù)，那么就可以基于這些指標(biāo)數(shù)據(jù)開展應(yīng)用程序的逐步自動化推出，實現(xiàn)應(yīng)用程序的自動化部署。

簡而言之， K8S提供了開箱即用的滾動更新(Rolling Updates)技術(shù)，如果需要比這個更高級的部署技術(shù)，就需要使用金絲雀部署逐步交付，即逐步將流量切換到新版本的應(yīng)用，然后采集指標(biāo)數(shù)據(jù)并分析，與預(yù)定義的規(guī)則進行匹配，如果一切都正常的話，就可以切換更多的流量，如果有任何問題就回滾部署。

在Kubernetes中，Argo Rollouts提供了金絲雀部署和更多的其他功能。內(nèi)置了Kubernetes控制器和一系統(tǒng)CRD，提供Kubernetes漸進式交付的藍綠部署、金絲雀部署、金絲雀分析、部署實驗等高級部署功能。

雖然像Istio這樣的服務(wù)網(wǎng)格也提供金絲雀發(fā)布功能，但是Argo rollout是專門為此目的而構(gòu)建的，發(fā)布過程更加簡化，并以開發(fā)人員為中心。最重要的是Argo Rollouts可以與任何服務(wù)網(wǎng)格集成。所提供的功能包括：

• 藍綠更新策略
• 金絲雀更新策略
• 細(xì)粒度與加權(quán)的軌跡切換
• 自動更新與回滾、或人工判斷執(zhí)行
• 自定義指標(biāo)查詢和業(yè)務(wù)KPI分析
• 入口控制器支持集成NGINX, ALB等
• 服務(wù)網(wǎng)格支持集成Istio, Linkerd, SMI等
• 量化指標(biāo)來源集成包括Prometheus, Wavefront, Kayenta, Web, Kubernetes Jobs等

替代方案

• Istio是具備金絲雀發(fā)布功能的服務(wù)網(wǎng)格工具，而不僅僅是一個過程交付工具。Istio不支持自動部署，但可以通過與Argo rollout集成來實現(xiàn)。
• Flagger與Argo Rollouts非常相似，與Flux集成效果非常好，所以如果使用Flux，建議考慮Flagger.
• Spinnaker是首個Kubernetes持續(xù)交付工具，具備豐富的功能，但使用和配置比較復(fù)雜。

Crossplane

Crossplane是作者最喜歡和關(guān)注的k8s生態(tài)項目，它實現(xiàn)了將第三方服務(wù)當(dāng)作K8S資源來管理，為K8s補全了關(guān)鍵的一塊能力。這意味著用戶可以在K8s內(nèi)使用YAML定義公有云數(shù)據(jù)庫，如AWS RDS或GCP cloud SQL等。

通過Crossplane工具，用戶就不需要使用不同的工具和方法學(xué)來隔離基礎(chǔ)設(shè)施和代碼，可以將任意外部服務(wù)定義為K8s的資源，且不需要再刻意學(xué)習(xí)使用和單獨部署Terraform等工具。

Crossplane是一個開源的Kubernetes插件，它允許平臺團隊封裝來自多個供應(yīng)商的基礎(chǔ)設(shè)施，并向應(yīng)用團隊開放更高級別的自服務(wù)API，而無需編寫任何代碼。

Crossplane擴展了Kubernetes集群的功能，提供管理任意基礎(chǔ)設(shè)施或云服務(wù)的CDR。此外，與Terraform等其他工具相反，Crossplane使用現(xiàn)有K8s的控制環(huán)等已有功能來持續(xù)監(jiān)視集群，并自動檢測運行時的配置漂移，從而實現(xiàn)完整的持續(xù)部署。例如，如果用戶定義了一個托管數(shù)據(jù)庫實例，但被其他用戶手動更改了配置，Crossplane將自動檢測該事件并將執(zhí)行配置回滾操作。這個過程也鞏固了基礎(chǔ)設(shè)施即代碼和GitOps的原則。

Crossplane與Argo CD集成非常好，即可以監(jiān)控源代碼，又確保代碼庫的唯一可信，代碼中的任何變更都將同步到集群和外部云服務(wù)。沒有Crossplane，用戶只能在K8s中部署GitOps，而不能跨K8s和公有云共享使用。

替代方案

• Terraform是最著名的IaC工具，但它不是K8s生態(tài)的原生工具，對用戶有額外的技能要求，且不具備配置漂移的自動監(jiān)控功能。
• Pulumi是Terraform的一個替代方案，運行的編程語言可以被開發(fā)人員測試和理解。

Knative

如果用戶在公有云開發(fā)應(yīng)用程序，可能使用了某些無服務(wù)器計算技術(shù)，比如事件驅(qū)動范式FaaS的AWS Lambda等。以往我們已經(jīng)討論過無服務(wù)器計算，所以此處不再贅述概念。但使用無服務(wù)器計算的問題在于它與公有云是緊密耦合的，因為公有云可以因此構(gòu)建一個事件驅(qū)動應(yīng)用的巨大的生態(tài)。

對于Kubernetes而言，如果用戶希望使用事件驅(qū)動架構(gòu)運行函數(shù)即代碼應(yīng)用，那么Knative將是在最佳選擇。Knative設(shè)計是在Pod之上創(chuàng)建一個抽象層，實現(xiàn)在Kubernetes中運行無服務(wù)器函數(shù)。它的主要功能包括：

• 為通用應(yīng)用用例提供更高層次的抽象API
• 提供可擴展、安全、無狀態(tài)的秒級函數(shù)服務(wù)
• 采用功能松耦合架構(gòu)，支持按需使用
• 具備組件可插拔，支持用戶使用外部日志和監(jiān)控，網(wǎng)絡(luò)，和服務(wù)網(wǎng)格工具
• 具備組件可移植，能夠在任意Kubernetes環(huán)境中運行，無需擔(dān)心廠商鎖定
• 繼承通用開發(fā)理念，支持GitOps, DockerOps, ManualOps等通用模式 兼容Django、Ruby on Rails、Spring等通用開發(fā)工具和框架

替代方案

• argo Events為Kubernetes提供了一個事件驅(qū)動的工作流引擎，支持與AWS Lambda等云引擎集成。雖然不是FaaS，但為Kubernetes提供了一個事件驅(qū)動架構(gòu)
• OpenFaas

kyverno

Kubernetes為敏捷自治團隊提供了強大的靈活性。但權(quán)力越大，責(zé)任越大，K8s必須有一系列的最佳實踐和規(guī)則，以確保以始終一致和高度內(nèi)聚的方式部署和管理工作負(fù)載，并確保這種方式符合公司的策略和安全規(guī)范。

在Kyverno出現(xiàn)之前，雖然有一些工具可以實現(xiàn)上述要求，但都不是Kubernetes的原生工具。Kyverno是為K8s生態(tài)而設(shè)計的策略引擎，策略被定義為K8s的一種資源，不需要新的語言來編寫策略。Kyverno具備對策略進行驗證、演化和生成Kubernetes資源的功能。

Kyverno策略是一組規(guī)則。每個規(guī)則由一個match子句、一個可選的exclude子句和一個validate、mutate或generate子句組成。規(guī)則定義只能包含單個validate、mutation或generate子節(jié)點。

用戶可以使用與最佳實踐、網(wǎng)絡(luò)或安全等相關(guān)的任何類型策略。例如，強制要求所有服務(wù)都具有標(biāo)簽，或者所有容器都必須為非根運行。用戶可以查看策略用例，并將策略應(yīng)用于整個集群或指定的命名空間，還可以選擇是否審計策略或強制阻止用戶部署資源等。

替代方案

Open Policy Agent是一種著名的云原生策略控制引擎。采用自有的聲明性語言，并可以應(yīng)用于許多環(huán)境，而不僅僅是在K8s。功能比Kyverno更強大，但管理難度也更大。

Kubevela

使用K8s的一個問題是開發(fā)人員需要非常清楚地了解平臺和集群的配置。許多用戶可能會認(rèn)為K8s的抽象級別太低，以至于給專注于編寫和發(fā)布應(yīng)用的開發(fā)人員，帶來了很多工作協(xié)同的摩擦。

開放應(yīng)用程序模型(OAM)就是解決這個問題而生的，其設(shè)計思想是屏蔽底層運行時，為應(yīng)用程序創(chuàng)建更高級的抽象。

相對于容器或容器編排，開放應(yīng)用模型[OAM]專注于應(yīng)用程序，為應(yīng)用部署帶來了模塊化、可擴展和可移植的設(shè)計，并提供更高級別的API。

Kubevela是OAM模型的一種功能實現(xiàn)。核心理念是以應(yīng)用為中心，對運行時沒有要求，具備原生可擴展性。在Kubevela中，應(yīng)用被定義為K8s的一種資源，具備最高的部署優(yōu)先權(quán)。應(yīng)用部署對于集群操作員(平臺團隊)和開發(fā)人員(應(yīng)用團隊)存在不同的內(nèi)涵，集群操作員是通過定義組件(類似于helm chart的可部署/可定義的實體)和特性來管理集群和不同的環(huán)境;開發(fā)人員是通過組裝組件和特性來定義應(yīng)用程序。

平臺團隊:將平臺能力當(dāng)作組件或特性，與目標(biāo)環(huán)境規(guī)范一起進行建模和管理。

應(yīng)用團隊:選定一個環(huán)境，根據(jù)需求組裝應(yīng)用的組件和特性，并將其部署到目標(biāo)環(huán)境中。

KubeVela是云原生計算基金會的沙盒項目，目前處于起步階段，但在不久的將來，很可能改變我們使用K8s的方式，可以讓開發(fā)人員專注于應(yīng)用開發(fā)，而不必是Kubernetes專家。然而，對于OAM在現(xiàn)實世界中的適用性，也確實存在一些隱憂，對于像系統(tǒng)軟件、ML或大數(shù)據(jù)處理等服務(wù)，存在很大程度的底層細(xì)節(jié)依賴，而這些細(xì)節(jié)可能很難納入到OAM模型。

替代方案

Shipa采用了類似的方法，使平臺和開發(fā)團隊能夠協(xié)同工作，實現(xiàn)將應(yīng)用輕松地部署到K8s環(huán)境。

Snyk

安全在任何軟件開發(fā)過程中，都是非常重要的方面。由于遷移應(yīng)用到K8s的用戶單位難以在K8s環(huán)境部署已有的安全原則，使得安全成為k8s的一大痛點。Snyk是可以與Kubernetes輕易集成的安全框架，能夠檢測容器映像、代碼、開源項目等組件的漏洞。從而試圖緩解K8s的安全問題，

替代方案

Falco是Kubernetes環(huán)境中的運行時安全線程檢測工具。

Velero

如果在Kubernetes中運行工作負(fù)載，并使用存儲卷來存儲數(shù)據(jù)，則需要創(chuàng)建和管理數(shù)據(jù)備份。Velero提供了簡單的備份/恢復(fù)流程、容災(zāi)恢復(fù)機制和數(shù)據(jù)遷移等功能。

與直接訪問Kubernetes ETCD庫來執(zhí)行備份和恢復(fù)的其他工具不同，Velero使用Kubernetes API來捕獲集群資源的狀態(tài)，并在必要時進行恢復(fù)。此外，Velero允許用戶在執(zhí)行軟件配置的同時備份和恢復(fù)應(yīng)用程序的持久數(shù)據(jù)。

Schema Hero

軟件開發(fā)中的另一個常見過程是在使用關(guān)系數(shù)據(jù)庫時管理Schema的演化。Schema Hero是一個開源的數(shù)據(jù)庫Schema遷移工具，它能夠?qū)chema定義轉(zhuǎn)換為可以應(yīng)用于任何環(huán)境的遷移腳本。它使用Kubernetes聲明性特性來管理數(shù)據(jù)庫Schema遷移。用戶只需指定所需的狀態(tài)，余下的工作都可以交由Schema Hero管理。

替代方案

LiquidBase是最著名的替代方案，功能強大，但不是Kubernetes的原生工具，且操作困難。

Bitnami Sealed Secrets

我們已經(jīng)介紹了包括ArgoCD在內(nèi)的多款GitOps工具。這些工具的設(shè)計目標(biāo)都是設(shè)計將所有內(nèi)容保存在Git庫中，并能夠使用原生的Kubernetes聲明來保持與環(huán)境的同步。如前所述，ArgoCD工具保證了Git中源代碼的可靠性，并提供自動化進程來處理配置變更。

但是在Git中存儲如數(shù)據(jù)庫密碼或API密鑰之類的密鑰，通常都非常困難。因為用戶不應(yīng)該在代碼庫中包含秘鑰信息。一種常見的解決方案是使用外部保險庫(如AWS Secret Manager或HashiCorp)來存儲密鑰，但這種解決方案會帶來額外獨立線程處理密鑰的不便需求。理想情況下，應(yīng)該有一種方式可以在Git中安全地存儲密鑰，就像管理其他類型的任何資源一樣。

Sealed Secrets就是解決這個問題的工具，它提供強加密能力，允許用戶將敏感數(shù)據(jù)存儲在Git中。Bitnami Sealed Secrets原生集成在K8s中，允許用戶只能通過Kubernetes中運行的控制器來解密密鑰?？刂破鲗⒔饷軘?shù)據(jù)并創(chuàng)建安全存儲的原生K8S密鑰。這使得用戶能夠以代碼的方式存儲任意內(nèi)容，并允許無需外部依賴就可以安全地執(zhí)行持續(xù)部署。

Sealed Secrets由兩部分組成:客戶側(cè)控制器和客戶側(cè)應(yīng)用Kubeseal。采用非對稱加密來加密密鑰，并且只有控制器可以解密。而加密的密鑰被封裝成K8S資源，可以將其存儲在Git中。

替代方案

• SOPS是相對簡單的密鑰管理工具

• AWS Secret Manager

• Vault

Capsule

許多公司使用多租戶來管理不同的客戶，這在軟件開發(fā)設(shè)計中很常見，但在Kubernetes中卻很難實現(xiàn)。命名空間是利用邏輯分區(qū)創(chuàng)建集群內(nèi)獨立分片的一種好方法，但還不足以安全地隔離用戶。還需要強制網(wǎng)絡(luò)策略、配額等功能。用戶可以為每個命名空間創(chuàng)建網(wǎng)絡(luò)策略和規(guī)則，但過程冗長且難以擴展。此外，租戶有一個關(guān)鍵限制即不能跨越命名空間使用。

創(chuàng)建分層繼承名稱空間就是為了克服上述部分問題。其設(shè)計思路是為每個租戶構(gòu)建一個父命名空間，提供通用的網(wǎng)絡(luò)策略和配額，并允許在此基礎(chǔ)上創(chuàng)建子命名空間。這是一個巨大的改進，但在租戶安全性和治理方面沒有原生的技術(shù)支持，功能還沒有達到生產(chǎn)狀態(tài)，預(yù)計1.0版本有望在下個月發(fā)布。

目前解決這個問題的另一種常用方法是為每個客戶創(chuàng)建一個集群，這既保證了安全，又為租戶提供了所需的一切，但帶來了管理困難和高成本。

Capsule是原生支持K8s單集群多個租戶管理的工具。通過使用Capsule，用戶可以將所有租戶創(chuàng)建在同一個集群。Capsule為租戶提供近似乎原生的體驗(僅有一些較小的限制)，通過隱藏集群共享的底層特征，讓租戶能夠在單集群內(nèi)創(chuàng)建多個命名空間并完整地使用集群資源。

在單個集群中，Capsule控制器在一個輕量級Kubernetes抽象(租戶)中聚合了多個命名空間，即一組Kubernetes命名空間。在每個租戶中，用戶可以自由創(chuàng)建自己的名稱空間，并共享所分配的資源，由策略引擎保證不同租戶之間的隔離。

類似于“分級命名空間”的運作機制，租戶級的“網(wǎng)絡(luò)與安全策略”、“資源配額”、“限制范圍”、“RBAC”等策略定義，會自動被租戶內(nèi)的所有命名空間繼承。這樣，用戶可以無需集群管理員的干預(yù)，自由地管理所屬的租戶。由于Capsule的聲明性，以及所有的配置都存儲在Git中，因此Capsule原生具備GitOps特征。

vCluster

VCluster在多租戶管理方面更加深入，它能夠在Kubernetes集群中創(chuàng)建虛擬集群環(huán)境，每個虛擬集群運行在一個常規(guī)的命名空間內(nèi)，具備完全隔離性。虛擬集群提供自有的API服務(wù)和獨立的數(shù)據(jù)存儲，因此在虛擬集群中創(chuàng)建的每個K8s對象只存在于所運行的虛擬集群中。此外，用戶可以像操作常規(guī)的K8s集群一樣，在虛擬集群中使用kube上下文指令。

類似于在單個名稱空間中創(chuàng)建部署，用戶可以創(chuàng)建虛擬集群，并成為集群管理員，而集群租戶可以創(chuàng)建命名空間、安裝CRD、配置權(quán)限等等。

建議vCluster使用k3s作為它的API服務(wù)器，使得虛擬集群具備超輕量級和高效費比能力，且由于k3s集群100%兼容K8s，虛擬集群自然也是100%兼容。超級輕量級 (1 pod)的能力讓用戶只需要消耗很少的資源，便可在任何Kubernetes集群上運行，而不需要有訪問底層集群的權(quán)限。與Capsule相比，vCluster消耗了更多一些的資源，但它提供了更多的靈活性，多租戶只是其具備的用例之一。

其他工具

• Kube-burner用于壓力測試。它提供指標(biāo)監(jiān)控和警報。 Litmus用于混沌引擎
• Kubewatch用于監(jiān)控，但主要聚焦于Kubernetes事件(如資源創(chuàng)建或刪除)的消息通知推送。支持與Slack等許多工具集成
• Botkube是一個用于監(jiān)視和調(diào)試Kubernetes集群的消息機器人。類似于kubewatch，但更新并具有更多的功能
• Mizu是一個API流量的查看器和調(diào)試器
• Kube-medged是Kubernetes的附加組件，用于在Kubernetes集群的工作節(jié)點上直接創(chuàng)建和管理容器映像的緩存。因此，不需要從鏡像庫獲取映像，應(yīng)用Pod可以即時啟動。

結(jié)論

本文回顧了作者喜歡的Kubernetes生態(tài)工具。作者關(guān)注能夠合并到任何Kubernetes發(fā)行版中的開源項目。鑒于內(nèi)容通用性考慮，本文沒有涉及介紹OpenShift或云供應(yīng)商Add-Ons等商業(yè)解決方案。但如果用戶在公有云上運行了Kubernete環(huán)境或使用商業(yè)工具，那鼓勵用戶積極探索云的潛能。

作者本文的目標(biāo)是向用戶展示，用戶在私有化部署Kubernetes環(huán)境中可以做到的事情。同時，作者也關(guān)注了一些不太知名，具備潛力的工具，比如Crossplane、Argo Rollouts或Kubevela。尤其對vCluster、Crossplane和ArgoCD/WorkMows等工具充滿興趣。