當(dāng)我們初接觸云原生技術(shù)時，可能會覺得它有些復(fù)雜和混亂。不過，我們可以先來了解一個開放，活力的軟件社區(qū)，即云原生計(jì)算基金會(CNCF)。它為數(shù)不清的云原生技術(shù)項(xiàng)目提供了持續(xù)不斷的支持和貢獻(xiàn)。而且，CNCF有一張涵蓋了全部云原生解決方案的全景圖，許多耳熟能詳?shù)捻?xiàng)目方案都包括在這張圖內(nèi)。

[[254613]]

我有幸成為CNCF的大使，致力于在加拿大推廣社區(qū)活動和云原生的教育。同時，在CloudOps社區(qū)， 我還帶領(lǐng)著Docker和Kubernetes研討會，向大家普及云原生技術(shù)，幫助DevOps團(tuán)隊(duì)實(shí)踐相關(guān)的技術(shù)應(yīng)用。

我也組織Kubernetes和云原生技術(shù)相關(guān)的會議，邀請了來自世界各地的演講者展示他們各種類型的技術(shù)項(xiàng)目。這些演講者在蒙特利爾、渥太華、多倫多、基奇納-滑鐵盧和魁北克市等地推動他們的項(xiàng)目運(yùn)行。大家通過電子郵件或在博客上@archyufaor的方式保持聯(lián)系。為他們提供云原生技術(shù)的信息咨詢。

同時，我還編寫了云原生技術(shù)的初學(xué)者指南。希望能幫助讀者理解這個領(lǐng)域并在這個領(lǐng)域取得更好的進(jìn)展。

CNCF的歷史背景

2014年，谷歌開源了一個主要用于容器編排的，名為博格(Borg)的內(nèi)部項(xiàng)目。由于沒有機(jī)構(gòu)來管理這個項(xiàng)目，谷歌就與Linux基金會聯(lián)合創(chuàng)建了旨在鼓勵Kubernetes和其他云原生解決方案的開發(fā)和協(xié)作的云原生計(jì)算基金會(CNCF)。而Borg項(xiàng)目就更名為Kubernetes，并用Go語言重寫了實(shí)現(xiàn)部分，成為了CNCF的啟動捐贈項(xiàng)目。毫無疑問地講，Kubernetes只是開始，后續(xù)有大批的新項(xiàng)目先后加入到CNCF，圍繞著Kubernetes不斷地?cái)U(kuò)展功能。

CNCF的使命

通過提供多種選項(xiàng)的開發(fā)軟件社區(qū)，幫助最終用戶構(gòu)建云原生應(yīng)用。從而培育云原生開源項(xiàng)目的生態(tài)體系。CNCF鼓勵項(xiàng)目之間的相互協(xié)作，希望實(shí)現(xiàn)完全由CNCF成員項(xiàng)目演化出來的成熟技術(shù)棧。這便是CNCF在云端的自我使命。

CNCF的歷程

目前共有25個項(xiàng)目已經(jīng)被CNCF接受，在跟進(jìn)Kubernetes生態(tài)發(fā)展。希望加入到CNCF的項(xiàng)目，必須是由技術(shù)監(jiān)督委員會(TOC)選定并通過投票評比，取得絕大多數(shù)的投票認(rèn)同才可以加入。投票過程由TOC貢獻(xiàn)者組成的一個優(yōu)秀社區(qū)來輔助進(jìn)行，而TOC貢獻(xiàn)者是來自CNCF成員公司的代表，我有幸也是其中一位。評選通過的項(xiàng)目就叫CNCF成員項(xiàng)目，CNCF將根據(jù)成員項(xiàng)目代碼成熟度級別分別定義為沙箱、孵化或畢業(yè)階段。

沙箱階段

這個階段的項(xiàng)目非常早期，在部署到生產(chǎn)環(huán)境之前，需要顯著地提升代碼成熟度，積極參與開源社區(qū)的互動。項(xiàng)目之所以被選中，主要是因?yàn)樗鼈兙邆涞臐摿κ巧鐓^(qū)所沒有的。在CNCF的指南中提到，CNCF將幫助推動沙箱項(xiàng)目的公共可見性，并促進(jìn)其與現(xiàn)有項(xiàng)目形成體系。但沙箱項(xiàng)目從CNCF獲得的資金和營銷支持非常少，并且每12個月都要接受審查，發(fā)展不夠好的項(xiàng)目可能會被淘汰掉。

孵化階段

當(dāng)項(xiàng)目滿足所有沙箱標(biāo)準(zhǔn)并具備明顯的增長和成熟度特征時，它們就進(jìn)入孵化階段。這時，它們必須至少在三家公司的生產(chǎn)環(huán)境中使用過，具備穩(wěn)定的團(tuán)隊(duì)，確保穩(wěn)定提供對社區(qū)的貢獻(xiàn)，包括處理來自社區(qū)的新功能和代碼要求等。

畢業(yè)階段

孵化項(xiàng)目一旦達(dá)到生產(chǎn)使用的臨界點(diǎn)，TOC就可以投票決定項(xiàng)目是否進(jìn)入畢業(yè)階段。畢業(yè)的項(xiàng)目必須證明有很高的采用率，并滿足所有孵化標(biāo)準(zhǔn)。項(xiàng)目的提交者必須至少來自2個不同的組織，具有文檔化和結(jié)構(gòu)化的管理流程，并滿足Linux基金會核心基礎(chǔ)設(shè)施計(jì)劃的最佳實(shí)踐徽章要求。截止到目前，只有Kubernetes和Prometheus兩個畢業(yè)項(xiàng)目。

CNCF項(xiàng)目介紹

