當(dāng)您聽到“云原生”這個詞時，您首先想到的是 Kubernetes 嗎?Kubernetes 現(xiàn)在是僅次于 Linux 的第二大開源項目，是云原生池塘里的大魚。但是在 CNCF 領(lǐng)域和更廣泛的云原生社區(qū)中還有許多其他項目。

下面列出一些云原生工具，這些工具對于不使用 Kubernetes 或未將其用于所有工作負(fù)載的團隊非常有用。

1. Nomad

你知道除了 Kubernetes 之外還有容器編排器嗎?其中之一是Nomad，由 HashiCorp 的成員制作。

它的架構(gòu)比 Kubernetes 更簡單，如果你想要比 Docker Swarm 更具可擴展性但不像 Kubernetes 那樣復(fù)雜的東西，它可能是一個很好的選擇。不過，您不必在 Kubernetes 和 Nomad 之間做出選擇;一些團隊將它們都用于不同的工作負(fù)載。Nomad 的一個流行用例是運行批處理作業(yè)。

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

如果你需要編排一些容器，而 Kubernetes 似乎有點過頭了，你可以試試 Nomad。

2. Pulumi

我在基礎(chǔ)設(shè)施即代碼世界中度過了幾年的時間，這個話題仍然讓我很感興趣。有一段時間，我認(rèn)為 Terraform 已經(jīng)贏得了云供應(yīng)工具領(lǐng)域，也許現(xiàn)在仍然如此，但Pulumi[6]是一個更新的替代品。

如果您熟悉 Terraform，就會知道它使用 HashiCorp 配置語言 (HCL)。它是一種領(lǐng)域特定語言 (DSL)，而不是成熟的編程語言。自定義 DSL 的問題之一是它們給用戶帶來了額外的負(fù)擔(dān)，讓他們學(xué)習(xí) DSL 以及哪些模式有用。

Pulumi 采取了不同的方法。使用 Pulumi，您可以使用您已經(jīng)知道的語言，并使用 Pulumi SDK 來提取您需要的特定 Pulumi 位。它基本上是一個庫，可以為您的代碼添加配置云資源的能力。支持的語言是 Python、Go、JavaScript、TypeScript 和 C#。這意味著您在編寫 Pulimi 代碼時還可以訪問您選擇的語言的整個生態(tài)系統(tǒng)，包括測試工具。

雖然我認(rèn)為讓用戶使用他們想要的語言工作通常是最好的方法，但像 HCL 這樣的聲明式 DSL 的優(yōu)點之一是可以確保人們編寫的代碼是冪等的。使用過程語言，代碼中的邏輯錯誤可能會導(dǎo)致非常意外的結(jié)果。這是這里的重大權(quán)衡。

總的來說，我真的很喜歡 Pulimi 的方法。HashiCorp 最近為 Terraform 構(gòu)建了 Cloud Development Kit(目前處于測試階段)，它允許您使用與 Pulumi 相同的語言為 Terraform 編寫代碼，這是對 Pulumi 方法的另一個投票。

3. Thanos

每個人都在用普羅米修斯。它絕對是用于 Kubernetes 和其他云原生應(yīng)用程序的最流行的可觀察性工具之一。但是如何設(shè)置 Prometheus 使其具有高可用性和可擴展性?您如何處理所有數(shù)據(jù)?

這就是Thanos的用武之地。正如GitHub README所述，“Thanos 是一組組件，可以組合成一個具有無限存儲容量的高可用性度量系統(tǒng)，可以無縫地添加到現(xiàn)有的 Prometheus 部署之上。” 管理存儲通常是指標(biāo)收集的一大痛點，因此無限的存儲容量聽起來很棒，Thanos 還為 Prometheus 添加了高可用性。

我喜歡滅霸的設(shè)計理念：

• 每個子命令應(yīng)該做一件事并做好
• 編寫協(xié)同工作的組件
• 讓組件易于閱讀、編寫和運行

Thanos 是一個 CNCF 孵化項目，如果你正在收集/存儲指標(biāo)，你應(yīng)該試試。

4. etcd

雖然 etcd 以 Kubernetes 集群的數(shù)據(jù)存儲而聞名，但您可以用它做更多事情。

