[[276535]]

　　使用容器嗎？來熟悉一下云原生計(jì)算基金會(huì)上的這些項(xiàng)目。

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

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

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

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

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

云原生計(jì)算基金會(huì)項(xiàng)目圖

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

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

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

CNCF 成熟度模型

　　1）沙盒階段

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

　　2）孵化階段

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

　　要進(jìn)入孵化階段，項(xiàng)目必須滿足沙盒階段的要求，并加上：

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

　　3）畢業(yè)階段

　　能從“沙盒”或者“孵化”達(dá)到“畢業(yè)”階段的項(xiàng)目，或者一個(gè)直接就進(jìn)入到“畢業(yè)”階段的項(xiàng)目，項(xiàng)目必須符合孵化階段標(biāo)準(zhǔn)，以及如下條件：

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

　　9 個(gè)值得考慮的項(xiàng)目

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

項(xiàng)目	License	簡(jiǎn)介
Kubernetes	Apache 2.0	容器編排平臺(tái)
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 存儲(chǔ)
CRI-O	Apache 2.0	輕量級(jí) Kubernetes 運(yùn)行時(shí)間管理

　　一、畢業(yè)的項(xiàng)目

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

　　1、Kubernetes

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

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

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

　　可以從閱讀 Kubernetes 的 Github 倉(cāng)庫(kù)開始，在 Kubernetes Documents 站點(diǎn)網(wǎng)頁(yè)訪問文檔學(xué)習(xí)資源。

　　2、Prometheus

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

Prometheus 架構(gòu)

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

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

　　3、Envoy

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

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

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

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

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

　　二、“孵化”階段項(xiàng)目

　　下面是六個(gè)非常受歡迎的開源 CNCF 孵化項(xiàng)目

　　1、rkt

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

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

　　2、Jaeger

　　Jaeger 是一個(gè)開源、端到端的分布式跟蹤系統(tǒng)，用于云原生應(yīng)用程序。在某種程度上，它是 Prometheus 這樣的監(jiān)控解決方案。但是它是不同的，因?yàn)樗挠美龜U(kuò)展到：

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

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

　　3、Linkerd

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

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

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

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

　　4、Helm

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

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

　　5、Etcd

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

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

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

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

　　6、CRI-O

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

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

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

　　原文鏈接：

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

　　譯者介紹：

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