本文列出一些云原生工具，这些工具对于不使用 Kubernetes 或未将其用于所有工作负载的团队非常有用。

当您听到“云原生”这个词时，您首先想到的是 Kubernetes 吗?Kubernetes 现在是仅次于 Linux 的第二大开源项目，是云原生池塘里的大鱼。但是在 CNCF 领域和更广泛的云原生社区中还有许多其他项目。

下面列出一些云原生工具，这些工具对于不使用 Kubernetes 或未将其用于所有工作负载的团队非常有用。

1. Nomad

你知道除了 Kubernetes 之外还有容器编排器吗?其中之一是Nomad，由 HashiCorp 的成员制作。

它的架构比 Kubernetes 更简单，如果你想要比 Docker Swarm 更具可扩展性但不像 Kubernetes 那样复杂的东西，它可能是一个很好的选择。不过，您不必在 Kubernetes 和 Nomad 之间做出选择;一些团队将它们都用于不同的工作负载。Nomad 的一个流行用例是运行批处理作业。

Nomad 与其他 HashiCorp 工具集成得非常好，而且速度非常快。此外，您可以将 Cilium 用作 Nomad 的 CNI。

如果你需要编排一些容器，而 Kubernetes 似乎有点过头了，你可以试试 Nomad。

2. Pulumi

我在基础设施即代码世界中度过了几年的时间，这个话题仍然让我很感兴趣。有一段时间，我认为 Terraform 已经赢得了云供应工具领域，也许现在仍然如此，但Pulumi[6]是一个更新的替代品。

如果您熟悉 Terraform，就会知道它使用 HashiCorp 配置语言 (HCL)。它是一种领域特定语言 (DSL)，而不是成熟的编程语言。自定义 DSL 的问题之一是它们给用户带来了额外的负担，让他们学习 DSL 以及哪些模式有用。

Pulumi 采取了不同的方法。使用 Pulumi，您可以使用您已经知道的语言，并使用 Pulumi SDK 来提取您需要的特定 Pulumi 位。它基本上是一个库，可以为您的代码添加配置云资源的能力。支持的语言是 Python、Go、JavaScript、TypeScript 和 C#。这意味着您在编写 Pulimi 代码时还可以访问您选择的语言的整个生态系统，包括测试工具。

虽然我认为让用户使用他们想要的语言工作通常是最好的方法，但像 HCL 这样的声明式 DSL 的优点之一是可以确保人们编写的代码是幂等的。使用过程语言，代码中的逻辑错误可能会导致非常意外的结果。这是这里的重大权衡。

总的来说，我真的很喜欢 Pulimi 的方法。HashiCorp 最近为 Terraform 构建了 Cloud Development Kit(目前处于测试阶段)，它允许您使用与 Pulumi 相同的语言为 Terraform 编写代码，这是对 Pulumi 方法的另一个投票。

3. Thanos

每个人都在用普罗米修斯。它绝对是用于 Kubernetes 和其他云原生应用程序的最流行的可观察性工具之一。但是如何设置 Prometheus 使其具有高可用性和可扩展性?您如何处理所有数据?

这就是Thanos的用武之地。正如GitHub README所述，“Thanos 是一组组件，可以组合成一个具有无限存储容量的高可用性度量系统，可以无缝地添加到现有的 Prometheus 部署之上。” 管理存储通常是指标收集的一大痛点，因此无限的存储容量听起来很棒，Thanos 还为 Prometheus 添加了高可用性。

我喜欢灭霸的设计理念：

  • 每个子命令应该做一件事并做好

  • 编写协同工作的组件

  • 让组件易于阅读、编写和运行

Thanos 是一个 CNCF 孵化项目，如果你正在收集/存储指标，你应该试试。

4. etcd

虽然 etcd 以 Kubernetes 集群的数据存储而闻名，但您可以用它做更多事情。

etcd 是一种分布式键值存储，可用于 Zookeeper 和 Consul 等工具经常涵盖的一些用例，例如服务发现和存储配置数据。它使用了Raft 共识算法(Consul 的共识协议也是基于 Raft)，并且有一个易于使用的 CLI 和 API。

如果您想比较 etcd 和其他键值存储，在 docs 中有一个有用的页面。

根据您的用例，Consul 或 Vault 之类的东西可能更合适，但在评估 key-value 存储选项时请记住 etcd。

5. Kuma

还记得虚拟机吗？事实证明，很多人仍在使用它们，而没有运行容器化工作负载的团队在使用 Istio 和 Linkerd 等服务网格时遇到了困难。

Kuma是一种服务网格，其设计不仅可以与 Kubernetes 一起使用，还可以与 VM 一起使用。Kuma 建立在 Envoy 之上，它允许团队为 Mutal TLS、健康检查、断路器以及使用 Zipkin 或 Datadog 的分布式跟踪等内容配置策略。我希望您可以使用 Envoy 自己推出其中的许多功能，但是 Kuma 为您提供了一个管理它们的中心位置，并且它抽象了 Envoy 的一些复杂性。

Kuma 支持的策略类型列表令人印象深刻。如果你想在你的服务网格中加入一些混沌工程，Kuma 甚至支持一些基本的故障注入。

Kuma 是由 Kong 的团队创建的，它与开源 Kong Gateway 集成。Kuma 被捐赠给 CNCF，目前是 CNCF 沙盒项目。

6. sigstore

自 Solarwinds 遭到黑客攻击以来，软件供应链安全已成为业界关注的一大问题。这是许多软件项目需要解决的问题，对于资源较少的开源项目来说，这通常更具挑战性。Sigstore 是一组开源工具，允许项目维护人员轻松地对其工件进行加密签名，同时允许其他人验证甚至监控这些签名。网站上有 sigstore 工具集的高级视图。

那么为什么我对人们签署软件的新工具如此感兴趣呢?我在洛杉矶的 KubeCon 上看到了 Bob Callaway 和 Dan Lorenc 的精彩演讲，展示了在没有 sigstore 的情况下执行相同的流程是多么困难。他们让整个过程变得如此简单给我留下了深刻的印象，我喜欢 sigstore 工具带来的透明度。

如果您正在构建软件版本或使用它们，那么值得花一些时间了解 sigstore。在 Linux 基金会和 Google、Red Hat 和 VMware 等公司的支持下，sigstore 几乎肯定会成为行业标准。

7. OpenTelemetry

OpenTelemetry 是在 OpenTracing 和 OpenCensus 项目合并时创建的分布式跟踪标准。这次合并减少了跟踪领域的许多混乱，OpenTelemetry 已被 Honeycomb、Datadog、New Relic 和 Dynatrace 等主要供应商采用。

它更像是一种规范，而不是一种工具。OpenTelemetry 规范最近发布了 1.0 版。跟踪对于运行分布式系统的团队来说是一个至关重要的问题，而 OpenTelemetry 通过提供一个现在被广泛使用的通用规范，极大地影响了可观察性空间。这有助于减少供应商锁定，这是可观察性工具的一个大问题。OpenTelemetry 项目包含 API 和 SDK、Open Telemetry Collector 等等，因此我认为它至少包含一些工具很舒服。您可以在 OpenTelemetry Registry[21]中查看可用的内容。