我將CNCF成員項(xiàng)目劃分了12個類別，分別是：編排、應(yīng)用程序開發(fā)、監(jiān)控、日志記錄、跟蹤、容器注冊、存儲和數(shù)據(jù)庫、運(yùn)行時間、服務(wù)發(fā)現(xiàn)、服務(wù)網(wǎng)格、服務(wù)代理、安全以及數(shù)據(jù)流和消息流。我希望所提供的信息能夠幫助公司或個人評估每個項(xiàng)目做什么，如何演化的，以及如何與其他CNCF項(xiàng)目集成等。

編排 

Kubernetes

Kubernetes(已畢業(yè))—— Kubernetes這個單詞在古希臘語是舵手的意思。強(qiáng)調(diào)自動化和聲明性配置，可自動化完成容器化應(yīng)用的部署、伸縮和管理。Kubernetes進(jìn)行容器編排，而所編排的容器是可移植和模塊化的微服務(wù)包。它為應(yīng)用添加了一個抽象層，將容器分組運(yùn)行在Pod中，從而實(shí)現(xiàn)容器的編排。Kubernetes可以幫助運(yùn)維人員進(jìn)行工作負(fù)載排期，并允許容器在多云環(huán)境中大規(guī)模部署。Kubernetes在畢業(yè)后被廣泛應(yīng)用，CNCF的調(diào)查顯示，超過40%的企業(yè)受訪者在生產(chǎn)過程中使用了Kubernetes。

應(yīng)用程序開發(fā) 

Helm

Helm(孵化階段)——Helm是程序包管理器，以chart的形式讓用戶輕松地查找、共享、安裝和升級Kubernetes應(yīng)用。幫助終端用戶使用KubeApps Hub部署已有應(yīng)用(包括MySQL、Jenkins、Artifactory等)。KubeApps Hub能夠列出由Kubernetes社區(qū)維護(hù)的穩(wěn)定庫和孵化庫中的全部chart。通過Helm，用戶可以安裝Kubernetes之上的所有CNCF項(xiàng)目。并且還可以讓企業(yè)在Kubernetes上創(chuàng)建和部署自定義的應(yīng)用程序或微服務(wù)。當(dāng)然，這會涉及到創(chuàng)建YAML清單，根據(jù)不同的環(huán)境或CI/CD流程匹配不同的部署參數(shù)等情況。Helm所創(chuàng)建的單個chart，可以基于應(yīng)用程序或配置更改來進(jìn)行版本控制，可以部署在各種環(huán)境中，還可以進(jìn)行跨組織共享。

Helm項(xiàng)目最開始來源于為Kubernetes用戶創(chuàng)建自定義體驗(yàn)的Deis項(xiàng)目。早期的Helm版本只有客戶端，但后來Deis與谷歌合作在Helm V2版本中添加了服務(wù)端‘tiller’，與Kubernetes 1.2同期發(fā)布。這就使得Helm成為在Kubernetes之上部署應(yīng)用的標(biāo)準(zhǔn)方式。

Helm目前正在2018年年底Helm V3發(fā)布進(jìn)行一系列的更改和更新。對于依靠Helm進(jìn)行日常CI/CD開發(fā)的公司，包括Reddit、Ubisoft和Nike，我建議他們按照新的設(shè)計(jì)進(jìn)行優(yōu)化調(diào)整。

Telepresence

Telepresence(沙箱階段)——雖然在私有云容器應(yīng)用開發(fā)方面，有包括Docker Compose和Minikube在內(nèi)的流行工具。但在Kubernetes上開發(fā)容器化應(yīng)用程序仍然非常具有挑戰(zhàn)性。因?yàn)?，目前大多?shù)云原生應(yīng)用都是資源密集型的，并且涉及多個數(shù)據(jù)庫、服務(wù)和依賴項(xiàng)。此外，模擬云依賴關(guān)系非常復(fù)雜，例如在Docker Compose和Minikube中與消息傳遞系統(tǒng)和數(shù)據(jù)庫的依賴關(guān)系就是一個復(fù)雜的事情。這里有一個可參考方案，就是使用完全遠(yuǎn)程的Kubernetes集群，但是這方案會影響IDE、調(diào)試器等本地開發(fā)工具的應(yīng)用，并且會導(dǎo)致開發(fā)人員出現(xiàn)等待CI去進(jìn)行測試更改之類的“內(nèi)部循環(huán)”效應(yīng)。

由Datawire開發(fā)的Telepresence在上述設(shè)想方面提供了不錯的解決方案。它允許開發(fā)人員因開發(fā)需要在本地運(yùn)行單個微服務(wù)，同時保持與運(yùn)行在遠(yuǎn)端Kubernetes集群上的其余部分應(yīng)用的連接，我們稱之為 “實(shí)時代碼”。Telepresence在遠(yuǎn)端Kubernetes集群上部署了包含雙向網(wǎng)絡(luò)代理的Pod。將本地機(jī)器連接到網(wǎng)絡(luò)代理。實(shí)現(xiàn)了部署真實(shí)的開發(fā)/測試環(huán)境，而無需凍結(jié)用于編碼、調(diào)試和編輯的本地工具。

監(jiān)控 

Prometheus

Prometheus(已畢業(yè))——類同于Kubernetes的歷程，Prometheus是第二個加入到CNCF的項(xiàng)目，也是第二個畢業(yè)的項(xiàng)目。它是一個適合動態(tài)云環(huán)境和容器環(huán)境的監(jiān)視解決方案。靈感來自于谷歌的Borgman監(jiān)控系統(tǒng)。Prometheus完全是拉取式系統(tǒng)，通過配置決定了什么時候拉取什么數(shù)據(jù)。而不同于通過agent推送數(shù)據(jù)的push式監(jiān)視系統(tǒng)。Prometheus將拉取的指標(biāo)存儲在TSDB中。允許用戶使用PromSOL類查詢語言抽取數(shù)據(jù)在Grafana儀表板內(nèi)進(jìn)行圖形展示。用戶還可以使用內(nèi)置的警報(bào)管理器生成警報(bào)并以slack和電子郵件的方式發(fā)送給各種目標(biāo)。

