[[276535]]

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

　　隨著使用容器開發(fā)應(yīng)用程序的實踐越來越流行，云本地應(yīng)用程序也在不斷增加。根據(jù)定義：

“云原生技術(shù)用于開發(fā)應(yīng)用程序，這些應(yīng)用程序使用封裝在容器中的服務(wù)構(gòu)建，部署為微服務(wù)，并通過敏捷的 DevOps 流程和持續(xù)交付工作流在彈性基礎(chǔ)設(shè)施上進行管理。”

　　該描述包括四個元素，這些元素與云原生應(yīng)用程序是一體的：

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

　　盡管這些技術(shù)有著非常獨特的歷史，但它們相互補充得很好，并在短時間內(nèi)導(dǎo)致云原生應(yīng)用程序和工具集的指數(shù)級增長。這張云原生計算基金會（CNCF）的信息圖表顯示了云原生應(yīng)用生態(tài)系統(tǒng)的大小和廣度。

云原生計算基金會項目圖

　　我是說，看看這個！這只是一個開始。正如 Node.JS 的創(chuàng)建引發(fā)了無休止的 JavaScript 工具的爆炸，容器技術(shù)的流行開始了云本地應(yīng)用程序的指數(shù)級增長。

　　好消息是有幾個組織負責監(jiān)督和連接這些點。一個是開放容器聯(lián)盟（OCI），它是一個輕量級的開放式治理結(jié)構(gòu)（或項目），在 Linux 基金會的支持下形成的。OCI 目的是圍繞容器格式和運行時間創(chuàng)建開放的工業(yè)標準。另一個是 CNCF，“一個開源軟件基金會致力于使云原生計算普及和可持續(xù)。”

　　除了一般圍繞云本機應(yīng)用程序構(gòu)建社區(qū)之外，CNCF 還幫助項目圍繞其云本機應(yīng)用程序建立結(jié)構(gòu)化治理。CNCF 創(chuàng)建了成熟度級別“沙盒”、“孵化”或“畢業(yè)”的概念，與下圖中的創(chuàng)新者、早期采用者和早期多數(shù)層相對應(yīng)。

CNCF 成熟度模型

　　1）沙盒階段

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

　　2）孵化階段

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

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

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

　　3）畢業(yè)階段

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

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

　　9 個值得考慮的項目

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

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

　　一、畢業(yè)的項目

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

　　1、Kubernetes

　　啊，Kubernetes。我們?nèi)绾卧诓惶岬?Kubernetes 的情況下談?wù)撛圃鷳?yīng)用程序？Kubernetes 無疑是 Google 發(fā)明的非常著名的基于容器的應(yīng)用程序的容器編排平臺，也是一個開源工具。

　　什么是容器編排平臺？基本上，一個獨立的容器引擎可以管理幾個容器。然而，當您談?wù)摂?shù)千個容器和數(shù)百個服務(wù)時，管理這些容器變得非常復(fù)雜。這就是容器引擎的切入點。容器編排引擎通過自動化容器的部署、管理、聯(lián)網(wǎng)和可用性來幫助擴展容器。

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

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

　　2、Prometheus

　　Prometheus 是一個開源系統(tǒng)監(jiān)控和警報工具包，于 2012 年在 SoundCloud 構(gòu)建。從那時起，許多公司和組織都采用了 Prometheus，并且這個項目有一個非?；钴S的開發(fā)人員和用戶社區(qū)。它現(xiàn)在是一個獨立的開源項目，獨立于公司進行維護。

Prometheus 架構(gòu)

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

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

　　3、Envoy

　　Envoy（或 Envoy Proxy）是一個開源的邊緣和服務(wù)代理。由 LyFT 創(chuàng)建的 Envoy 是一個由 C++ 編寫的，高性能，分布式代理，專為單一服務(wù)和應(yīng)用而設(shè)計，以及為大型微服務(wù)網(wǎng)格體系結(jié)構(gòu)設(shè)計的通信總線和通用數(shù)據(jù)平面?；趯?Nginx、HAProxy、硬件負載均衡器和云負載均衡器等解決方案的學習，Envoy 與每個應(yīng)用程序一起運行，并通過以平臺無感知的方式提供公共特性來抽象網(wǎng)絡(luò)。

　　當一個基礎(chǔ)設(shè)施中的所有服務(wù)流量都通過一個 Envoy mesh 流動時，通過一致的可觀測性，調(diào)整整體性能，并在一個地方添加底層特性，就可以很容易地觀察問題區(qū)域?；旧?，Envoy Proxy 是一個 Service Mesh 工具，幫助組織為生產(chǎn)環(huán)境構(gòu)建容錯系統(tǒng)。

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

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

　　想要了解 Envoy 更多，發(fā)揮它的能力，并實現(xiàn)其全部優(yōu)勢，用戶需要在運行生產(chǎn)級環(huán)境方面有豐富的經(jīng)驗。訪問 Envoy 的 GitHub 代碼倉庫，閱讀文檔，用戶可以了解更詳細信息。

　　二、“孵化”階段項目

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

　　1、rkt

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

　　rkt 最初是由 CoreOS 開發(fā)的（后來被 Red Hat 收購），您可以在其網(wǎng)站上找到詳細的文檔并訪問 Github 上的源代碼。

　　2、Jaeger

　　Jaeger 是一個開源、端到端的分布式跟蹤系統(tǒng)，用于云原生應(yīng)用程序。在某種程度上，它是 Prometheus 這樣的監(jiān)控解決方案。但是它是不同的，因為它的用例擴展到：

• 分布式事務(wù)監(jiān)視
• 性能和延遲優(yōu)化
• 根本原因分析
• 服務(wù)依賴性分析
• 分布式上下文傳播

　　Jaeger 是一種由 Uber 構(gòu)建的開源技術(shù)。您可以在其網(wǎng)站上找到詳細的文檔，并在 GitHub 上找到其源代碼。

　　3、Linkerd

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

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

• 支持多種平臺（Docker、Kubernetes、DC/OS、Amazon ECS 或任何單機）
• 用于統(tǒng)一多個系統(tǒng)的內(nèi)置服務(wù)發(fā)現(xiàn)抽象
• 支持 GRPC、HTTP/2 和 HTTP/1.x 請求以及所有 TCP 通信 

　　您可以在 Linkerd 的網(wǎng)站上閱讀更多關(guān)于它的信息，并在 GitHub 上訪問它的源代碼。

　　4、Helm

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

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

　　5、Etcd

　　Etcd 是一個分布式的、可靠的鍵值對數(shù)據(jù)存儲，用于存儲分布式系統(tǒng)中最關(guān)鍵的數(shù)據(jù)。其主要特點是：

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

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

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

　　6、CRI-O

　　CRI-O 是一個開放容器聯(lián)盟（OCI）兼容的 Kubernetes 運行時接口的實現(xiàn)。CRI-O 用于各種功能，包括：

• 運行時使用 runc（或任何 OCI 運行時規(guī)范實現(xiàn)）和 OCI 運行時工具
• 使用容器/圖像進行圖像管理
• 使用容器/存儲器存儲和管理圖像層
• 通過容器網(wǎng)絡(luò)接口（CNI）提供網(wǎng)絡(luò)支持

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

　　原文鏈接：

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

　　譯者介紹：

　　ArthurGuo 職場老司機。21 世紀初開始擁抱開源，后轉(zhuǎn)型項目管理。現(xiàn)在某云計算公司擔任技術(shù)總監(jiān)。掌握多門計算機語言，但更擅長人類語言。愛玩文字，不喜毒舌。