隨著用容器來(lái)開(kāi)發(fā)應(yīng)用的實(shí)踐變得流行，云原生應(yīng)用也在增長(zhǎng)。云原生應(yīng)用的定義為：

這個(gè)定義提到了構(gòu)成云原生應(yīng)用的不可或缺的四個(gè)元素：

• 容器
• 微服務(wù)
• DevOps
• 持續(xù)集成和持續(xù)交付 (CI/CD)

盡管這些技術(shù)各有各自獨(dú)特的歷史，但它們之間卻相輔相成，在短時(shí)間內(nèi)實(shí)現(xiàn)了云原生應(yīng)用和工具的驚人的指數(shù)級(jí)增長(zhǎng)。這個(gè)云原生計(jì)算基金會(huì)(CNCF)信息圖呈現(xiàn)了當(dāng)今云原生應(yīng)用生態(tài)的規(guī)模和廣度。

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

我想說(shuō)，瞧著吧!這僅僅是一個(gè)開(kāi)始。正如 NodeJS 的出現(xiàn)引發(fā)了無(wú)數(shù)的 JavaScript 工具的爆炸式增長(zhǎng)一樣，容器技術(shù)的普及也推動(dòng)了云原生應(yīng)用的指數(shù)增長(zhǎng)。

好消息是，有幾個(gè)組織負(fù)責(zé)監(jiān)管并將這些技術(shù)連接在一起。其中之一是 開(kāi)放容器倡議(Open Containers Initiative)(OCI)，它是一個(gè)輕量級(jí)的、開(kāi)放的治理機(jī)構(gòu)(或項(xiàng)目)，“它是在 Linux 基金會(huì)的支持下形成的，其明確目的是創(chuàng)建開(kāi)放的行業(yè)標(biāo)準(zhǔn)的容器格式和運(yùn)行時(shí)。” 另一個(gè)是 CNCF，它是“一個(gè)致力于使云原生計(jì)算普及和可持續(xù)發(fā)展的開(kāi)源軟件基金會(huì)”。

通常除了圍繞云原生應(yīng)用建立社區(qū)之外，CNCF 還幫助項(xiàng)目圍繞其云原生應(yīng)用建立結(jié)構(gòu)化管理。CNCF 創(chuàng)建了成熟等級(jí)的概念(沙箱級(jí)、孵化級(jí)或畢業(yè)級(jí))，分別與下圖中的“創(chuàng)新者”、“早期采用者”和“早期大量應(yīng)用”相對(duì)應(yīng)。

CNCF 項(xiàng)目成熟等級(jí)

CNCF 為每個(gè)成熟等級(jí)制定了詳細(xì)的標(biāo)準(zhǔn)(為方便讀者而列在下面)。獲得技術(shù)監(jiān)督委員會(huì)(TOC)三分之二的同意才能轉(zhuǎn)為孵化或畢業(yè)級(jí)。

沙箱級(jí)

要想成為沙箱級(jí)，一個(gè)項(xiàng)目必須至少有兩個(gè) TOC 贊助商。有關(guān)詳細(xì)過(guò)程，請(qǐng)參見(jiàn)《CNCF 沙箱指南 v1.0》。

孵化級(jí)

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

要進(jìn)入孵化級(jí)，項(xiàng)目除了滿足沙箱級(jí)的要求之外還要滿足：

• 證明至少有三個(gè)獨(dú)立的最終用戶已成功將其用于生產(chǎn)，且 TOC 判斷這些最終用戶具有足夠的質(zhì)量和范圍。
• 提交者的數(shù)量要合理。提交者定義為具有提交權(quán)的人，即可以接受部分或全部項(xiàng)目貢獻(xiàn)的人。
• 顯示出有大量持續(xù)提交和合并貢獻(xiàn)。
• 由于這些指標(biāo)可能會(huì)根據(jù)項(xiàng)目的類型、范圍和大小而有很大差異，所以 TOC 有權(quán)決定是否滿足這些標(biāo)準(zhǔn)的活動(dòng)水平。

畢業(yè)級(jí)

要從沙箱或孵化級(jí)畢業(yè)，或者要使一個(gè)新項(xiàng)目作為已畢業(yè)項(xiàng)目加入，項(xiàng)目除了必須滿足孵化級(jí)的標(biāo)準(zhǔn)外還要滿足：

