关于云计算:Kubernetes-必备工具2021

有别于前些天的文章 – 罕用的几款工具让 Kubernetes 集群上的工作更容易 偏重于工具类来晋升工作效率，明天这篇文章更加适宜用来做选型时的参考。

文档翻译自 Kubernetes Essential Tools: 2021，篇幅较长，做了局部增删。

介绍

在本文中，我将尝试总结我最喜爱的 Kubernetes 工具，并特别强调最新的和鲜为人知但我认为会十分风行的工具。

这只是我依据我的教训得出的集体清单，但为了防止偏见，我还将尝试提及每种工具的代替计划，以便你能够依据本人的须要进行比拟和决定。我将尽可能缩短这篇文章并提供链接，以便你能够自行摸索更多内容。我的指标是答复这个问题：“我如何在 Kubernetes 中做 X？”通过形容不同软件开发工作的工具。

K3D

K3D 是我最喜爱的在笔记本电脑上运行 Kubernetes (K8s) 集群的形式。它十分 笨重且 速度十分快。它是应用 Docker 围绕 K3S 的包装器。所以，你只须要 Docker 来运行它并且资源使用率非常低。惟一的问题是 它不完全符合 K8s 规范，但这不应该是本地开发的问题。对于测试环境，你能够应用其余解决方案。K3D 比 Kind 快，但 Kind 齐全兼容。

备选

• K3S 物联网或者边缘计算
• Kind 齐全兼容 Kubernetes 的备选
• MicroK8s
• MiniKube

Krew

Krew 是治理的必备工具 Kubectl 插件，这是一个必须有任何 K8S 用户。我不会具体介绍超过 145 个可用插件，但至多装置 kubens 和 kubectx。

Lens

Lens 是实用于 SRE、Ops 和开发人员的 K8s IDE。它实用于任何 Kubernetes 发行版：本地或云端。它疾速、易于应用并提供实时可察看性。应用 Lens 能够十分轻松地治理多个集群。如果你是集群操作员，这是必须的。

备选

• 对于那些喜爱轻量级终端替代品的人来说，K9s 是一个很好的抉择。K9s 会继续察看 Kubernetes 的变动，并提供后续命令来与你察看到的资源进行交互。

Helm

Helm 不须要介绍，它是 Kubernetes 最驰名的包管理器。你应该在 K8s 中应用包管理器，就像在编程语言中应用它一样。Helm 容许你将应用程序打包到 Charts 中，将简单的应用程序形象为易于定义、装置和更新的可重用简略组件。

它还提供了弱小的模板引擎。Helm 很成熟，有很多预约义的 charts，很好的反对，而且很容易应用。

备选

• Kustomize 是 helm 的一个更新和平凡的替代品，它不应用模板引擎，而是一个笼罩引擎，在其中你有根本的定义和笼罩在它们之上。

ArgoCD

我置信 GitOps 是过来十年中最好的想法之一。在软件开发中，咱们应该应用繁多的事实起源来跟踪构建软件所需的所有挪动局部，而 Git 是做到这一点的完满工具。咱们的想法是领有一个 Git 存储库，其中蕴含利用程序代码以及示意所需生产环境状态的基础设施 (IaC) 的申明性形容；以及使所需环境与存储库中形容的状态相匹配的自动化过程。

GitOps: versioned CI/CD on top of declarative infrastructure. Stop scripting and start shipping.

— Kelsey Hightower

只管应用 Terraform 或相似工具，你能够实现基础设施即代码（IaC），但这还不足以将你在 Git 中的所需状态与生产同步。咱们须要一种办法来继续监控环境并确保没有配置漂移。应用 Terraform，你将不得不编写脚本来运行 terraform apply 并查看状态是否与 Terraform 状态匹配，但这既乏味又难以保护。

Kubernetes 从头开始​​构建管制循环的思维，这意味着 Kubernetes 始终在监督集群的状态以确保它与所需的状态匹配，例如，运行的正本数量与所需的数量相匹配复制品。GitOps 的想法是将其扩大到应用程序，因而你能够将你的服务定义为代码，例如，通过定义 Helm Charts，并应用利用 K8s 性能的工具来监控你的应用程序的状态并相应地调整集群。也就是说，如果更新你的代码存储库或 Helm Chart，生产集群也会更新。这是真正的继续部署。外围准则是应用程序部署和生命周期治理应该自动化、可审计且易于了解。