Prometheus的成功讓它已經(jīng)成為了云原生監(jiān)控的事實(shí)性標(biāo)準(zhǔn)。通過Prometheus，用戶可以監(jiān)控VM、Kubernetes集群和運(yùn)行在任何地方的微服務(wù)，尤其適應(yīng)像Kubernetes這樣的動態(tài)系統(tǒng)。Prometheus的度量指標(biāo)還可以利用Kubernetes的HPA、VPA和集群自動伸縮等功能來進(jìn)行自動伸縮決策。也支持對其他的CNCF項(xiàng)目的監(jiān)控，如Rook、Vitesse、Envoy、Linkerd、CoreDNS、Fluentd和NATS。Prometheus的輸出集成了許多其他應(yīng)用和分布式系統(tǒng)。我建議初學(xué)者從Helm Chart開始接觸。 

OpenMetrics

OpenMetrics (沙箱階段)——OpenMetrics為應(yīng)用程序的外部指標(biāo)格式設(shè)定了中性的標(biāo)準(zhǔn)。這個標(biāo)準(zhǔn)讓用戶可以在更大范圍的系統(tǒng)間傳輸指標(biāo)數(shù)據(jù)。OpenMetrics其實(shí)是基于Prometheus的指標(biāo)格式，而后者又是采用Borgmon的運(yùn)營經(jīng)驗(yàn)，Borgmon實(shí)現(xiàn)了“白盒監(jiān)控”和低開銷的海量數(shù)據(jù)收集，有著超過300家的服務(wù)輸出商。在OpenMetrics之前，監(jiān)控環(huán)境主要都是基于像SNMP之類，相對過時的標(biāo)準(zhǔn)和技術(shù)，使用專用指標(biāo)格式，也很少有人關(guān)注指標(biāo)格式規(guī)范，存在不少系統(tǒng)差異性的問題。而OpenMetrics出現(xiàn)后，在Prometheus的指標(biāo)格式之上，定義了更緊湊、更清晰和更嚴(yán)格的語法。很好的改善了系統(tǒng)間指標(biāo)差異這方面的問題。

雖然OpenMetrics仍在沙箱階段，但它已經(jīng)被AppOptics、Cortex、Datadog、谷歌、InfluxData、OpenCensus、Prometheus、Sysdig和Uber等公司用于生產(chǎn)環(huán)境。 

Cortex

Cortex (沙箱階段)——Prometheus的首要設(shè)計(jì)目標(biāo)就是操作簡單。因此，它只運(yùn)行在單節(jié)點(diǎn)或單容器內(nèi)，所使用的存儲也是不具備持久或長期存儲能力的本地存儲。避免采用操作復(fù)雜性更高的集群和分布式存儲的目的也是為了符合Prometheus的簡單原則。Cortex卻是具備水平可擴(kuò)展、支持多租戶、采用長效存儲設(shè)備的輔助解決方案。這對于Prometheus而言，我們認(rèn)為是不錯的補(bǔ)充。它讓大型企業(yè)在使用Prometheus時，可以具備高可用性，可以訪問長效存儲設(shè)備。雖然在這個領(lǐng)域，目前還有其他一些例如Thanos、Timbala和M3DB的項(xiàng)目也獲得社區(qū)的關(guān)注。但是，Cortex已經(jīng)在GrafanaLabs和Weaveworks作為SaaS產(chǎn)品進(jìn)行了battle測試，而且EA和StorageOS也在prem平臺上部署了它。

日志和跟蹤 

Fluentd

Fluentd(孵化階段)——Fluentd采用統(tǒng)一的方法，對應(yīng)用程序的日志進(jìn)行收集、解析和傳輸。使用戶可以更好地理解和利用這些日志信息。這統(tǒng)一的方法就是將日志數(shù)據(jù)定義成JSON格式，實(shí)現(xiàn)跨多個源和目的地進(jìn)行日志的收集、過濾、緩沖和輸出。Fluentd的優(yōu)勢之一是可以收集VM和傳統(tǒng)應(yīng)用的日志，但它真正的優(yōu)勢還是在云原生環(huán)境Kubernetes之上，作用于那些動態(tài)運(yùn)行的微服務(wù)。

Fluentd以daemonset的方式，運(yùn)行在Kubernetes上每個Pod節(jié)點(diǎn)內(nèi)。它不僅收集容器內(nèi)所有應(yīng)用程序的日志(包括CNCF ones)，還將日志發(fā)送到STDOUT。Fluentd具有逐條解析和緩沖日志記錄的能力，并將格式化的日志發(fā)送到所配置的目的地，如Elasticsearch、Hadoop和Mongo，讓用戶可以進(jìn)行后續(xù)處理。

Fluentd最初是用Ruby編寫的，雖然功能比較完整，但運(yùn)行時需要50Mb以上的內(nèi)存，這對于配對容器部署運(yùn)行顯然不太合適。于是，與Fluentd同時開發(fā)的Fluentbit變成了一個替代解決方案。Fluentbit是用C寫的，在運(yùn)行時只需要幾Kb的內(nèi)存，CPU和內(nèi)存上效率更高，但功能比Fluentd要簡單很多，存在比較多的限制。

Fluentd最初是Treasuredata的一個開源開發(fā)項(xiàng)目，只是Kubernetes的一個日志插件。較早的可部署版本是0.12，版本比較老、但非常穩(wěn)定，已被廣泛部署在各種生產(chǎn)環(huán)境中。近期開發(fā)完成的1.X新版本包含了很多改進(jìn)，例如增加新的API、納秒級響應(yīng)和支持Windows環(huán)境等。Fluentd正在慢慢成為云原生環(huán)境中日志收集的標(biāo)配， 很大可能成為下一個CNCF畢業(yè)項(xiàng)目。 