etcd 是一種分布式鍵值存儲，可用于 Zookeeper 和 Consul 等工具經(jīng)常涵蓋的一些用例，例如服務(wù)發(fā)現(xiàn)和存儲配置數(shù)據(jù)。它使用了Raft 共識算法(Consul 的共識協(xié)議也是基于 Raft)，并且有一個易于使用的 CLI 和 API。

如果您想比較 etcd 和其他鍵值存儲，在 docs 中有一個有用的頁面。

根據(jù)您的用例，Consul 或 Vault 之類的東西可能更合適，但在評估 key-value 存儲選項時請記住 etcd。

5. Kuma

還記得虛擬機嗎？事實證明，很多人仍在使用它們，而沒有運行容器化工作負(fù)載的團隊在使用 Istio 和 Linkerd 等服務(wù)網(wǎng)格時遇到了困難。

Kuma是一種服務(wù)網(wǎng)格，其設(shè)計不僅可以與 Kubernetes 一起使用，還可以與 VM 一起使用。Kuma 建立在 Envoy 之上，它允許團隊為 Mutal TLS、健康檢查、斷路器以及使用 Zipkin 或 Datadog 的分布式跟蹤等內(nèi)容配置策略。我希望您可以使用 Envoy 自己推出其中的許多功能，但是 Kuma 為您提供了一個管理它們的中心位置，并且它抽象了 Envoy 的一些復(fù)雜性。

Kuma 支持的策略類型列表令人印象深刻。如果你想在你的服務(wù)網(wǎng)格中加入一些混沌工程，Kuma 甚至支持一些基本的故障注入。

Kuma 是由 Kong 的團隊創(chuàng)建的，它與開源 Kong Gateway 集成。Kuma 被捐贈給 CNCF，目前是 CNCF 沙盒項目。

6. sigstore

自 Solarwinds 遭到黑客攻擊以來，軟件供應(yīng)鏈安全已成為業(yè)界關(guān)注的一大問題。這是許多軟件項目需要解決的問題，對于資源較少的開源項目來說，這通常更具挑戰(zhàn)性。Sigstore 是一組開源工具，允許項目維護人員輕松地對其工件進行加密簽名，同時允許其他人驗證甚至監(jiān)控這些簽名。網(wǎng)站上有 sigstore 工具集的高級視圖。

那么為什么我對人們簽署軟件的新工具如此感興趣呢?我在洛杉磯的 KubeCon 上看到了 Bob Callaway 和 Dan Lorenc 的精彩演講，展示了在沒有 sigstore 的情況下執(zhí)行相同的流程是多么困難。他們讓整個過程變得如此簡單給我留下了深刻的印象，我喜歡 sigstore 工具帶來的透明度。

如果您正在構(gòu)建軟件版本或使用它們，那么值得花一些時間了解 sigstore。在 Linux 基金會和 Google、Red Hat 和 VMware 等公司的支持下，sigstore 幾乎肯定會成為行業(yè)標(biāo)準(zhǔn)。

7. OpenTelemetry

OpenTelemetry 是在 OpenTracing 和 OpenCensus 項目合并時創(chuàng)建的分布式跟蹤標(biāo)準(zhǔn)。這次合并減少了跟蹤領(lǐng)域的許多混亂，OpenTelemetry 已被 Honeycomb、Datadog、New Relic 和 Dynatrace 等主要供應(yīng)商采用。

它更像是一種規(guī)范，而不是一種工具。OpenTelemetry 規(guī)范最近發(fā)布了 1.0 版。跟蹤對于運行分布式系統(tǒng)的團隊來說是一個至關(guān)重要的問題，而 OpenTelemetry 通過提供一個現(xiàn)在被廣泛使用的通用規(guī)范，極大地影響了可觀察性空間。這有助于減少供應(yīng)商鎖定，這是可觀察性工具的一個大問題。OpenTelemetry 項目包含 API 和 SDK、Open Telemetry Collector 等等，因此我認(rèn)為它至少包含一些工具很舒服。您可以在 OpenTelemetry Registry[21]中查看可用的內(nèi)容。