[[425421]]

簡介

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

作者撰寫本文的目標是描述用于不同軟件開發任務的生態工具，回答如何在Kubernetes環境中完成某個任務的問題。

K3D

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

替代方案

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

Lens

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

替代方案

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

Helm

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

替代方案

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

ArgoCD

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

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

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

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

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

在作者看來，Kubernetes中最好的GitOps工具是ArgoCD，他是Argo生態的一部分（Argo生態還包括其他的優秀工具，稍后還將討論提及）。ArgoCD功能支持用戶在代碼庫中存儲每一種環境，并為上述每個環境定義所有的配置，能夠在特定的目標環境內，自動部署所需的應用程序狀態。ArgoCD 技術架構如下圖所示：

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

替代方案

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

Argo WorkMows和Argo Events

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

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

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

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

替代方案

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

Kaniko

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

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

Istio

Istio是市面上著名和受歡迎的開源服務網格工具。無需細說服務網格的概念（這個話題很大）。如果用戶正在準備構建或正在構建微服務,且需要一個服務網格來管理服務通訊、服務可觀察性,錯誤處理,安全控制、以及微服務架構跨平面通信等功能。可以采用服務網格避免邏輯重復導致單個微服務的代碼污染。Istio的技術架構如下圖所示：

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

替代方案

Linkerd是一種更輕或更快的服務網格。Linkerd的初衷就是為了安全而研發，提供包括默認啟動mTLS、采用：

• Rust構建數據平面、采用內存安全語言以及定期安全審計等功能。
• Consul為任何運行時和云服務商構建的服務網格，非常適合跨K8s和公有云的混合部署。非常適合不是純Kubernetes負荷運行的組織。

Argo Rollouts

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

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

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

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

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

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

替代方案

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

Crossplane

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

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

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

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

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

替代方案

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

Knative

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

對于Kubernetes而言，如果用戶希望使用事件驅動架構運行函數即代碼應用，那么Knative將是在最佳選擇。Knative設計是在Pod之上創建一個抽象層，實現在Kubernetes中運行無服務器函數。它的主要功能包括：

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

替代方案

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

kyverno

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

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

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

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

替代方案

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

Kubevela

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

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

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

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

平臺團隊:將平臺能力當作組件或特性，與目標環境規范一起進行建模和管理。

應用團隊:選定一個環境，根據需求組裝應用的組件和特性，并將其部署到目標環境中。

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

替代方案

Shipa采用了類似的方法，使平臺和開發團隊能夠協同工作，實現將應用輕松地部署到K8s環境。

Snyk

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

替代方案

Falco是Kubernetes環境中的運行時安全線程檢測工具。

Velero

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

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

Schema Hero

軟件開發中的另一個常見過程是在使用關系數據庫時管理Schema的演化。Schema Hero是一個開源的數據庫Schema遷移工具，它能夠將Schema定義轉換為可以應用于任何環境的遷移腳本。它使用Kubernetes聲明性特性來管理數據庫Schema遷移。用戶只需指定所需的狀態，余下的工作都可以交由Schema Hero管理。

替代方案

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

Bitnami Sealed Secrets

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

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

Sealed Secrets就是解決這個問題的工具，它提供強加密能力，允許用戶將敏感數據存儲在Git中。Bitnami Sealed Secrets原生集成在K8s中，允許用戶只能通過Kubernetes中運行的控制器來解密密鑰。控制器將解密數據并創建安全存儲的原生K8S密鑰。這使得用戶能夠以代碼的方式存儲任意內容，并允許無需外部依賴就可以安全地執行持續部署。

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

替代方案

• SOPS是相對簡單的密鑰管理工具
• AWS Secret Manager
• Vault

Capsule

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

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

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

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

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

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

vCluster

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

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

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

其他工具

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

結論

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

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