OpenTracing

OpenTracing(孵化階段)——開發(fā)人員需要能夠查看到每條事務(wù)并懂得微服務(wù)的行為，這使用分布式跟蹤對于大規(guī)模構(gòu)建微服務(wù)的重要性不能被低估，然而，分布式跟蹤非常具有挑戰(zhàn)性，需要跟蹤工具必須通過已有的服務(wù)、包和特定的應(yīng)用程序代碼在流程內(nèi)和流程之間傳播跟蹤的上下文。OpenTracing允許應(yīng)用程序代碼、OSS包和OSS服務(wù)開發(fā)人員無需限定具體供應(yīng)商的情況下測試自己的代碼。 它為應(yīng)用程序和OSS包提供了一個分布式跟蹤標(biāo)準(zhǔn)，這些程序包具有獨(dú)立的API和9種語言的可用庫。專注于分布式跟蹤使得OpenTracing非常適合服務(wù)集群和分布式系統(tǒng)。但OpenTracing本身并不是一個在UI中運(yùn)行跟蹤來分析spans的跟蹤系統(tǒng)。它只是一個與應(yīng)用業(yè)務(wù)邏輯、框架和現(xiàn)有工具一起工作的API，可用于創(chuàng)建、傳播和標(biāo)記spans。它創(chuàng)建存儲在后端或UI格式的跟蹤。目前，OpenTracing集成了開源(如Jaeger，Zipkin)和商業(yè)跟蹤解決方案(如Instana，Datadog)。

Jaeger

Jaeger(孵化階段)——Jaeger是一個開源的分布式跟蹤系統(tǒng)解決方案，它與OpenTracing兼容，最初是由Uber開發(fā)和測試的。它的名字的發(fā)音是yā′gər，即獵人的意思。靈感來自于谷歌的內(nèi)部跟蹤系統(tǒng)Dapper和Zipkin。Zipkin是由Twitter編寫，采用了OpenTracing標(biāo)準(zhǔn)(但限制了集成支持能力)構(gòu)建的開源跟蹤系統(tǒng)。Jaeger通過HTTP接受Zipkin格式的spans，并具有Zipkin的向后兼容性。Jaeger的用例監(jiān)視和基于微服務(wù)的故障排除功能，提供了分布式上下文傳播、分布式事務(wù)監(jiān)視、根本原因分析、服務(wù)依賴關(guān)系分析以及性能和延遲優(yōu)化能力。Jaeger的數(shù)據(jù)模型和工具包庫與OpenTracing兼容。它的Web UI是采用React/Javascript構(gòu)建的，可以對Cassandra、Elasticsearch和memory等后端提供多種支持。同時，Jaeger集成了包括Istio和Linkerd在內(nèi)的服務(wù)組件，使得跟蹤更加容易實(shí)現(xiàn)。 

Jaeger默認(rèn)會暴露Prometheus的指標(biāo)，并與Fluentd集成來進(jìn)行日志傳輸，這讓它具有很好可觀察性?？梢酝ㄟ^Helm chart或最近開發(fā)的Jaeger Operator部署到Kubernetes之上。Uber和RedHat為Jaeger代碼庫提供了大部分的貢獻(xiàn)。但還有數(shù)百家公司為Jaeger用于云環(huán)境和基于微服務(wù)的分布式跟蹤在進(jìn)行調(diào)優(yōu)。

容器注冊 

Harbor

Harbor(沙箱階段)——Harbor最初是由VMWare作為開源解決方案開發(fā)的，是一個開源可信任的容器注冊器，用于存儲、標(biāo)記和掃描Docker鏡像，提供了免費(fèi)的、增強(qiáng)的Docker注冊特性和功能。它提供的Web接口具有基于角色訪問控制(RBAC)和LDAP驗(yàn)證支持的安全特性。它集成了由CoreOS開發(fā)的用于漏洞掃描的開源項(xiàng)目Clair和用于內(nèi)容信任的Notary(一個CNCF孵化項(xiàng)目，稍后介紹)。Harbor提供活動審計(jì)、Helm chart管理和Harbor實(shí)例間的鏡像復(fù)制(高可用和災(zāi)難恢復(fù)用途)功能?，F(xiàn)在已經(jīng)被許多公司所使用，包括TrendMicro、Rancher、Pivotal和AXA。

存儲和數(shù)據(jù)庫 

Rook

Rook(孵化階段)——Rook是Kubernetes的開源存儲編排器。它幫助OPS人員在Kubernetes之上運(yùn)行Ceph等軟件分布式系統(tǒng)(SDS)。開發(fā)人員可以使用存儲動態(tài)創(chuàng)建Kubernetes中的持久卷(PV)來部署Jenkins、WordPress等存在狀態(tài)請求的應(yīng)用程序。

Ceph是一種流行的開源SDS，它運(yùn)行在常規(guī)的硬件上，對外提供對象存儲，塊存儲和文件系統(tǒng)等多種主流的的存儲服務(wù)類型。用戶可以將Ceph集群直接部署在硬件上，然后使用CSI插件將其連接到Kubernetes。但這樣做無疑會增加OPS人員的部署和操作Ceph集群的難度，增加工作挑戰(zhàn)性，降低對Ceph集群的歡迎度。而Rook使用自定義資源定義(CRDs)方式將Ceph作為一個類對象部署到Kubernetes中，并使用操作框架將其變成自管理、自伸縮和自修復(fù)的存儲服務(wù)。這一點(diǎn)恰恰對應(yīng)了Kubernetes運(yùn)行的理念，即將人的操作知識編碼到軟件中，從而可實(shí)現(xiàn)簡易打包和與終端用戶的共享。