对我来说，这个想法是革命性的，如果做得好，将使组织可能更多地关注性能，而不是编写自动化脚本。这个概念能够扩大到软件开发的其余畛域，例如，你能够将文档存储在代码中以跟踪更改的历史并确保文档是最新的；或应用 ADR 跟踪架构决策。

在我看来，在最好的 GitOps 工具 Kubernetes 是 ArgoCD。你能够在此处浏览更多信息。ArgoCD 是 Argo 生态系统的一部分，其中包含一些其余很棒的工具，其中一些咱们将在稍后探讨。

应用 ArgoCD，你能够在代码存储库中领有每个环境，你能够在其中定义该环境的所有配置。Argo CD 在指定的指标环境中主动部署所需的应用程序状态。

ArgoCD 被实现为一个 kubernetes 控制器，它继续监控正在运行的应用程序并将以后的实时状态与所需的指标状态（如 Git 存储库中指定的）进行比拟。ArgoCD 报告并可视化差别，并且能够主动或手动将实时状态同步回所需的指标状态。

备选

• Flux 刚刚公布了一个具备许多改良的新版本。它提供了十分类似的性能。

Argo 工作流（Workflows）和 Argo 事件（Events）

在 Kubernetes 中，你可能还须要运行批处理作业或简单的工作流。这可能是你的数据管道、异步流程甚至 CI/CD 的一部分。最重要的是，你甚至可能须要运行对某些事件做出反馈的驱动微服务，例如文件上传或音讯发送到队列。对于所有这些，咱们有 Argo Workflows 和 Argo Events。

只管它们是独立的我的项目，但它们往往会被部署在一起。

Argo Workflows 是一个相似于 Apache Airflow 的编排引擎，但它是 Kubernetes 原生的。它应用自定义 CRD 来定义简单的工作流程，应用 YAML 的步骤或 DAG，这在 K8s 中感觉更天然。它有一个丑陋的 UI、重试机制、基于 cron 的作业、输出和输入跟踪等等。你能够应用它来编排数据管道、批处理作业等等。

有时，你可能心愿将管道与异步服务（如 Kafka 等流引擎、队列、webhooks 或深度存储服务）集成。例如，你可能想要对上传到 S3 的文件等事件做出反馈。为此，你将应用 Argo 事件（Event）。

这两个工具组合为你的所有管道需要提供了一个简略而弱小的解决方案，包含 CI/CD 管道，它容许你在 Kubernetes 中本地运行 CI/CD 管道。

备选

• 对于 ML 管道，你能够应用 Kubeflow。
• 对于 CI/CD 管道，你能够应用 Tekton。

Kaniko

咱们刚刚看到了如何应用 Argo Workflows 运行 Kubernetes 原生 CI/CD 管道。一个常见的工作是构建 Docker 镜像，这在 Kubernetes 中通常是乏味的，因为构建过程实际上是在容器自身上运行的，你须要应用变通方法来应用主机的 Docker 引擎。

底线是你不应该应用 Docker 来构建你的镜像：改用 Kanico。Kaniko 不依赖于 Docker 守护过程，而是齐全在用户空间中执行 Dockerfile 中的每个命令。这使得在无奈轻松或平安地运行 Docker 守护程序的环境中构建容器镜像成为可能，例如规范的 Kubernetes 集群。这打消了在 K8s 集群中构建镜像的所有问题。

Istio

Istio 是市场上最驰名的服务网格，它是开源的并且十分受欢迎。我不会具体介绍什么是服务网格，因为它是一个微小的话题，然而如果你正在构建微服务，并且可能应该这样做，那么你将须要一个服务网格来治理通信、可察看性、错误处理、安全性。与其用反复的逻辑净化每个微服务的代码（译者：SDK 侵入），不如利用服务网格为你做这件事。

简而言之，服务网格是一个专用的基础设施层，你能够将其增加到你的应用程序中。它容许你通明地增加可察看性、流量治理和安全性等性能，而无需将它们增加到你本人的代码中。

如果 Istio 用于运行微服务，只管你能够在任何中央运行 Istio 并应用微服务，但 Kubernetes 已被一次又一次地证实是运行它们的最佳平台。Istio 还能够将你的 K8s 集群扩大到其余服务，例如 VM，容许你领有在迁徙到 Kubernetes 时十分有用的混合环境。

