值得關注的 9 個開源雲原生專案

工作中用了容器？熟悉這些出自雲原生計算基金會的專案嗎？

隨著用容器來開發應用的實踐變得流行，雲原生應用也在增長。雲原生應用的定義為：

“雲原生技術用於開發使用打包在容器中的服務所構建的應用程式，以微服務的形式部署，並通過敏捷的 DevOps 流程和持續交付工作流在彈性基礎設施上進行管理。”

這個定義提到了構成雲原生應用的不可或缺的四個元素：

1. 容器
2. 微服務
3. DevOps
4. 持續整合和持續交付 (CI/CD)

儘管這些技術各有各自獨特的歷史，但它們之間卻相輔相成，在短時間內實現了雲原生應用和工具的驚人的指數級增長。這個雲原生計算基金會（CNCF）資訊圖呈現了當今雲原生應用生態的規模和廣度。

雲原生計算基金會專案

我想說，瞧著吧！這僅僅是一個開始。正如 NodeJS 的出現引發了無數的 JavaScript 工具的爆炸式增長一樣，容器技術的普及也推動了雲原生應用的指數增長。

好訊息是，有幾個組織負責監管並將這些技術連線在一起。 其中之一是 開放容器倡議Open Containers Initiative（OCI），它是一個輕量級的、開放的治理機構（或專案），“它是在 Linux 基金會的支援下形成的，其明確目的是建立開放的行業標準的容器格式和執行時。” 另一個是 CNCF，它是“一個致力於使雲原生計算普及和可持續發展的開源軟體基金會”。

通常除了圍繞雲原生應用建立社群之外，CNCF 還幫助專案圍繞其雲原生應用建立結構化管理。CNCF 建立了成熟等級的概念（沙箱級、孵化級或畢業級），分別與下圖中的“創新者”、“早期採用者”和“早期大量應用”相對應。

CNCF 專案成熟等級

CNCF 為每個成熟等級制定了詳細的標準（為方便讀者而列在下面）。獲得技術監督委員會（TOC）三分之二的同意才能轉為孵化或畢業級。

沙箱級

要想成為沙箱級，一個專案必須至少有兩個 TOC 贊助商。 有關詳細過程，請參見《CNCF 沙箱指南 v1.0》。

孵化級

註：孵化級是我們期望對專案進行全面的盡職調查的起點。

要進入孵化級，專案除了滿足沙箱級的要求之外還要滿足：

• 證明至少有三個獨立的終端使用者已成功將其用於生產，且 TOC 判斷這些終端使用者具有足夠的品質和範圍。
• 提交者的數量要合理。提交者定義為具有提交權的人，即可以接受部分或全部專案貢獻的人。
• 顯示出有大量持續提交和合並貢獻。
• 由於這些指標可能會根據專案的型別、範圍和大小而有很大差異，所以 TOC 有權決定是否滿足這些標準的活動水平。

畢業級

要從沙箱或孵化級畢業，或者要使一個新專案作為已畢業專案加入，專案除了必須滿足孵化級的標準外還要滿足：

• 至少有兩個來自組織的提交者。
• 已獲得並保持了“核心基礎設施計劃最佳實踐徽章”。
• 已完成獨立的第三方安全稽核，並行佈了具有與以下範例類似的範圍和品質的結果（包括已解決的關鍵漏洞）：https://github.com/envoyproxy/envoy，並在畢業之前需要解決所有關鍵的漏洞。
• 採用《CNCF 行為準則》。
• 明確規定專案治理和提交流程。最好將其列在 GOVERNANCE.md 檔案中，並參照顯示當前提交者和榮譽提交者的 OWNERS.md 檔案。
• 至少有一個主倉的專案採用者的公開列表（例如，ADOPTERS.md 或專案網站上的徽標）。
• 獲得 TOC 的絕大多數票，進入畢業階段。如果專案能夠表現出足夠的成熟度，則可以嘗試直接從沙箱級過渡到畢業級。專案可以無限期保持孵化狀態，但是通常預計它們會在兩年內畢業。

值得關注的 9 個專案

本文不可能涵蓋所有的 CNCF 專案，我將介紹最有趣的 9 個畢業和孵化的開源專案。