與Helm專注于打包和部署Kubernetes應(yīng)用程序相比，Rook Operator可以部署和管理復(fù)雜的SDS應(yīng)用程序生命周期。以Ceph為例，Rook操作人員可以自動化存儲管理員的工作，例如部署、引導(dǎo)、配置、性能指定、水平伸縮、修復(fù)、升級、備份、災(zāi)難恢復(fù)和監(jiān)視等。

最初的Rook Operator只支持Ceph，在0.8版本時，對Ceph的支持達(dá)到Beta版，隨后發(fā)布了用于存儲廠商的Rook框架，這個框架將Rook擴(kuò)展成為一個通用的云原生存儲編配器。具有支持可重用規(guī)范、邏輯、策略和測試的多個存儲解決方案。目前Rook在alpha中支持CockroachDB、Minio、NFS，后續(xù)將支持Cassandra、Nexenta和Alluxio。在生產(chǎn)中使用Ceph的Rook Operator的公司越來越多，尤其是在Prem平臺上，包括CENGN、Gini、RPR都有部署，還有許多公司正在評估階段。 

Vitess

Vitess (孵化階段)——Vitess是一個數(shù)據(jù)庫的中間件。 它使用通用分片技術(shù)在MySQL實(shí)例之間分發(fā)數(shù)據(jù)。它可以實(shí)現(xiàn)水平伸縮，在不影響應(yīng)用的情況下，進(jìn)行水平擴(kuò)展。 當(dāng)用戶的分片達(dá)到滿負(fù)荷時，Vitess能以零停機(jī)時間和良好可觀察性，重新對底層數(shù)據(jù)庫進(jìn)行分片擴(kuò)展。Vitess還解決了許多與事務(wù)性數(shù)據(jù)相關(guān)的問題，項(xiàng)目成長趨勢良好。 

TiKV

TiKV(沙箱階段)——TiKV是一個事務(wù)性鍵值數(shù)據(jù)庫，它具備簡化調(diào)度和自動平衡的能力。它充當(dāng)了分布式存儲層，提供數(shù)據(jù)強(qiáng)一致性、分布式事務(wù)管理和水平伸縮性的功能。TiKV的設(shè)計(jì)靈感來自于谷歌Spanner和HBase，但是它的優(yōu)點(diǎn)是沒有分布式文件系統(tǒng)。TiKV由PingCAP開發(fā)，目前還有有來自三星、騰訊云和UCloud的貢獻(xiàn)者。

容器運(yùn)行時 

RKT

RKT(孵化階段)——RKT(讀作Rocket)最初是由CoreOS開發(fā)的一個應(yīng)用程序容器，屬于Docker的備選項(xiàng)目。當(dāng)時，Docker成為Kubernetes的默認(rèn)容器，但遭遇到來自kubelet的壓力，Kubernetes和Docker社區(qū)在相互協(xié)作方面存在著分歧。開發(fā)Docker的公司Docker Inc.有自己的產(chǎn)品路線圖，并且正在給Docker添加一些復(fù)雜的功能。例如，為Docker添加集群模式，以及將文件系統(tǒng)從AUFS更改為overlay2。但做這些工作時，并沒有向外發(fā)布信息，導(dǎo)致這些更改影響到了Kubernetes社區(qū)和Kubernetes路線圖規(guī)劃和發(fā)布日期。況且，Kubernetes用戶需要用到的只是一個簡單的容器，具備啟停容器，并具備伸縮、升級等功能即可。因此，CoreOS就打算將RKT開發(fā)成Docker的替代品，專門為Kubernetes而構(gòu)建。但令人意外的是，這舉措?yún)s激發(fā)了Kubernetes的SIG-Node團(tuán)隊(duì)為Kubernetes開發(fā)了一個容器接口(CRI)，這個接口可以連接任何類型的容器，并從其核心代碼中把Docker的代碼也被刪除了。RKT可以同時使用OCI和Docker格式的鏡像。雖然RKT對Kubernetes生態(tài)系統(tǒng)產(chǎn)生了積極的影響，但卻沒有被最終用戶所接受，特別是那些習(xí)慣了Docker CLI并且不想學(xué)習(xí)其他應(yīng)用程序打包方法的開發(fā)人員。此外，由于Kubernetes的流行，有許多容器解決方案都在爭奪這一細(xì)分市場，例如Gvisor和基于OCI的cri-o都越來越流行，而RKT有點(diǎn)風(fēng)景不再的感覺，可能會成為CNCF孵化器中被移除的項(xiàng)目。 

Containerd

Containerd(孵化階段)——Containerd是一個強(qiáng)調(diào)簡單性、健壯性和可移植性的容器。與RKT一樣，支持OCI和Docker鏡像格式，但不同的是，Containerd設(shè)計(jì)的目的是嵌入到較大型的系統(tǒng)中，而不是提供給開發(fā)人員或最終用戶直接使用。Containerd也是Docker捐贈給CNCF的項(xiàng)目。早期的Docker是一個高度集成的應(yīng)用，但隨著時間的推移，集群模式等功能的加入，使其成為一個復(fù)雜且難以管理的應(yīng)用。而且對于要求簡單容器功能的Kubernetes用戶而言，Docker的復(fù)雜功能反而有些多余。因此，Kubernetes開始尋找包括RKT在內(nèi)的替代方案，來替代默認(rèn)的Docker容器。這時，Docker項(xiàng)目決定將自己拆分為松耦合的組件，采用更模塊化的體系結(jié)構(gòu)。這也就是Moby項(xiàng)目，其中Containerd就是這個項(xiàng)目的核心功能。拆分出來的Containerd通過CRI接口集成到Kubernetes，并改名為ri- Containerd。但從Kubernetes 1.10開始，默認(rèn)采用Containerd通過內(nèi)置的CRI插件實(shí)現(xiàn)集成，省卻了額外的grpc跳轉(zhuǎn)。