• 至少有兩個(gè)來(lái)自組織的提交者。
• 已獲得并保持了“核心基礎(chǔ)設(shè)施計(jì)劃最佳實(shí)踐徽章”。
• 已完成獨(dú)立的第三方安全審核，并發(fā)布了具有與以下示例類似的范圍和質(zhì)量的結(jié)果(包括已解決的關(guān)鍵漏洞)：https://github.com/envoyproxy/envoy#security-audit，并在畢業(yè)之前需要解決所有關(guān)鍵的漏洞。
• 采用《CNCF 行為準(zhǔn)則》。
• 明確規(guī)定項(xiàng)目治理和提交流程。最好將其列在 GOVERNANCE.md 文件中，并引用顯示當(dāng)前提交者和榮譽(yù)提交者的 OWNERS.md 文件。
• 至少有一個(gè)主倉(cāng)的項(xiàng)目采用者的公開(kāi)列表(例如，ADOPTERS.md 或項(xiàng)目網(wǎng)站上的徽標(biāo))。
• 獲得 TOC 的絕大多數(shù)票，進(jìn)入畢業(yè)階段。如果項(xiàng)目能夠表現(xiàn)出足夠的成熟度，則可以嘗試直接從沙箱級(jí)過(guò)渡到畢業(yè)級(jí)。項(xiàng)目可以無(wú)限期保持孵化狀態(tài)，但是通常預(yù)計(jì)它們會(huì)在兩年內(nèi)畢業(yè)。

值得關(guān)注的 9 個(gè)項(xiàng)目

本文不可能涵蓋所有的 CNCF 項(xiàng)目，我將介紹最有趣的 9 個(gè)畢業(yè)和孵化的開(kāi)源項(xiàng)目。

畢業(yè)項(xiàng)目

畢業(yè)的項(xiàng)目被認(rèn)為是成熟的，已被許多組織采用的，并且嚴(yán)格遵守了 CNCF 的準(zhǔn)則。以下是三個(gè)最受歡迎的開(kāi)源 CNCF 畢業(yè)項(xiàng)目。(請(qǐng)注意，其中一些描述來(lái)源于項(xiàng)目的網(wǎng)站并被做了改編。)

1. Kubernetes(希臘語(yǔ)“舵手”)

Kubernetes! 說(shuō)起云原生應(yīng)用，怎么能不提 Kubernetes 呢?Google 發(fā)明的 Kubernetes 無(wú)疑是最著名的基于容器的應(yīng)用程序的容器編排平臺(tái)，而且它還是一個(gè)開(kāi)源工具。

什么是容器編排平臺(tái)?通常，一個(gè)容器引擎本身可以管理幾個(gè)容器。但是，當(dāng)你談?wù)摂?shù)千個(gè)容器和數(shù)百個(gè)服務(wù)時(shí)，管理這些容器變得非常復(fù)雜。這就是容器編排引擎的用武之地。容器編排引擎通過(guò)自動(dòng)化容器的部署、管理、網(wǎng)絡(luò)和可用性來(lái)幫助管理大量的容器。

Docker Swarm 和 Mesosphere Marathon 也是容器編排引擎，但是可以肯定地說(shuō)，Kubernetes 已經(jīng)贏得了這場(chǎng)比賽(至少現(xiàn)在是這樣)。Kubernetes 還催生了像 OKD 這樣的容器即服務(wù)(CaaS)平臺(tái)，它是 Kubernetes 的 Origin 社區(qū)發(fā)行版，并成了 Red Hat OpenShift 的一部分。

想開(kāi)始學(xué)習(xí)，請(qǐng)?jiān)L問(wèn) Kubernetes GitHub 倉(cāng)庫(kù)，并從 Kubernetes 文檔頁(yè)面訪問(wèn)其文檔和學(xué)習(xí)資源。

2. Prometheus(普羅米修斯)

Prometheus 是 2012 年在 SoundCloud 上構(gòu)建的一個(gè)開(kāi)源的系統(tǒng)監(jiān)控和告警工具。之后，許多公司和組織都采用了 Prometheus，并且該項(xiàng)目擁有非?；钴S的開(kāi)發(fā)者和用戶群體。現(xiàn)在，它已經(jīng)成為一個(gè)獨(dú)立的開(kāi)源項(xiàng)目，獨(dú)立于公司之外進(jìn)行維護(hù)。