我也建立了視訊材料來介紹這些專案。

畢業專案

畢業的專案被認為是成熟的，已被許多組織採用的，並且嚴格遵守了 CNCF 的準則。以下是三個最受歡迎的開源 CNCF 畢業專案。（請注意，其中一些描述來源於專案的網站並被做了改編。）

Kubernetes（希臘語“舵手”）

Kubernetes! 說起雲原生應用，怎麼能不提 Kubernetes 呢？ Google 發明的 Kubernetes 無疑是最著名的基於容器的應用程式的容器編排平台，而且它還是一個開源工具。

什麼是容器編排平台？通常，一個容器引擎本身可以管理幾個容器。但是，當你談論數千個容器和數百個服務時，管理這些容器變得非常複雜。這就是容器編排引擎的用武之地。容器編排引擎通過自動化容器的部署、管理、網路和可用性來幫助管理大量的容器。

Docker Swarm 和 Mesosphere Marathon 也是容器編排引擎，但是可以肯定地說，Kubernetes 已經贏得了這場比賽（至少現在是這樣）。Kubernetes 還催生了像 OKD 這樣的容器即服務（CaaS）平台，它是 Kubernetes 的 Origin 社群發行版，並成了 Red Hat OpenShift 的一部分。

想開始學習，請存取 Kubernetes GitHub 倉庫，並從 Kubernetes 文件頁面存取其文件和學習資源。

Prometheus（普羅米修斯）

Prometheus 是 2012 年在 SoundCloud 上構建的一個開源的系統監控和告警工具。之後，許多公司和組織都採用了 Prometheus，並且該專案擁有非常活躍的開發者和使用者群體。現在，它已經成為一個獨立的開源專案，獨立於公司之外進行維護。

Prometheus 的架構

理解 Prometheus 的最簡單方法是視覺化一個生產系統，該系統需要 24（小時）x 365（天）都可以正常執行。沒有哪個系統是完美的，也有減少故障的技術（稱為容錯系統），但是，如果出現問題，最重要的是儘快發現問題。這就是像 Prometheus 這樣的監控工具的用武之地。Prometheus 不僅僅是一個容器監控工具，但它在雲原生應用公司中最受歡迎。此外，其他開源監視工具，包括 Grafana，都借助了 Prometheus。

開始使用 Prometheus 的最佳方法是下載其 GitHub 倉庫。在本地執行 Prometheus 很容易，但是你需要安裝一個容器引擎。你可以在 Prometheus 網站上檢視詳細的文件。

Envoy（使者）

Envoy（或 Envoy 代理）是專為雲原生應用設計的開源的邊緣代理和服務代理。由 Lyft 建立的 Envoy 是為單一服務和應用而設計的高效能的 C++ 開發的分散式代理，同時也是為由大量微服務組成的服務網格架構而設計的通訊匯流排和通用資料平面。Envoy 建立在 Nginx、HAProxy、硬體負載均衡器和雲負載均衡器等解決方案的基礎上，Envoy 與每個應用相伴（並行）執行，並通過提供平台無關的方式提供通用特性來抽象網路。

當基礎設施中的所有服務流量都經過 Envoy 網格時，很容易就可以通過一致的可觀測性來視覺化問題域，調整整體效能，並在單個位置新增基礎功能。基本上，Envoy 代理是一個可幫助組織為生產環境構建容錯系統的服務網格工具。

服務網格應用有很多替代方案，例如 Uber 的 Linkerd（下面會討論）和 Istio。Istio 通過將其部署為 Sidecar 並利用了 Mixer 的設定模型，實現了對 Envoy 的擴充套件。Envoy 的顯著特性有：

• 包括所有的“入場籌碼table stakes（LCTT 譯註：引申為基礎必備特性）”特性（與 Istio 這樣的控制平面組合時）
• 帶載執行時 99% 資料可達到低延時
• 可以作為核心的 L3/L4 過濾器，提供了開箱即用的 L7 過濾器
• 支援 gRPC 和 HTTP/2（上行/下行）
• 由 API 驅動，並支援動態設定和熱過載
• 重點關注指標收集、跟蹤和整體可監測性

要想了解 Envoy，證實其能力並實現其全部優勢，需要豐富的生產級環境執行的經驗。你可以在其詳細文件或存取其 GitHub 倉庫了解更多資訊。

孵化專案

下面是六個最流行的開源的 CNCF 孵化專案。

rkt（火箭）

rkt, 讀作“rocket”，是一個 Pod 原生的容器引擎。它有一個命令列介面用來在 Linux 上執行容器。從某種意義上講，它和其他容器如 Podman、Docker 和 CRI-O 相似。

rkt 最初是由 CoreOS （後來被 Red Hat 收購）開發的，你可以在其網站上找到詳細的文件，以及在 GitHub 上存取其原始碼。

Jaeger（賊鷗）

Jaeger 是一個開源的端到端的分散式追蹤系統，適用於雲端應用。在某種程度上，它是像 Prometheus 這樣的監控解決方案。但它有所不同，因為其使用場景有所擴充套件：

• 分散式事務監控
• 效能和延時優化
• 根因分析
• 服務依賴性分析
• 分散式上下文傳播

Jaeger 是一項 Uber 打造的開源技術。你可以在其網站上找到詳細文件，以及在 GitHub 上找到其原始碼。

Linkerd

像建立 Envoy 代理的 Lyft 一樣，Uber 開發了 Linkerd 開源解決方案用於生產級的服務維護。在某些方面，Linkerd 就像 Envoy 一樣，因為兩者都是服務網格工具，旨在提供平台級的可觀測性、可靠性和安全性，而無需進行設定或程式碼更改。

但是，兩者之間存在一些細微的差異。 儘管 Envoy 和 Linkerd 充當代理並可以通過所連線的服務進行上報，但是 Envoy 並不像 Linkerd 那樣被設計為 Kubernetes Ingress 控制器。Linkerd 的顯著特點包括：

• 支援多種平台（Docker、Kubernetes、DC/OS、Amazon ECS 或任何獨立的機器）
• 內建服務發現抽象，可以將多個系統聯合在一起
• 支援 gRPC、HTTP/2 和 HTTP/1.x請 求和所有的 TCP 流量

你可以在 Linkerd 網站上閱讀有關它的更多資訊，並在 GitHub 上存取其原始碼。

Helm（舵輪）

Helm 基本上就是 Kubernetes 的包管理器。如果你使用過 Apache Maven、Maven Nexus 或類似的服務，你就會理解 Helm 的作用。Helm 可幫助你管理 Kubernetes 應用程式。它使用“Helm Chart”來定義、安裝和升級最複雜的 Kubernetes 應用程式。Helm 並不是實現此功能的唯一方法；另一個流行的概念是 Kubernetes Operators，它被 Red Hat OpenShift 4 所使用。

你可以按照其文件中的快速開始指南或 GitHub 指南來試用 Helm。

Etcd

Etcd 是一個分散式的、可靠的鍵值儲存，用於儲存分散式系統中最關鍵的資料。其主要特性有：

• 定義明確的、面向使用者的 API（gRPC）
• 自動 TLS，可選的用戶端證書驗證
• 速度（可達每秒 10,000 次寫入）
• 可靠性（使用 Raft 實現分散式）

Etcd 是 Kubernetes 和許多其他技術的預設的內建資料儲存方案。也就是說，它很少獨立執行或作為單獨的服務執行；相反，它以整合到 Kubernetes、OKD/OpenShift 或其他服務中的形式來運作。還有一個 etcd Operator 可以用來管理其生命週期並解鎖其 API 管理功能：

你可以在 etcd 文件中了解更多資訊，並在 GitHub上存取其原始碼。

CRI-O

CRI-O 是 Kubernetes 執行時介面的 OCI 相容實現。CRI-O 用於各種功能，包括：

• 使用 runc（或遵從 OCI 執行時規範的任何實現）和 OCI 執行時工具執行
• 使用容器/映象進行映象管理
• 使用容器/儲存來儲存和管理映象層
• 通過容器網路介面（CNI）來提供網路支援

CRI-O 提供了大量的文件，包括指南、教學、文章，甚至播客，你還可以存取其 GitHub 頁面。

我錯過了其他有趣且開源的雲原生專案嗎？請在評論中提醒我。