隨著基于OCI的cri-o和Gvisor這樣的項(xiàng)目越來越受歡迎，Containerd慢慢也不被社區(qū)所關(guān)注。不過它還是Docker平臺不可或缺的一部分，在Kubernetes生態(tài)系統(tǒng)中還保有一定的位置。

服務(wù)發(fā)現(xiàn) 

CoreDNS

CoreDNS(孵化階段)——CoreDNS是云原生部署中提供服務(wù)發(fā)現(xiàn)的DNS服務(wù)器。Kubernetes自1.12版起，將CoreDNS作為默認(rèn)的集群DNS服務(wù)器，而在更早以前，SkyDNS是Kubernetes集群的DNS組件，它本身就是由Caddy和后來的KubeDNS組成的一個分支。SkyDNS是基于DNS的動態(tài)服務(wù)發(fā)現(xiàn)的解決方案，但體系結(jié)構(gòu)不夠靈活，很難添加新功能或進(jìn)行擴(kuò)展。于是Kubernetes轉(zhuǎn)而采用KubeDNS。但KubeDNS在運(yùn)行時，分3個容器(Kube-dns，Dnsmasq和Sidecar)運(yùn)行，容易出現(xiàn)Dnsmasq漏洞，在新功能擴(kuò)展上也存在類似SkyDNS的問題。而恰好這時，CoreDNS用Go語言進(jìn)行了全面重寫，成為了基于插件的靈活可擴(kuò)展的DNS解決方案，而且在Kubernetes上，運(yùn)行時只需啟動一個容器，也沒有漏洞方面的問題，提供的ConfigMap工具可動態(tài)更新配置。此外，CoreDNS通過嚴(yán)格的設(shè)計(jì)(如驗(yàn)證Pod記錄)修復(fù)了許多KubeDNS上存在的問題。基于插件的架構(gòu)使用戶可以插件的方式隨時添加或刪除功能。目前，CoreDNS已包括30多個自有插件和20個以上的外部插件。通過鏈接插件，用戶可以啟用Prometheus監(jiān)控、Jaeger日志跟蹤、Fluentd日志記錄、Kubernetes API或etcd配置以及其他的高級DNS特性和集成功能。

Service Meshes 

Linkerd

Linkerd(孵化階段)——Linkerd是一個用于服務(wù)網(wǎng)格部署的開源網(wǎng)絡(luò)代理服務(wù)。服務(wù)網(wǎng)格是一個單獨(dú)的層，用于管理、控制和監(jiān)視應(yīng)用程序中的服務(wù)到服務(wù)之間的通信。Linkerd在無需應(yīng)用代碼變更的情況下，通過可編程的回路制動、速率限制、超時和重試配置來提高應(yīng)用程序的容錯性，幫助開發(fā)人員大規(guī)模地運(yùn)行微服務(wù)。通過Zipkin提供了對微服務(wù)的可視化。以及提供了先進(jìn)的交通控制設(shè)備來支持Canaries、Staging和Blue-green部署。SecOps團(tuán)隊(duì)受益于Linkerd的功能，在Kubernetes集群中通過TLS透明地加密了所有跨節(jié)點(diǎn)通信。Linkerd是在Twitter的Finagle項(xiàng)目之上開發(fā)出來的，項(xiàng)目具有廣泛的生產(chǎn)用途，并吸引了許多探索服務(wù)網(wǎng)絡(luò)的公司的興趣。目前，Linkerd可以與Kubernetes、DC/OS和AWS/ECS一起使用。以DaemonSet的形式部署在Kubernetes上，這也意味著集群中的每個節(jié)點(diǎn)都運(yùn)行了一個Linkerd Pod。

服務(wù)網(wǎng)格生態(tài)系統(tǒng)最近有新的變化，例如與Kubernetes緊密集成的Istio項(xiàng)目的引入，與微服務(wù)一起運(yùn)行的輕量級代理Envoy的出現(xiàn)等。這些服務(wù)網(wǎng)格組件提供了比Linkerd更多的功能，這大大降低了Linkerd的受歡迎程度，甚至出現(xiàn)了質(zhì)疑Linkerd存在價(jià)值的聲音。為了重新獲得社區(qū)的興趣并支持現(xiàn)有的大量客戶，Linkerd所屬的公司Buoyant宣布了一個名為Conduit的項(xiàng)目，該項(xiàng)目允許DaemonSets使用Istio作為Sidecar代理，重寫了dataplane，用Go語言重寫了控制平面。這些改變使許多可能的特性都可以使用Sidecar方式。不久前，Conduit項(xiàng)目被重新命名為Linkerd 2.0，并發(fā)布了GA，這表明Linkerd已經(jīng)準(zhǔn)備應(yīng)用于生產(chǎn)環(huán)境。服務(wù)網(wǎng)絡(luò)還在飛速發(fā)展，像Istio和Linkerd 2這樣的項(xiàng)目將是這方面的核心。

服務(wù)代理 

Envoy

Envoy(孵化階段)——Envoy是一個為云原生應(yīng)用設(shè)計(jì)的邊緣節(jié)點(diǎn)和服務(wù)代理。它是由C++編寫的CNCF孵化項(xiàng)目，是具備廠商無關(guān)性、高性能、輕量級的應(yīng)用代理服務(wù)，已在Lyft上開發(fā)和進(jìn)行了battle測試。Envoy可在不改變現(xiàn)有應(yīng)用程序代碼行的情況下，為微服務(wù)提供針對超時、安全、重試、回路制動在內(nèi)的容錯能力。通過與Prometheus、Fluentd、Jaeger和Kiali的集成，它提供了對微服務(wù)之間事件的自動可見性。Envoy還具備執(zhí)行流量路由和流量分發(fā)能力，負(fù)載均衡failovers的域感知能力，因此還可以充當(dāng)一個邊緣代理(如Kubernetes L7 Ingress控制器)的角色。