Prometheus 的架構(gòu)理解 Prometheus 的最簡(jiǎn)單方法是可視化一個(gè)生產(chǎn)系統(tǒng)，該系統(tǒng)需要 24(小時(shí))x 365(天)都可以正常運(yùn)行。沒(méi)有哪個(gè)系統(tǒng)是完美的，也有減少故障的技術(shù)(稱為容錯(cuò)系統(tǒng))，但是，如果出現(xiàn)問(wèn)題，最重要的是盡快發(fā)現(xiàn)問(wèn)題。這就是像 Prometheus 這樣的監(jiān)控工具的用武之地。Prometheus 不僅僅是一個(gè)容器監(jiān)控工具，但它在云原生應(yīng)用公司中最受歡迎。此外，其他開(kāi)源監(jiān)視工具，包括 Grafana，都借助了 Prometheus。

開(kāi)始使用 Prometheus 的最佳方法是下載其 GitHub 倉(cāng)庫(kù)。在本地運(yùn)行 Prometheus 很容易，但是你需要安裝一個(gè)容器引擎。你可以在 Prometheus 網(wǎng)站上查看詳細(xì)的文檔。

3. Envoy(使者)

Envoy(或 Envoy 代理)是專為云原生應(yīng)用設(shè)計(jì)的開(kāi)源的邊緣代理和服務(wù)代理。由 Lyft 創(chuàng)建的 Envoy 是為單一服務(wù)和應(yīng)用而設(shè)計(jì)的高性能的 C++ 開(kāi)發(fā)的分布式代理，同時(shí)也是為由大量微服務(wù)組成的服務(wù)網(wǎng)格架構(gòu)而設(shè)計(jì)的通信總線和通用數(shù)據(jù)平面。Envoy 建立在 Nginx、HAProxy、硬件負(fù)載均衡器和云負(fù)載均衡器等解決方案的基礎(chǔ)上，Envoy 與每個(gè)應(yīng)用相伴(并行)運(yùn)行，并通過(guò)提供平臺(tái)無(wú)關(guān)的方式提供通用特性來(lái)抽象網(wǎng)絡(luò)。

當(dāng)基礎(chǔ)設(shè)施中的所有服務(wù)流量都經(jīng)過(guò) Envoy 網(wǎng)格時(shí)，很容易就可以通過(guò)一致的可觀測(cè)性來(lái)可視化問(wèn)題域，調(diào)整整體性能，并在單個(gè)位置添加基礎(chǔ)功能?；旧?，Envoy 代理是一個(gè)可幫助組織為生產(chǎn)環(huán)境構(gòu)建容錯(cuò)系統(tǒng)的服務(wù)網(wǎng)格工具。

服務(wù)網(wǎng)格應(yīng)用有很多替代方案，例如 Uber 的 Linkerd(下面會(huì)討論)和 Istio。Istio 通過(guò)將其部署為 Sidecar 并利用了 Mixer 的配置模型，實(shí)現(xiàn)了對(duì) Envoy 的擴(kuò)展。Envoy 的顯著特性有：

• 包括所有的“入場(chǎng)籌碼(table stakes)(LCTT 譯注：引申為基礎(chǔ)必備特性)”特性(與 Istio 這樣的控制平面組合時(shí))
• 帶載運(yùn)行時(shí) 99% 數(shù)據(jù)可達(dá)到低延時(shí)
• 可以作為核心的 L3/L4 過(guò)濾器，提供了開(kāi)箱即用的 L7 過(guò)濾器
• 支持 gRPC 和 HTTP/2(上行/下行)
• 由 API 驅(qū)動(dòng)，并支持動(dòng)態(tài)配置和熱重載
• 重點(diǎn)關(guān)注指標(biāo)收集、跟蹤和整體可監(jiān)測(cè)性

要想了解 Envoy，證實(shí)其能力并實(shí)現(xiàn)其全部?jī)?yōu)勢(shì)，需要豐富的生產(chǎn)級(jí)環(huán)境運(yùn)行的經(jīng)驗(yàn)。你可以在其詳細(xì)文檔或訪問(wèn)其 GitHub 倉(cāng)庫(kù)了解更多信息。

