7 個值得關注的開源雲原生工具

當您聽到“雲原生”這個詞時，您首先想到的是 Kubernetes 嗎?Kubernetes 現在是僅次於 Linux 的第二大開源專案，是雲原生池塘裡的大魚。但是在 CNCF 領域和更廣泛的雲原生社群中還有許多其他專案。

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

1. Nomad

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

它的架構比 Kubernetes 更簡單，如果你想要比 Docker Swarm 更具可擴充套件性但不像 Kubernetes 那樣複雜的東西，它可能是一個很好的選擇。不過，您不必在 Kubernetes 和 Nomad 之間做出選擇;一些團隊將它們都用於不同的工作負載。Nomad 的一個流行用例是執行批處理作業。

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

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

2. Pulumi

我在基礎設施即程式碼世界中度過了幾年的時間，這個話題仍然讓我很感興趣。有一段時間，我認為 Terraform 已經贏得了雲供應工具領域，也許現在仍然如此，但Pulumi是一個更新的替代品。

如果您熟悉 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[10]所述，“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中檢視可用的內容。