备选

• Linkerd 是一种更笨重且可能更快的服务网格。Linkerd 从头开始​​为安全性而构建，包含默认 mTLS、应用 Rust 构建的数据立体、内存平安语言和定期平安审计等性能
• Consul 是为任何运行时和云提供商构建的服务网格，因而它非常适合跨 K8s 和云提供商的混合部署。如果不是所有的工作负载都在 Kubernetes 上运行，这是一个不错的抉择。

Argo Rollouts

咱们曾经提到，你能够应用 Kubernetes 应用 Argo Workflows 或应用 Kanico 构建图像的相似工具来运行 CI/CD 管道。下一个合乎逻辑的步骤是持续并进行继续部署。因为波及高风险，这在实在场景中是极具挑战性的，这就是为什么大多数公司只做继续交付，这意味着他们曾经实现了自动化，但他们依然须要手动批准和验证，这个手动步骤是这是因为团队 不能齐全信赖他们的自动化。

那么，你如何建设这种信赖以解脱所有脚本并齐全自动化从源代码到生产的所有内容？答案是：可察看性。你须要将资源更多地集中在指标上，并收集精确示意应用程序状态所需的所有数据。指标是应用一组指标来建设这种信赖。如果你在 Prometheus 中领有所有数据，那么你能够主动部署，因为你能够依据这些指标主动逐渐推出应用程序。

简而言之，你须要比 K8s 开箱即用的 滚动更新 更高级的部署技术。咱们须要应用金丝雀部署进行渐进式交付。指标是逐渐将流量路由到应用程序的新版本，期待收集指标，剖析它们并将它们与预约义的规定进行匹配。如果一切正常，咱们减少流量；如果有任何问题，咱们会回滚部署。
要在 Kubernetes 中执行此操作，你能够应用提供 Canary 公布等的 Argo Rollouts。

Argo Rollouts 是一个 Kubernetes 控制器和一组 CRD，可提供高级部署性能，例如蓝绿、金丝雀、金丝雀剖析、试验和向 Kubernetes 的渐进式交付性能。

只管像 Istio 这样的服务网格提供 Canary 公布，但 Argo Rollouts 使这个过程变得更加容易并且以开发人员为核心，因为它是专门为此目标而构建的。除此之外，Argo Rollouts 能够与任何服务网格集成。

Argo Rollouts 性能：

• 蓝绿更新策略
• 金丝雀更新策略
• 细粒度、加权的流量转移
• 主动回滚和促销或人工判断
• 可定制的指标查问和业务 KPI 剖析
• 入口控制器集成：NGINX、ALB
• 服务网格集成：Istio、Linkerd、SMI
• 指标提供者集成：Prometheus、Wavefront、Kayenta、Web、Kubernetes Jobs

备选

• Istio 作为 Canary 版本的服务网格。Istio 不仅仅是一个渐进式交付工具，它还是一个残缺的服务网格。Istio 不会主动部署，Argo Rollouts 能够与 Istio 集成来实现这一点。
• Flagger 与 Argo Rollouts 十分类似，并且与 Flux 很好地集成在一起，因而如果你应用 Flux，请思考应用 Flagger。
• Spinnaker 是 Kubernetes 的第一个继续交付工具，它具备许多性能，但应用和设置起来有点简单。

Crossplane

Crossplane 是我最喜爱的 K8s 工具，我对这个我的项目感到十分兴奋，因为它给 Kubernetes 带来了一个要害的缺失局部：像治理 K8s 资源一样治理第三方服务。这意味着，你能够应用 YAML 中定义的 K8s 资源来配置云提供商数据库，例如 AWS RDS 或 GCP Cloud SQL，就像你在 K8s 中配置数据库一样。

应用 Crossplane，无需应用不同的工具和办法拆散基础设施和代码。你能够应用 K8s 资源定义所有。这样，你就无需学习 Terraform 等新工具并将它们离开保留。

Crossplane 是一个开源 Kubernetes 附加组件，它使平台团队可能组装来自多个供应商的基础设施，并公开更高级别的自助 API 供应用程序团队应用，而无需编写任何代码。

