[[276535]]

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

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

“云原生技術用于開發應用程序，這些應用程序使用封裝在容器中的服務構建，部署為微服務，并通過敏捷的 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 個有趣的處于“畢業”階段和“孵化”階段的開源項目。

項目	License	簡介
Kubernetes	Apache 2.0	容器編排平臺
Prometheus	Apache 2.0	系統和服務監控工具
Envoy	Apache 2.0	服務代理
rkt	Apache 2.0	Pod 原生容器引擎
Jaeger	Apache 2.0	分布式跟蹤系統
Linkerd	Apache 2.0	透明的 service mesh
Helm	Apache 2.0	Kubernetes 包管理
Etcd	Apache 2.0	分布式 key-value 存儲
CRI-O	Apache 2.0	輕量級 Kubernetes 運行時間管理

　　一、畢業的項目

　　“畢業”階段項目被許多組織認為是成熟的，必須遵守 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 世紀初開始擁抱開源，后轉型項目管理。現在某云計算公司擔任技術總監。掌握多門計算機語言，但更擅長人類語言。愛玩文字，不喜毒舌。