雖然服務(wù)代理領(lǐng)域已經(jīng)有很多可選的項(xiàng)目，但Envoy激發(fā)了許多關(guān)于服務(wù)網(wǎng)格和現(xiàn)代負(fù)載平衡的興趣點(diǎn)和革命性想法，對現(xiàn)有生態(tài)起到很好的補(bǔ)充。涉及Envoy部署的有Heptio公布的Contour項(xiàng)目，這個項(xiàng)目是部署Envoy代理作為反向代理和負(fù)載平衡器來充當(dāng)Kubernetes的入口控制器。Contour支持動態(tài)配置更新和多團(tuán)隊(duì)Kubernetes集群，能夠限制可能配置虛擬主機(jī)和TLS憑證的命名空間，并提供高級負(fù)載平衡策略。另一個以Envoy為核心的項(xiàng)目是datawire Ambassador，這是一個強(qiáng)大的Kubernetes原生API網(wǎng)關(guān)。由于Envoy是用C++編寫的，非常輕量級，非常適合在Kubernetes內(nèi)部以Sidecar模式運(yùn)行，也非常適合與API驅(qū)動的配置更新的風(fēng)格相協(xié)同，成為dataplanes服務(wù)網(wǎng)格的理想候選方案。另外，服務(wù)網(wǎng)格 Istio宣布Envoy是其dataplane的默認(rèn)服務(wù)代理，Envoy代理以Sidecar模式部署在Kubernetes中的每個實(shí)例上。創(chuàng)建一個由Istio的控制面板配置管理的透明的服務(wù)網(wǎng)格。這種方法與Linkerd v1中使用DaemonSet模式完全不同，后者提供了每個服務(wù)的可見性，并提供在Kubernetes甚至混合云場景中為每個服務(wù)創(chuàng)建安全TLS的能力。最近，Hashicorp宣布其開源項(xiàng)目Consul Connect也將使用Envoy在微服務(wù)之間建立TLS連接。

現(xiàn)在，Envoy在背后沒有任何供應(yīng)商或商業(yè)項(xiàng)目的驅(qū)動下，創(chuàng)立了一個龐大而活躍的開源社區(qū)。如果您想嘗試Envoy，也建議試用一下Istio、Ambassador或Contour， 2018年12月10日在西雅圖，Kubecon的Envoy社區(qū)成功地主辦了第1屆EnvoyCon，歡迎大家加入到社區(qū)。

安全 

Falco

Falco(沙箱階段)——Falco是Sysdig開發(fā)的開源實(shí)時安全工具，設(shè)計(jì)用來檢測在Kubernetes編排系統(tǒng)中的異?；顒雍腿肭中袨椤Ｋv留在用戶空間中，使用Sysdig內(nèi)核模塊檢索系統(tǒng)調(diào)用活動。Falco與SecComp或AppArmor之類的執(zhí)行工具相比，它具備更多的審計(jì)功能。

Falco用一組預(yù)配置的規(guī)則，定義了需要注意的行為和事件。然后以DaemonSet方法運(yùn)行在Kubernetes中，基于這些規(guī)則，F(xiàn)alco可以檢測到任何調(diào)用Linux系統(tǒng)的行為，并為這些行為添加警報(bào)。類似的行為可能來自于在容器內(nèi)的shell運(yùn)行腳步，或建立出站網(wǎng)絡(luò)連接的二進(jìn)制文件。這些事件可以通過Fluentd在STDERR上捕獲，然后發(fā)送到ElasticSearch進(jìn)行過濾或解除告警。從而可以幫助用戶迅速應(yīng)對如容器破壞或損毀的安全事故，減少此類事件造成的經(jīng)濟(jì)損失。 

隨著Falco被納入CNCF的沙箱階段，我們希望它以后與更多的其他CNCF項(xiàng)目深度集成，例如在Falco內(nèi)集成官方的Helm Chart。 

Spiffe

Spiffe(沙箱階段)——在應(yīng)用負(fù)載之間建立互信是一個復(fù)雜的問題，且隨著負(fù)載的彈性伸縮和動態(tài)調(diào)度，這個問題變得更為困難甚至危險(xiǎn)。但Spiffe是解決這個問題的云原生方案。Spiffe提供了一個策略驅(qū)動、API驅(qū)動且完全自動化的安全產(chǎn)品標(biāo)識框架。它通過驗(yàn)證身份來開啟應(yīng)用負(fù)載之間的通信。Spiff現(xiàn)在還相對較新，主要是設(shè)計(jì)用于與Spire緊密配合的項(xiàng)目。 

Spire

Spire(沙箱階段)——Spire是Spiffe的運(yùn)行環(huán)境，是一系列可集成到云提供商和中間件層的軟件組件。Spire采用模塊化架構(gòu)，支持多種平臺。目前，圍繞Spiffe和Spire的社區(qū)發(fā)展非常迅速。HashiCorp剛剛宣布在Vault中支持Spiffe ID，使得它可用于關(guān)鍵信息和常態(tài)輪換。Spiffe和Spire現(xiàn)在都處于CNCF的沙箱階段。 

Tuf

Tuf(孵化階段)——Tuf是“The Update Framework”的縮寫。它是一個用于可信內(nèi)容分發(fā)的框架。內(nèi)容信任問題是一個重要的安全問題。Tuf通過驗(yàn)證軟件的出處，并確認(rèn)只使用軟件的新版本，來提供內(nèi)容信任，改善這個問題。TUF項(xiàng)目在下面將提到的Notary項(xiàng)目中扮演許多非常重要的角色。也被許多公司用于生產(chǎn)環(huán)境構(gòu)建內(nèi)部工具和產(chǎn)品，這些公司包括Docker、DigitalOcean、Flynn、Cloudflare和VMware。 

Notary