Crossplane 扩大了你的 Kubernetes 集群，为你提供实用于任何基础架构或托管云服务的 CRD。此外，它容许你齐全实现继续部署，因为与 Terraform 等其余工具相同，Crossplane 应用现有的 K8s 性能（例如管制循环）来继续察看你的集群并自动检测任何对其起作用的配置漂移。例如，如果你定义了一个托管数据库实例并且有人手动更改它，Crossplane 将自动检测问题并将其设置回以前的值。这将施行基础设施即代码和 GitOps 准则。Crossplane 与 ArgoCD 配合应用成果很好，它能够查看源代码并确保你的代码存储库是惟一的实在起源，并且代码中的任何更改都会流传到集群以及内部云服务。如果没有 Crossplane，你只能在 K8s 服务中实现 GitOps，而不能在不应用独自过程的状况下在云服务中实现，当初你能够做到这一点，这太棒了。

备选

• Terraform 是最驰名的 IaC 工具，但它不是 K8s 原生的，须要新技能并且不会主动监督配置漂移。
• Pulumi 是一种 Terraform 替代品，它应用开发人员能够测试和了解的编程语言工作。

Knative

如果你在云中开发应用程序，你可能曾经应用了一些无服务器技术，例如 AWS Lambda，它是一种称为 FaaS 的事件驱动范例。

我过来曾经探讨过 Serverless，因而请查看我之前的文章以理解更多信息。Serverless 的问题在于它与云提供商严密耦合，因为提供商能够为事件驱动的应用程序创立一个很好的生态系统。

对于 Kubernetes，如果你心愿将函数作为代码运行并应用事件驱动架构，那么你最好的抉择是 Knative。Knative 旨在在 Kubernetes 上运行函数，在 Pod 之上创立一个形象。

特点：

• 针对常见应用程序用例的具备更高级别形象的重点 API。
• 在几秒钟内建设一个可扩大、平安、无状态的服务。
• 涣散耦合的性能让你能够应用所需的局部。
• 可插拔组件让你能够应用本人的日志记录和监控、网络和服务网格。
• Knative 是可移植的：在 Kubernetes 运行的任何中央运行它，不必放心供应商锁定。
• 习用的开发者体验，反对 GitOps、DockerOps、ManualOps 等罕用模式。
• Knative 能够与常见的工具和框架一起应用，例如 Django、Ruby on Rails、Spring 等等。

备选

• Argo Events 为 Kubernetes 提供了一个事件驱动的工作流引擎，能够与 AWS Lambda 等云引擎集成。它不是 FaaS，而是为 Kubernetes 提供了一个事件驱动的架构。
• OpenFaas

Kyverno

Kubernetes 提供了极大的灵活性，以赋予麻利的自治团队势力，但能力越大，责任越大。必须有一组 最佳实际和规定，以确保以统一且有凝聚力的形式来部署和治理合乎公司政策和平安要求的工作负载。

有几种工具能够实现这一点，但没有一个是 Kubernetes 原生的…… 直到现在。Kyverno 是为 Kubernetes 设计的策略引擎，策略作为 Kubernetes 资源进行治理，并且不须要新的语言来编写策略。Kyverno 策略能够验证、扭转和生成 Kubernetes 资源。

你能够利用无关最佳实际、网络或安全性的任何类型的策略。例如，你能够强制所有服务都有标签或所有容器都以非 root 身份运行。你能够在此处查看一些政策示例。策略能够利用于整个集群或给定的命名空间。你还能够抉择是只想审核策略还是强制执行它们以阻止用户部署资源。

备选

• Open Policy Agent 是驰名的云原生基于策略的管制引擎。它应用本人的申明性语言，并且能够在许多环境中运行，而不仅仅是在 Kubernetes 上。它比 Kyverno 更难治理，但更弱小。

Kubevela

Kubernetes 的一个问题是开发人员须要十分理解和了解平台和集群配置。许多人会辩论说 K8s 的形象级别太低，这会给只想专一于编写和交付应用程序的开发人员带来很多摩擦。

在开放式应用程序模型（OAM）的设立是为了克服这个问题。这个想法是围绕应用程序创立更高级别的形象，它独立于底层运行时。你能够在此处浏览标准。

专一于应用程序而不是容器或协调器，凋谢应用程序模型 [OAM] 带来了模块化、可扩大和可移植的设计，用于应用更高级别但统一的 API 对应用程序部署进行建模。

