使用容器嗎？來熟悉一下雲原生計算基金會上的這些項目。

隨著使用容器開發應用程序的實踐越來越流行，雲本地應用程序也在不斷增加。根據定義：

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

該描述包括四個元素，這些元素與雲原生應用程序是一體的：

1. 容器
2. 微服務
3. DevOps
4. 持續集成和持續交付（CI/CD）

儘管這些技術有著非常獨特的歷史，但它們相互補充得很好，並在短時間內導致雲原生應用程序和工具集的指數級增長。這張雲原生計算基金會（CNCF）的信息圖表顯示了雲原生應用生態系統的大小和廣度。

雲原生計算基金會項目圖

我是說，看看這個！這只是一個開始。正如Node.JS的創建引發了無休止的JavaScript工具的爆炸，容器技術的流行開始了雲本地應用程序的指數級增長。

好消息是有幾個組織負責監督和連接這些點。一個是開放容器聯盟（OCI），它是一個輕量級的開放式治理結構（或項目），在Linux基金會的支持下形成的。OCI目的是圍繞容器格式和運行時間創建開放的工業標準。另一個是CNCF，“一個開源軟件基金會致力於使雲原生計算普及和可持續。”

除了一般圍繞雲本機應用程序構建社區之外，CNCF還幫助項目圍繞其雲本機應用程序建立結構化治理。CNCF創建了成熟度級別“沙盒”、“孵化”或“畢業”的概念，與下圖中的創新者、早期採用者和早期多數層相對應。

CNCF成熟度模型

1）沙盒階段

要在沙盒中被接受，一個項目必須至少有兩個TOC發起人。詳細流程請參見CNCF Sandbox Guidelines v1.0。

2）孵化階段

注：孵化水平是我們希望對項目進行全面盡職調查的點。

要進入孵化階段，項目必須滿足沙盒階段的要求，並加上：

• 記錄至少三個獨立的最終用戶在生產中成功使用，根據TOC的判斷，這些用戶具有足夠的質量和範圍
• 有一個合理的提交者數量。提交者定義為具有commit bit的人，即可以通過對項目的部分或全部的代碼提交貢獻的人
• 顯示出持續不斷的代碼提交和代碼合併數據流
• 由於這些指標可能因項目的類型、範圍和規模而顯著不同，因此TOC對足以滿足這些標準的活動水平有最終判斷

3）畢業階段

能從“沙盒”或者“孵化”達到“畢業”階段的項目，或者一個直接就進入到“畢業”階段的項目，項目必須符合孵化階段標準，以及如下條件：

• 擁有來自至少兩個組織的代碼提交者
• 已經實現並維護了核心基礎設施計劃最佳實踐徽章
• 已完成獨立的第三方安全審計，其結果發佈的範圍和質量與以下示例類似（包括已解決的列舉在https://github.com/envoyproxy/envoy#security-audit的關鍵漏洞）並且所有關鍵的問題都需要在“畢業”前解決
• 適應CNCF執行準則
• 明確定義項目治理和提交者流程。這最好在governance.md文件中列出，並參考owners.md文件，顯示當前和退休的提交者
• 至少有一個項目採用者的公開列表（例如，Adopters.md或項目網站上的logo）
• 獲得TOC的絕大多數選票，項目進入“畢業”階段。如果項目能夠顯示出足夠的成熟度，那麼它們可以嘗試直接從“沙盒”直接跳躍到“畢業”。項目可以無限期地保持在“孵化”狀態，但通常預計在兩年內達到“畢業”階段

9個值得考慮的項目

儘管不可能在一篇文章中涵蓋所有CNCF項目，我還是想要列舉9個有趣的處於“畢業”階段和“孵化”階段的開源項目。

一、畢業的項目

“畢業”階段項目被許多組織認為是成熟的，必須遵守CNCF的指導方針。以下是三個最流行的開源CNCF畢業項目。（請注意，其中一些描述是從項目的網站上改編和重用的。）

