值得關注的 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#security-audit，並在畢業之前需要解決所有關鍵的漏洞。
• 採用《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 頁面。

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

via: https://opensource.com/article/19/8/cloud-native-projects

作者：Bryant Son 選題：lujun9972 譯者：messon007 校對：wxy

本文由 LCTT 原創編譯，Linux中國 榮譽推出

本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive