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

[[254613]]

我有幸成為CNCF的大使，致力于在加拿大推廣社區活動和云原生的教育。同時，在CloudOps社區， 我還帶領著Docker和Kubernetes研討會，向大家普及云原生技術，幫助DevOps團隊實踐相關的技術應用。

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

同時，我還編寫了云原生技術的初學者指南。希望能幫助讀者理解這個領域并在這個領域取得更好的進展。

CNCF的歷史背景

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

CNCF的使命

通過提供多種選項的開發軟件社區，幫助最終用戶構建云原生應用。從而培育云原生開源項目的生態體系。CNCF鼓勵項目之間的相互協作，希望實現完全由CNCF成員項目演化出來的成熟技術棧。這便是CNCF在云端的自我使命。

CNCF的歷程

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

沙箱階段

這個階段的項目非常早期，在部署到生產環境之前，需要顯著地提升代碼成熟度，積極參與開源社區的互動。項目之所以被選中，主要是因為它們具備的潛力是社區所沒有的。在CNCF的指南中提到，CNCF將幫助推動沙箱項目的公共可見性，并促進其與現有項目形成體系。但沙箱項目從CNCF獲得的資金和營銷支持非常少，并且每12個月都要接受審查，發展不夠好的項目可能會被淘汰掉。

孵化階段

當項目滿足所有沙箱標準并具備明顯的增長和成熟度特征時，它們就進入孵化階段。這時，它們必須至少在三家公司的生產環境中使用過，具備穩定的團隊，確保穩定提供對社區的貢獻，包括處理來自社區的新功能和代碼要求等。

畢業階段

孵化項目一旦達到生產使用的臨界點，TOC就可以投票決定項目是否進入畢業階段。畢業的項目必須證明有很高的采用率，并滿足所有孵化標準。項目的提交者必須至少來自2個不同的組織，具有文檔化和結構化的管理流程，并滿足Linux基金會核心基礎設施計劃的最佳實踐徽章要求。截止到目前，只有Kubernetes和Prometheus兩個畢業項目。

CNCF項目介紹

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

編排 

Kubernetes

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

應用程序開發 

Helm

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

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

Helm目前正在2018年年底Helm V3發布進行一系列的更改和更新。對于依靠Helm進行日常CI/CD開發的公司，包括Reddit、Ubisoft和Nike，我建議他們按照新的設計進行優化調整。

Telepresence

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

由Datawire開發的Telepresence在上述設想方面提供了不錯的解決方案。它允許開發人員因開發需要在本地運行單個微服務，同時保持與運行在遠端Kubernetes集群上的其余部分應用的連接，我們稱之為 “實時代碼”。Telepresence在遠端Kubernetes集群上部署了包含雙向網絡代理的Pod。將本地機器連接到網絡代理。實現了部署真實的開發/測試環境，而無需凍結用于編碼、調試和編輯的本地工具。

監控 

Prometheus

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

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

OpenMetrics

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

雖然OpenMetrics仍在沙箱階段，但它已經被AppOptics、Cortex、Datadog、谷歌、InfluxData、OpenCensus、Prometheus、Sysdig和Uber等公司用于生產環境。 

Cortex

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

日志和跟蹤 

Fluentd

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

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

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

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

OpenTracing

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

Jaeger

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

Jaeger默認會暴露Prometheus的指標，并與Fluentd集成來進行日志傳輸，這讓它具有很好可觀察性。可以通過Helm chart或最近開發的Jaeger Operator部署到Kubernetes之上。Uber和RedHat為Jaeger代碼庫提供了大部分的貢獻。但還有數百家公司為Jaeger用于云環境和基于微服務的分布式跟蹤在進行調優。

容器注冊 

Harbor

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

存儲和數據庫 

Rook

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

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

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

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

Vitess

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

TiKV

TiKV(沙箱階段)——TiKV是一個事務性鍵值數據庫，它具備簡化調度和自動平衡的能力。它充當了分布式存儲層，提供數據強一致性、分布式事務管理和水平伸縮性的功能。TiKV的設計靈感來自于谷歌Spanner和HBase，但是它的優點是沒有分布式文件系統。TiKV由PingCAP開發，目前還有有來自三星、騰訊云和UCloud的貢獻者。

容器運行時 

RKT

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

Containerd

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

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

服務發現 

CoreDNS

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

Service Meshes 

Linkerd

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

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

服務代理 

Envoy

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

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

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

安全 

Falco

Falco(沙箱階段)——Falco是Sysdig開發的開源實時安全工具，設計用來檢測在Kubernetes編排系統中的異常活動和入侵行為。它駐留在用戶空間中，使用Sysdig內核模塊檢索系統調用活動。Falco與SecComp或AppArmor之類的執行工具相比，它具備更多的審計功能。

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

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

Spiffe

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

Spire

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

Tuf

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

Notary

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

OPA

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

數據流和消息流

NATS

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

gRPC

gRPC(孵化階段)——gRPC是一個高性能RPC框架，提供在多個平臺上，庫、客戶端和服務器之間進行通信的能力。可以在任何環境中運行，并為Envoy和Nginx等代理提供支持。gRPC為負載平衡、跟蹤、健康檢查和身份驗證提供可插入的支持，來實現有效地連接服務。將設備、應用程序和瀏覽器與后端服務連接起來。gRPC是促進消息傳遞的應用層工具。 

CloudEvents

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

后續展望

云原生生態正在不斷地飛速增長。在不久的將來，還將有更多的項目被納入到沙箱階段，讓它們有機會獲得社區的興趣和認識。我們希望像Vitess，NATs，Rook之類與基礎設施相關的項目能不斷得到CNCF的關注和支持。因為他們是云原生部署的重要推動者。同時，在云原生持續交付的領域還相對空白，我們希望CNCF能夠繼續關注。

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

作為CNCF的大使，我希望教會人們如何使用這些技術。在CloudOps，我帶領了Docker和Kubernetes的研討會，推廣云原生技術，并幫助DevOps團隊實踐他們的應用。我也組織Kubernetes和云原生技術相關的會議，邀請了來自世界各地的演講者展示他們各種類型的技術項目。這些演講者在蒙特利爾、渥太華、多倫多、基奇納-滑鐵盧和魁北克市等地推動他們的項目運行。我也鼓勵大家加入CloudNativeCon。