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

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

1. Nomad

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

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

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

如果你需要编排一些容器，而 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[7]（目前处于测试阶段），它允许您使用与 Pulumi 相同的语言为 Terraform 编写代码，这是对 Pulumi 方法的另一个投票。

3.Thanos

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

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

我喜欢灭霸的设计理念：

• 每个子命令应该做一件事并做好
• 编写协同工作的组件
• 让组件易于阅读、编写和运行

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

4.etcd

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

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

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

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

5. Kuma

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

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

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

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

6. sigstore

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

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

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

7. OpenTelemetry

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

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

参考资料

[1] 但是在 CNCF 领域: https://landscape.cncf.io/

[2] Nomad: https://www.nomadproject.io/

[3] 架构: https://www.nomadproject.io/docs/internals/architecture

[4] 速度非常快: https://www.hashicorp.com/c1m

[5] 将 Cilium 用作 Nomad 的 CNI: https://www.hashicorp.com/blog/multi-interface-networking-and-cni-plugins-in-nomad-0-12

[6] Pulumi: https://www.pulumi.com/

[7] 为 Terraform 构建了 Cloud Development Kit: https://www.terraform.io/cdktf

[8] 普罗米修斯: https://prometheus.io/blog/

[9] Thanos: https://thanos.io/

[10] GitHub README: https://github.com/thanos-io/thanos

[11] Raft 共识算法: https://raft.github.io/

[12] 在 docs 中: https://etcd.io/docs/v3.3/learning/why/

[13] 服务网格时遇到了困难。: https://en.wikipedia.org/wiki/Service_mesh

[14] Kuma: https://kuma.io/

[15] 策略。: https://kuma.io/policies/

[16] 策略类型列表: https://kuma.io/policies/

[17] 网站上: https://www.sigstore.dev/how-it-works

[18] 精彩演讲: https://www.youtube.com/watch?v=PVhRQFS9Njg

[19] 发布了 1.0 版: https://medium.com/opentelemetry/opentelemetry-specification-v1-0-0-tracing-edition-72dd08936978

[20] 减少供应商锁定: https://www.honeycomb.io/blog/open-telemetry-vendor-neutral/

[21] 您可以在 OpenTelemetry Registry: https://opentelemetry.io/registry/