Kubernetes必備工具（2021版）

作者：易理林翻譯 2021-09-24 09:59:54

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

創(chuàng)新互聯(lián)建站是一家集網(wǎng)站建設(shè),衡陽縣企業(yè)網(wǎng)站建設(shè),衡陽縣品牌網(wǎng)站建設(shè),網(wǎng)站定制,衡陽縣網(wǎng)站建設(shè)報(bào)價(jià),網(wǎng)絡(luò)營(yíng)銷,網(wǎng)絡(luò)優(yōu)化,衡陽縣網(wǎng)站推廣為一體的創(chuàng)新建站企業(yè)，幫助傳統(tǒng)企業(yè)提升企業(yè)形象加強(qiáng)企業(yè)競(jìng)爭(zhēng)力。可充分滿足這一群體相比中小企業(yè)更為豐富、高端、多元的互聯(lián)網(wǎng)需求。同時(shí)我們時(shí)刻保持專業(yè)、時(shí)尚、前沿，時(shí)刻以成就客戶成長(zhǎng)自我，堅(jiān)持不斷學(xué)習(xí)、思考、沉淀、凈化自己，讓我們?yōu)楦嗟钠髽I(yè)打造出實(shí)用型網(wǎng)站。

簡(jiǎn)介

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

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

K3D

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

替代方案

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

Lens

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

替代方案

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

Helm

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

替代方案

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

ArgoCD

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

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

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

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

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

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

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

替代方案

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

Argo WorkMows和Argo Events

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

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

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

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

替代方案

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

Kaniko

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

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

Istio

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

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

替代方案

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

Argo Rollouts

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

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

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

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

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

• 藍(lán)綠更新策略
• 金絲雀更新策略
• 細(xì)粒度與加權(quán)的軌跡切換
• 自動(dòng)更新與回滾、或人工判斷執(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)格工具，而不僅僅是一個(gè)過程交付工具。Istio不支持自動(dòng)部署，但可以通過與Argo rollout集成來實(shí)現(xiàn)。
• Flagger與Argo Rollouts非常相似，與Flux集成效果非常好，所以如果使用Flux，建議考慮Flagger.
• Spinnaker是首個(gè)Kubernetes持續(xù)交付工具，具備豐富的功能，但使用和配置比較復(fù)雜。

Crossplane

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

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

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

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

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

替代方案

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

Knative

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

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

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

替代方案

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

kyverno

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

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

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

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

替代方案

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

Kubevela

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

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

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

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

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

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

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

替代方案

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

Snyk

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

替代方案

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

Velero

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

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

Schema Hero

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

替代方案

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

Bitnami Sealed Secrets

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

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

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

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

替代方案

• SOPS是相對(duì)簡(jiǎn)單的密鑰管理工具

• AWS Secret Manager

• Vault

Capsule

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

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

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

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

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

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

vCluster

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

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

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

其他工具

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

結(jié)論

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

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

文章標(biāo)題：Kubernetes必備工具（2021版）
標(biāo)題網(wǎng)址：http://m.fisionsoft.com.cn/article/cohggso.html