孵化項(xiàng)目

下面是六個(gè)最流行的開(kāi)源的 CNCF 孵化項(xiàng)目。

4. rkt(火箭)

rkt, 讀作“rocket”，是一個(gè) Pod 原生的容器引擎。它有一個(gè)命令行接口用來(lái)在 Linux 上運(yùn)行容器。從某種意義上講，它和其他容器如 Podman、Docker 和 CRI-O 相似。

rkt 最初是由 CoreOS (后來(lái)被 Red Hat 收購(gòu))開(kāi)發(fā)的，你可以在其網(wǎng)站上找到詳細(xì)的文檔，以及在 GitHub 上訪問(wèn)其源代碼。

5. Jaeger(賊鷗)

Jaeger 是一個(gè)開(kāi)源的端到端的分布式追蹤系統(tǒng)，適用于云端應(yīng)用。在某種程度上，它是像 Prometheus 這樣的監(jiān)控解決方案。但它有所不同，因?yàn)槠涫褂脠?chǎng)景有所擴(kuò)展：

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

Jaeger 是一項(xiàng) Uber 打造的開(kāi)源技術(shù)。你可以在其網(wǎng)站上找到詳細(xì)文檔，以及在 GitHub 上找到其源碼。

6. Linkerd

像創(chuàng)建 Envoy 代理的 Lyft 一樣，Uber 開(kāi)發(fā)了 Linkerd 開(kāi)源解決方案用于生產(chǎn)級(jí)的服務(wù)維護(hù)。在某些方面，Linkerd 就像 Envoy 一樣，因?yàn)閮烧叨际欠?wù)網(wǎng)格工具，旨在提供平臺(tái)級(jí)的可觀測(cè)性、可靠性和安全性，而無(wú)需進(jìn)行配置或代碼更改。

但是，兩者之間存在一些細(xì)微的差異。盡管 Envoy 和 Linkerd 充當(dāng)代理并可以通過(guò)所連接的服務(wù)進(jìn)行上報(bào)，但是 Envoy 并不像 Linkerd 那樣被設(shè)計(jì)為 Kubernetes Ingress 控制器。Linkerd 的顯著特點(diǎn)包括：

• 支持多種平臺(tái)(Docker、Kubernetes、DC/OS、Amazon ECS 或任何獨(dú)立的機(jī)器)
• 內(nèi)置服務(wù)發(fā)現(xiàn)抽象，可以將多個(gè)系統(tǒng)聯(lián)合在一起
• 支持 gRPC、HTTP/2 和 HTTP/1.x請(qǐng) 求和所有的 TCP 流量

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

7. Helm(舵輪)

Helm 基本上就是 Kubernetes 的包管理器。如果你使用過(guò) Apache Maven、Maven Nexus 或類似的服務(wù)，你就會(huì)理解 Helm 的作用。Helm 可幫助你管理 Kubernetes 應(yīng)用程序。它使用“Helm Chart”來(lái)定義、安裝和升級(jí)最復(fù)雜的 Kubernetes 應(yīng)用程序。Helm 并不是實(shí)現(xiàn)此功能的唯一方法;另一個(gè)流行的概念是 Kubernetes Operators，它被 Red Hat OpenShift 4 所使用。

你可以按照其文檔中的快速開(kāi)始指南或 GitHub 指南來(lái)試用 Helm。

8. Etcd

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

• 定義明確的、面向用戶的 API(gRPC)
• 自動(dòng) TLS，可選的客戶端證書(shū)驗(yàn)證
• 速度(可達(dá)每秒 10,000 次寫(xiě)入)
• 可靠性(使用 Raft 實(shí)現(xiàn)分布式)

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

你可以在 etcd 文檔中了解更多信息，并在 GitHub上訪問(wèn)其源碼。

9. CRI-O

CRI-O 是 Kubernetes 運(yùn)行時(shí)接口的 OCI 兼容實(shí)現(xiàn)。CRI-O 用于各種功能，包括：

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

CRI-O 提供了大量的文檔，包括指南、教程、文章，甚至播客，你還可以訪問(wèn)其 GitHub 頁(yè)面。