Kubevela 是 OAM 模型的一个实现。KubeVela 与运行时无关，可本地扩大，但最重要的是，以应用程序为核心。在 Kubevela 中，应用程序是作为 Kubernetes 资源实现的一等公民。集群运营商（Platform Team）和开发者（Application Team）是有区别的。集群操作员通过定义组件（组成应用程序的可部署 / 可配置实体，如 Helm Chart）和特色来治理集群和不同的环境。开发人员通过组装组件和特色来定义应用程序。

KubeVela 是一个云原生计算基金会沙箱我的项目，尽管它仍处于起步阶段，但它能够在不久的未来扭转咱们应用 Kubernetes 的形式，让开发人员无需成为 Kubernetes 专家即可专一于应用程序。然而，我的确对 OAM 在事实世界中的适用性有一些担心，因为零碎应用程序、ML 或大数据过程等一些服务在很大水平上依赖于低级细节，这些细节可能很难融入 OAM 模型中。

备选

• Shipa 遵循相似的办法，使平台和开发团队可能协同工作，轻松将应用程序部署到 Kubernetes。

Snyk

任何开发过程中一个十分重要的方面是安全性，这始终是 Kubernetes 的一个问题，因为想要迁徙到 Kubernetes 的公司无奈轻松实现其以后的平安准则。

Snyk 试图通过提供一个能够轻松与 Kubernetes 集成的平安框架来缓解这种状况。它能够检测容器映像、你的代码、开源我的项目等中的破绽。

备选

• Falco 是 Kubernetes 的运行时平安线程检测工具。

Velero

如果你在 Kubernetes 中运行工作负载并应用卷来存储数据，则须要创立和治理备份。Velero 提供简略的备份 / 复原过程、劫难复原机制和数据迁徙。

与其余间接拜访 Kubernetes etcd 数据库执行备份和复原的工具不同，Velero 应用 Kubernetes API 来捕捉集群资源的状态并在必要时复原它们。此外，Velero 使你可能在配置的同时备份和复原你的应用程序持久数据。

Schema Hero

软件开发中的另一个常见过程是在应用关系数据库时治理 模式演变。

SchemaHero 是一种开源数据库架构迁徙工具，可将架构定义转换为可利用于任何环境的迁徙脚本。它应用 Kubernetes 申明性来治理数据库模式迁徙。你只需指定所需的状态，而后 SchemaHero 治理其余的。

备选

• LiquidBase 是最驰名的替代品。它更难应用，且不是 Kubernetes 原生的，但它具备更多功能。

Bitnami Sealed Secrets

咱们曾经介绍了许多 GitOps 工具，例如 ArgoCD。咱们的指标是将所有内容保留在 Git 中，并应用 Kubernetes 申明性来放弃环境同步。咱们刚刚看到咱们如何（并且应该）在 Git 中保留实在起源，并让自动化流程解决配置更改。

在 Git 中通常很难保留的一件事是诸如数据库明码或 API 密钥之类的机密，这是因为你永远不应该在代码存储库中存储机密。一种常见的解决方案是应用内部保存库（例如 AWS Secret Manager 或 HashiCorp Vault）来存储秘密，但这会产生很多摩擦，因为你须要有一个独自的流程来解决秘密。现实状况下，咱们心愿有一种办法能够像任何其余资源一样平安地在 Git 中存储秘密。

Sealed Secrets 旨在克服这个问题，容许你应用强加密将敏感数据存储在 Git 中。Bitnami Sealed Secrets 本地集成在 Kubernetes 中，容许你仅通过在 Kubernetes 中运行的 Kubernetes 控制器而不是其余任何人来解密密钥。控制器将解密数据并创立平安存储的原生 K8s 秘密。这使咱们可能将所有内容作为代码存储在咱们的 repo 中，从而容许咱们平安地执行继续部署，而无需任何内部依赖。

Sealed Secrets 由两局部组成：

• 集群端控制器
• 客户端实用程序：kubeseal

该 kubeseal 实用程序应用非对称加密来加密只有控制器能力解密的秘密。这些加密的机密被编码在一个 SealedSecret K8s 资源中，你能够将其存储在 Git 中。

备选

• AWS Secret Manager
• HashiCorp Vault）

Capsule