1、Kubernetes

啊，Kubernetes。我們如何在不提到Kubernetes的情況下談論雲原生應用程序？Kubernetes無疑是Google發明的最著名的基於容器的應用程序的容器編排平臺，也是一個開源工具。

什麼是容器編排平臺？基本上，一個獨立的容器引擎可以管理幾個容器。然而，當您談論數千個容器和數百個服務時，管理這些容器變得非常複雜。這就是容器引擎的切入點。容器編排引擎通過自動化容器的部署、管理、聯網和可用性來幫助擴展容器。

Docker Swarm 和 Mesosphere Marathon是另外兩種容器編排引擎，但是我們可以很放心地說Kubernetes在競爭中勝出。Kubernetes還催生了Container-as-a-Service (CaaS) 平臺，比如：OKD。最初的Kubernetes社區發佈版，激發RedHat的OpenShift。

可以從閱讀Kubernetes的Github倉庫開始，在Kubernetes Documents站點網頁訪問文檔學習資源。

2、Prometheus

Prometheus是一個開源系統監控和警報工具包，於2012年在SoundCloud構建。從那時起，許多公司和組織都採用了Prometheus，並且這個項目有一個非常活躍的開發人員和用戶社區。它現在是一個獨立的開源項目，獨立於公司進行維護。

Prometheus架構

瞭解Prometheus最簡單的方法是設想一個生產系統，它需要每天24小時，每年365天工作。沒有一個系統是完美的，也有一些技術可以減少故障（稱為容錯系統）。但是，如果出現問題，最重要的是儘快識別它。這就是Prometheus這樣的監控工具的用武之地。Prometheus不僅僅是一個容器監控工具，它在雲原生應用程序公司中最受歡迎。此外，其它開源監控工具，包括Grafana，可以對接Prometheus。

開始Prometheus最好的辦法是訪問它的GitHub代碼倉庫，本地運行Prometheus是很容易的，但是必須提前有一個容器引擎。用戶可以在Prometheus的官網獲取更詳細文檔。

3、Envoy

Envoy（或Envoy Proxy）是一個開源的邊緣和服務代理。由LyFT創建的Envoy是一個由C++編寫的，高性能，分佈式代理，專為單一服務和應用而設計，以及為大型微服務網格體系結構設計的通信總線和通用數據平面。基於對Nginx、HAProxy、硬件負載均衡器和雲負載均衡器等解決方案的學習，Envoy與每個應用程序一起運行，並通過以平臺無感知的方式提供公共特性來抽象網絡。

當一個基礎設施中的所有服務流量都通過一個Envoy mesh流動時，通過一致的可觀測性，調整整體性能，並在一個地方添加底層特性，就可以很容易地觀察問題區域。基本上，Envoy Proxy是一個Service Mesh工具，幫助組織為生產環境構建容錯系統。

ServiceMesh應用程序有許多替代方案，例如Uber的Linkerd（下面討論）和Isito。Istio通過部署為Sidecar並利用Mixer配置模型來擴展Envoy Proxy。Envoy的顯著特點是：

• 包含所有該支持的功能（當搭配控制平面，如Istio的時候）
• 在負載情況下消耗資源量很低
• 在其核心處充當L3/L4過濾，並且可以提供許多不可思議的L7過濾
• 支持GRPC和HTTP/2（上游/下游）
• 它是API驅動的，支持動態配置和熱重加載
• 重點關注度量收集、跟蹤和整體可觀測性

想要了解Envoy更多，發揮它的能力，並實現其全部優勢，用戶需要在運行生產級環境方面有豐富的經驗。訪問Envoy的GitHub代碼倉庫，閱讀文檔，用戶可以瞭解更詳細信息。

二、“孵化”階段項目

下面是六個最受歡迎的開源CNCF孵化項目

1、rkt