Notary(孵化階段)—— Notary是一種安全的軟件分發(fā)實(shí)現(xiàn)。本質(zhì)上，是基于TUF，確保所有提取的Docker鏡像都是具有簽名、正確和未篡改的鏡像版本。 Notary可以貫穿于CI/CD工作流的所有階段，解決Kubernetes中基于Docker部署的一個主要安全問題。Notary發(fā)布和管理受信內(nèi)容的集合。它允許DevOps工程師批準(zhǔn)已發(fā)布的可信數(shù)據(jù)并創(chuàng)建簽名集合。這類似于Linux系統(tǒng)中軟件庫的管理工具，但只是用于Docker鏡像管理。Notary的主要目標(biāo)包括保證鏡像版本的更新情況(始終有新的內(nèi)容，以避免漏洞)，和對象之間的信用委托。例如用戶之間，不可信鏡像和傳輸通道的可信分發(fā)等。雖然Tuf和Notary通常不被終端用戶直接使用，但它們的解決方案集成到各種商業(yè)產(chǎn)品或開源項(xiàng)目中，用于可信分發(fā)的內(nèi)容簽名或圖像簽名，這些產(chǎn)品包括Harbor、Docker Enterprise Registry、Quay Enterprise、Aqua。在這個領(lǐng)域還有另一個有趣的開源項(xiàng)目Grafeas，它是一個開源的元數(shù)據(jù)API。所存儲“attestations”或圖像簽名可以作為部分授權(quán)控制的校驗(yàn)，也可用于容器分析API和GCP的二進(jìn)制授權(quán)。和JFrog，AquaSec的同類功能類似。 

OPA

Open Policy Agent(沙箱階段)——Open Policy Agent(OPA)采用強(qiáng)制聲明方式來指定策略，允許在一個技術(shù)堆棧中分發(fā)不同類型的策略，并自動更新，而無需重新編譯或重新部署。在應(yīng)用和平臺層，OPA以從服務(wù)發(fā)送查詢的方式通知策略決策。它與Docker、Kubernetes、Istio等應(yīng)用都有不錯的集成效果。

數(shù)據(jù)流和消息流

NATS

NATS(孵化階段)——NATS是一個聚焦中間件的消息傳遞服務(wù)，允許基礎(chǔ)設(shè)施在分布式系統(tǒng)之間發(fā)送和接收消息。它的集群和自動修復(fù)技術(shù)具備高可用性，并且它基于日志的數(shù)據(jù)流保證了有歷史數(shù)據(jù)引用消息的送達(dá)和所有信息的接收。NATS有一個相對簡單的API，支持多種技術(shù)用例，包括云中常規(guī)消息傳遞、微服務(wù)傳輸、控制平面和服務(wù)發(fā)現(xiàn)等消息傳遞，以及物聯(lián)網(wǎng)消息傳遞。與前文所列的日志記錄、監(jiān)視和跟蹤解決方案所不同的是，NATS工作在應(yīng)用層。 

gRPC

gRPC(孵化階段)——gRPC是一個高性能RPC框架，提供在多個平臺上，庫、客戶端和服務(wù)器之間進(jìn)行通信的能力?？梢栽谌魏苇h(huán)境中運(yùn)行，并為Envoy和Nginx等代理提供支持。gRPC為負(fù)載平衡、跟蹤、健康檢查和身份驗(yàn)證提供可插入的支持，來實(shí)現(xiàn)有效地連接服務(wù)。將設(shè)備、應(yīng)用程序和瀏覽器與后端服務(wù)連接起來。gRPC是促進(jìn)消息傳遞的應(yīng)用層工具。 

CloudEvents

CloudEvents(沙箱階段)——CloudEvents為開發(fā)人員提供了一種通用的方式來描述跨多云環(huán)境下發(fā)生的事件。通過提供描述事件數(shù)據(jù)的規(guī)范，CloudEvents簡化了跨服務(wù)和平臺的事件聲明和傳遞。項(xiàng)目仍處于沙箱階段，還需要極大地提高應(yīng)用程序的可移植性和效率。

后續(xù)展望

云原生生態(tài)正在不斷地飛速增長。在不久的將來，還將有更多的項(xiàng)目被納入到沙箱階段，讓它們有機(jī)會獲得社區(qū)的興趣和認(rèn)識。我們希望像Vitess，NATs，Rook之類與基礎(chǔ)設(shè)施相關(guān)的項(xiàng)目能不斷得到CNCF的關(guān)注和支持。因?yàn)樗麄兪窃圃渴鸬闹匾苿诱?。同時，在云原生持續(xù)交付的領(lǐng)域還相對空白，我們希望CNCF能夠繼續(xù)關(guān)注。

盡管CNCF在不斷納入新項(xiàng)目，讓成熟的項(xiàng)目畢業(yè)。但同樣重要的還需要有一種工作機(jī)制，將那些因失去社區(qū)關(guān)注，價(jià)值性不高或被其他項(xiàng)目取代的項(xiàng)目從CNCF孵化器中移除。雖然項(xiàng)目提交過程對任何人都是開放的，但我希望TOC委員會繼續(xù)只資助優(yōu)秀的候選者，使CNCF成為項(xiàng)目間協(xié)同良好，多樣化的生態(tài)系統(tǒng)。

作為CNCF的大使，我希望教會人們?nèi)绾问褂眠@些技術(shù)。在CloudOps，我?guī)ьI(lǐng)了Docker和Kubernetes的研討會，推廣云原生技術(shù)，并幫助DevOps團(tuán)隊(duì)實(shí)踐他們的應(yīng)用。我也組織Kubernetes和云原生技術(shù)相關(guān)的會議，邀請了來自世界各地的演講者展示他們各種類型的技術(shù)項(xiàng)目。這些演講者在蒙特利爾、渥太華、多倫多、基奇納-滑鐵盧和魁北克市等地推動他們的項(xiàng)目運(yùn)行。我也鼓勵大家加入CloudNativeCon。