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

當您聽到“雲原生”這個詞時，您首先想到的是 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]中檢視可用的內容。