许多公司应用 多租户 来治理不同的客户。这在软件开发中很常见，但在 Kubernetes 中很难实现。命名空间 是将集群的逻辑分区创立为隔离切片的好办法，但这不足以平安地隔离客户，咱们须要强制执行网络策略、配额等。你能够为每个名称空间创立网络策略和规定，但这是一个难以扩大的乏味过程。此外，租户将不能应用多个命名空间，这是一个很大的限度。

创立 分层命名空间 是为了克服其中一些问题。这个想法是为每个租户领有一个父命名空间，为租户提供公共网络策略和配额，并容许创立子命名空间。这是一个很大的改良，但它在平安和治理方面没有对租户的本地反对。此外，它还没有达到生产状态，但 1.0 版预计将在将来几个月内公布。

以后解决此问题的罕用办法是为每个客户创立一个集群，这是平安的并提供租户所需的所有，但这很难治理且十分低廉。

Capsule 是一种为单个集群中的多个租户提供原生 Kubernetes 反对的工具。应用 Capsule，你能够为所有租户领有一个集群。Capsule 将为租户提供“简直”原生体验（有一些小限度），他们将可能创立多个命名空间并应用集群，因为它们齐全可用，暗藏了集群实际上是共享的事实。

在单个集群中，Capsule Controller 在称为 Tenant 的轻量级 Kubernetes 形象中聚合多个命名空间，这是一组 Kubernetes 命名空间。在每个租户内，用户能够自在创立他们的命名空间并共享所有调配的资源，而策略引擎则使不同的租户彼此隔离。

租户级别定义的网络和安全策略、资源配额、限度范畴、RBAC 和其余策略由租户中的所有命名空间主动继承，相似于分层命名空间。而后用户能够自在地自治操作他们的租户，而无需集群管理员的干涉。
Capsule 是 GitOps 就绪的，因为它是申明性的，并且所有配置都能够存储在 Git 中。

vCluster

vCluster 在多租户方面更进了一步，它在 Kubernetes 集群内提供了虚构集群。每个集群都在一个惯例命名空间上运行，并且是齐全隔离的。虚构集群有本人的 API 服务器和独立的数据存储，所以你在 vCluster 中创立的每个 Kubernetes 对象都只存在于 vcluster 外部。此外，您能够将 kube 上下文与虚构集群一起应用，以像应用惯例集群一样应用它们。

只有您能够在单个命名空间内创立部署，您就能够创立虚构集群并成为该虚构集群的管理员，租户能够创立命名空间、装置 CRD、配置权限等等。

vCluster 应用 k3s 作为其 API 服务器，使虚构集群超轻量级且经济高效；因为 k3s 集群 100% 合规，虚构集群也 100% 合规。vClusters 是超轻量级的（1 个 pod），耗费很少的资源并且能够在任何 Kubernetes 集群上运行，而无需对底层集群进行特权拜访。与 Capsule 相比，它的确应用了更多的资源，但它提供了更多的灵活性，因为多租户只是用例之一。

其余工具

• kube-burner 用于 压力测试。它提供指标和警报。
• 混沌工程的 Litmus。
• kubewatch 用于监控，但次要关注基于 Kubernetes 事件（如资源创立或删除）的推送告诉。它能够与 Slack 等许多工具集成。
• BotKube 是一个音讯机器人，用于监控和调试 Kubernetes 集群。与 kubewatch 相似，但更新并具备更多功能。
• Mizu 是一个 API 流量查看器和调试器。
• kube-fledged 是一个 Kubernetes 插件，用于间接在 Kubernetes 集群的工作节点上创立和治理容器镜像的缓存。因而，应用程序 pod 简直立刻启动，因为不须要从注册表中提取图像。

论断

在本文中，咱们回顾了我最喜爱的 Kubernetes 工具。我专一于能够合并到任何 Kubernetes 发行版中的开源我的项目。我没有涵盖诸如 OpenShift 或 Cloud Providers Add-Ons 之类的商业解决方案，因为我想让它放弃通用性，但我激励您摸索如果您在云上运行 Kubernetes 或应用商业工具，您的云提供商能够为您提供什么。

我的指标是向您展现您能够在 Kubernetes 中实现您在本地所做的所有。我还更多地关注鲜为人知的工具，我认为这些工具可能具备很大的后劲，例如 Crossplane、Argo Rollouts 或 Kubevela。我更感兴趣的工具是 vCluster、Crossplane 和 ArgoCD/Workflows。

文章对立公布在公众号 云原生指北