rkt，發音為“rocket”，是一種pod-native引擎。它有一個命令行界面（cli），用於在Linux上運行容器。在某種意義上，它類似於其他容器，如：Podman、Docker和CRI-O。

rkt最初是由CoreOS開發的（後來被Red Hat收購），您可以在其網站上找到詳細的文檔並訪問Github上的源代碼。

2、Jaeger

Jaeger是一個開源、端到端的分佈式跟蹤系統，用於雲原生應用程序。在某種程度上，它是Prometheus這樣的監控解決方案。但是它是不同的，因為它的用例擴展到：

• 分佈式事務監視
• 性能和延遲優化
• 根本原因分析
• 服務依賴性分析
• 分佈式上下文傳播

Jaeger是一種由Uber構建的開源技術。您可以在其網站上找到詳細的文檔，並在GitHub上找到其源代碼。

3、Linkerd

與Envoy Proxy的Lyft一樣，Uber將Linkerd開發為一個開源解決方案，以將其服務保持在生產級別。在某些方面，Linkerd就像Envoy一樣，因為兩者都是Service Mesh工具，用以在不需要配置或代碼更改的情況下提供平臺範圍的可觀測性、可靠性和安全性。

然而，兩者之間有一些細微的差別。雖然Envoy和Linkerd作為代理，可以在連接的服務上報告，但Envoy並不像Linkerd那樣被設計成Kubernetes入口控制器。Linkerd的顯著特點包括：

• 支持多種平臺（Docker、Kubernetes、DC/OS、Amazon ECS或任何單機）
• 用於統一多個系統的內置服務發現抽象
• 支持GRPC、HTTP/2和HTTP/1.x請求以及所有TCP通信

您可以在Linkerd的網站上閱讀更多關於它的信息，並在GitHub上訪問它的源代碼。

4、Helm

Helm基本上是Kubernetes的包管理器。如果您使用過ApacheMaven、MavenNexus或類似的服務，您將瞭解Helm的目的。Helm幫助您管理Kubernetes應用程序。它使用“helm charts”定義、安裝和升級最複雜的Kubernetes應用程序。Helm並不是實現這一點的唯一方法；另一個流行的概念是KubernetesOperators，它由RedHat Openshift4使用。

您可以按照文檔中的快速入門指南（https://github.com/helm/helm）或Github指南來嘗試Helm。

5、Etcd

Etcd是一個分佈式的、可靠的鍵值對數據存儲，用於存儲分佈式系統中最關鍵的數據。其主要特點是：

• 定義明確、面向用戶的API（gRPC）
• 具有可選客戶端證書身份驗證的自動TLS
• 速度（以每秒10000次寫入為基準）
• 可靠性（採用Raft分佈式）

Etcd被用作Kubernetes和許多其他技術的內置默認數據存儲。也就是說，它很少獨立運行或作為單獨的服務運行；相反，它使用集成到Kubernetes、OKD/OpenShift或其他服務中的服務。還有一個Etcd運營商來管理其生命週期並解鎖其API管理功能：

您可以在ETCD的文檔中瞭解更多信息，並在Github上訪問其源代碼。

6、CRI-O

CRI-O是一個開放容器聯盟（OCI）兼容的Kubernetes運行時接口的實現。CRI-O用於各種功能，包括：

• 運行時使用runc（或任何OCI運行時規範實現）和OCI運行時工具
• 使用容器/圖像進行圖像管理
• 使用容器/存儲器存儲和管理圖像層
• 通過容器網絡接口（CNI）提供網絡支持

CRI-O提供了大量文檔，包括指南、教程、文章甚至播客，您還可以訪問其Github頁面（https://github.com/cri-o/cri-o）。

原文鏈接：

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

譯者介紹：

ArthurGuo 職場老司機。21世紀初開始擁抱開源，後轉型項目管理。現在某雲計算公司擔任技術總監。掌握多門計算機語言，但更擅長人類語言。愛玩文字，不喜毒舌。