CNCF 雲原生容器生態系統概要

CNCF（Cloud Native Compute Foundation）是 Linux 基金會旗下的一個組織，旨在推動以容器爲中心的雲原生系統。從 2016 年 11 月，CNCF 開始維護了一個 Cloud Native Landscape 的 repo，彙總目前比較流行的雲原生技術，並加以分類，希望能爲企業構建雲原生體系提供參考。

原文鏈接

2017 年 12 月 06 日，landscape 的 v1.0 版本發佈，本文就按照下面這種圖介紹雲原生系統的大致情況。

雲原生以容器爲核心技術，分爲運行時（runtime）和 orchestration 兩層，runtime 負責容器的計算、存儲、網絡；orchestration 負責容器集羣的調度、服務發現和資源管理。

往下是基礎設施和配置管理，作爲容器底層的基石。容器可以運行在各種系統上，包括公有云、私有云、物理機等；容器還依賴自動化部署工具、容器鏡像工具、安全工具等運維繫統才能工作。

往上是容器平臺上的應用層，類似於手機的 app store，圖中分爲數據庫和數據分析、流處理、SCM 工具、CI/CD 和應用定義幾類，每個公司根據業務需求會有不同的應用體系。

右邊有兩塊：平臺和觀察分析。平臺是指基於容器技術提供的平臺級的服務，比如常見的 Paas 服務，和 Serverless 服務。觀察分析是容器平臺的運維，從日誌和監控方面給出容器集羣當前的運行情況，方便分析和 debug。

NOTE：因爲圖中給出的軟件很多，所以文中會挑選一些比較有名的以及本人比較熟悉的介紹，會略過一些信息；此外，也因爲個人的水平有限，並沒有對所有產品都一一使用過，因此有些內容未免有偏頗或者錯誤之處，如果讀者發現，還望能不吝指出。

1. Cloud（雲）

容器需要運行在操作系統上，系統可以運行在虛擬機或者物理機上。從使用方式上來分，操作系統這層（Iaas）可以分爲公有云和私有云。

公有云

公有云國外以亞馬遜 AWS、微軟 Azure、谷歌 GCP、DigitalOcean 爲代表，國內有阿里雲、騰訊雲、華爲雲，此外IBM、oracle、Fujitsu 都有自己的雲產品，Joyent 也是國外很有名的雲計算公司；packet 是物理機雲服務商，直接爲用戶提供物理機資源。

企業一般會選擇其中一個平臺來使用，也有不少企業同時選擇兩種或者多種雲服務商，以提高可用性和避免廠商鎖定。

私有云

私有云是指用戶在自己的數據中心搭建的雲服務，除了自己研發之外，常見搭建私有云的方法有 Vmware（商業化的虛擬化軟件）和 openstack（python 編寫的開源 Iaas 平臺軟件）；此外 Maas 提供物理機自動安裝和管理服務，分爲免費版和收費版；foreman 是虛擬機和物理機的系統配置工具。

建設私有云的成本很高，但是當公司成長到一定規模的時候，私有云建設也是必要的一件事。除了能縮減成本，也能提高技術實力，而且也有更多的靈活性滿足內部的各種需求。

2. Provisioning（部署）

有了物理機和虛擬機，在運行容器服務之前，我們還需要爲容器準備標準化的基礎環境，以及保證基礎設施的自動化，拿蓋房子來比較，Iaas 和這部分共同組成了容器平臺的地基。

Host Management / Tooling

自動化配置工具，保證容器運行的系統配置的一致性，並提供升級、補丁等功能，一般也可以用來 bootstrap 容器服務。

這裏的幾家軟件功能大同小異：

ansible 比較簡潔，用 ssh 來自動化部署，使用 python 編寫
cfEngine 是這個領域非常老的工具，可以說是配置管理的元老，用 C 編寫，因此性能會更好，但是學習曲線也更曲折
chef 用 ruby 編寫，而且配置文件格式也是 ruby DSL，因此對於 ruby 程序員非常親切友好
saltstack 採用 zeroMQ 作爲消息隊列，實現 master-salve 模式，兼具性能和靈活性，但同時整個系統也更加複雜
puppet 是這個領域的老大哥，以成熟穩定著稱，社區文檔也更豐富

這篇博客和這篇文章比較了 CFEngine vs Puppet vs Chef vs Ansible vs Salt 這幾個工具的異同，如果糾結如何選型，推薦閱讀。

其實，對於大多數需求，根據開發語言、配置文件風格等選擇其中一種就行。

Infrastructure Automation

Iaas 平臺提供了基礎設施服務，但是對於複雜的場景來說，直接使用這些服務提供的接口還是會很麻煩，所以有了基礎設施自動化。這部分做的事情就是能夠讓基礎設施的配置自動化，一次完成多個資源的部署，提高效率。

Bosh：CloudFoundry 旗下的產品
Cloudify：雲應用編排系統，能夠讓用戶定義軟件，然後部署到不同的雲環境中
CloudFormation：AWS 提供的基礎配置服務，能夠通過配置文件定義要創建的各種 AWS 服務，然後一鍵完成集羣或者系統的搭建
Ubuntu Juju：Ubuntu 提供的管理工具，能夠自動化把幾百種服務部署到不同的平臺
Terraform：HashiCorp 旗下的基礎設施配置工具，通過定義一份配置文件，Terraform 能夠在不同雲提供商運行服務，是 Infrastructure as Code 的信奉者
Manage IQ：統一管理雲主機、容器、網絡、存儲的 IT 平臺
kubicorn：管理多個 kubernetes 集羣的工具，集羣可以在不同的雲上
Helm：kubernetes 軟件包安裝工具，能夠安裝多個 kubernetes 資源，類似於 ubuntu 的 apt 工具

總的來說，這些工具就是在雲平臺或者 kubernetes 平臺上再封裝一層，讓用戶能夠通過一次定義，在不同平臺部署多個資源或者服務，並做到版本升級和跟蹤。如果雲平臺提供相關服務（比如 AWS 的 CloudFormation）直接使用即可，如果是混合雲，則需要選擇 Juju、Terraform 這樣的管理工具。

Container Registries

容器的鏡像 registry 是容器平臺的基礎需求，畢竟所有的容器應用就是通過鏡像來定義的，鏡像服務分爲自建和公有服務兩種。

很多公司提供了它們公開的容器 registr 服務，比如 docker 官方的 registry，亞馬遜 ECR（Elastic Container Registry）、Azure 和 Google 雲 registry、此外 Quay、project atomic、JFrog Artifactory 也是比較著名的容器鏡像服務提供商。

Harbor 是開源的企業級容器鏡像管理平臺，Portus 專門爲 Docker registry 提供授權服務。

國內一般企業會選擇自建 registry，因爲國外的 registry 訪問速度都很慢，而國內並沒有非常流行的 registry 服務（當然很多容器服務公司都會提供 registry 服務），另一方面自建 registry 的技術並不複雜。

Secure Images

隨着鏡像和容器標準化的完善，鏡像和容器的安全也越來越受到企業的關注。雖然在大多數情況下，安全往往是軟件開發者最後才關心的事情，但是容器安全卻是不容忽視的一個環節。

notary 和 tuf（the update framework）是 CNCF 旗下的兩個項目，tuf 是開源的安全和驗證標準，notary 是它的一個實現，notary 可以用來驗證鏡像的安全性，也可以用來安全地發佈軟件包。

clair：coreOS 開源的容器安全性分析工具
twistlock 是雲原生系統的安全性平臺
NeuVector 是網絡安全分析工具
aqua 也是容器安全平臺，提供鏡像、容器、用戶認證、網絡流量限制等多種安全功能
anchore 提供了一系列容器環境安全分析、審查和掃描工具

Key Management

和安全相關的另一個問題是機密信息，包括密碼數據、密鑰等。

Keywhiz、pinterest 開源的 knox、lyft 開源的密碼存儲工具 confidant 和 HashiCorp 開源的 vault 想要解決機密信息的存儲，它們通過加密的方式把內容保存到後端存儲中，而且提供了 auditing 等額外功能。

spiffe 和 spire 是一對的，spiffe 定義了服務的認證標準和認證信息的標準，spire 是它的一個實現，但是目前還沒有達到生產可用。

3. Runtime（運行時）

容器運行時這塊是容器核心的技術，關注的是主機容器的技術模塊，分爲計算、存儲、網絡三塊。

Container Runtime（容器運行時）

我們知道，整個容器技術就是因爲 docker 的出現才變得炙手可熱，可以說 docker 重新定義了容器，也成爲了容器技術的代名詞。但是隨着容器的標準化，docker 把核心組件抽象出 containerd，作爲容器運行時，而更多公司也推出自己的容器實現，容器一詞的含義開始擴展，而且也逐漸標準化了。

隨着容器運行時的穩定，普通用戶對其關注會逐漸下降。如果把運行時比作內核，那麼容器調度系統就是操作系統，開發者應該更關心操作系統的功能和性能，只有遇到特殊需求或者問題時纔會關注內核。

OCI（Open Container Initiative）是一個促進容器標準化的組織，主要工作是容器 runtime 和鏡像的標準化協議，這部分內容可以參考我之前的介紹文章。

containerd：docker 公司從原來的 docker 引擎中剝離出來的容器核心功能，具有鏡像管理和容器隔離兩大功能，底層使用 runc
rkt：CoreOS 公司提出的容器引擎技術，一直作爲 docker 的直接競爭對手存在，對於促進容器標準化貢獻很大
lxd：基於 linux 老牌容器管理工具 lxc，旨在提供更好用的接口，最大的特色是使用容器技術提供類似虛擬機的服務
runv：以兼容 OCI 接口的方式管理虛擬機，支持 kvm、Xen、QEMU 等虛擬化技術。換句話說，可以直接把虛擬機作爲 runtime 運行在容器集羣管理平臺上
Intel Clear Containers：Intel 公司推出的容器技術，因爲爸爸的緣故最近也開始出現在容器圈各種文章裏

CRI-O 是 kubernetes 推出的東西，它是 kubelet 和 OCI runtime 之間的橋樑，它內部採用 OCI 標準，因此可以兼容各種 runtime（比如 runc、Clear Container等），對上它提供 CRI 接口供 kubelet 調用。這樣的話，CRI-O 的存在能夠讓 kubelet 使用任何 OCI 兼容的 runtime，從而繞過 docker、rkt 這種完整容器管理工具。

Cloud Native Storage（雲原生存儲）

容器從一出現就非常契合微服務中無狀態服務的設計理念，因此初期甚至給了一些人容器只適合無狀態服務的印象，但是隨着容器技術的成熟和用戶理念的變化，容器目前已經全面進入有狀態服務領域。因爲容器存活時間很短的特點，容器的狀態（存儲的數據）必須獨立於容器的生命週期，也因爲此，容器的存儲變得非常重要，雲原生存儲這塊介紹了很多相關的技術。

作爲 IT 領域的核心技術，存儲早在容器火起來之前就已經有發展了很多年，從單機的各種文件系統、到網絡存儲，再到現在比較熱門的分佈式存儲、以及雲計算催生的塊存儲、文件存儲、對象存儲，不同需求不同分類的存儲早就五花八門了：

Ceph：分佈式存儲系統，同時支持塊存儲、文件存儲和對象存儲，發展時間很久，穩定性也得到了驗證。之前在 openstack 社區被廣泛使用，目前在容器社區也是很好的選項。
GlusterFS：RedHat 旗下的產品，部署簡單，擴展性強，
Hadoop HDFS：Apache 基金會下的開源文件系統項目，在大數據領域廣泛使用，基於 GFS 理念的開源版本。主節點保存元數據，並負責數據分佈、複製、備份決策，工作節點存儲數據，每個數據會有多個副本，保存在不同的工作節點
SheepDog：起源於日本的塊存儲開源項目，設計之初是爲了用於虛擬化平臺 QEMU
Swift：openstack 項目提供的對象存儲工具
LeoFS：高可用、分佈式的對象存儲系統，海量數據支持比較好，提供 HTTP、S3、NFS 等接口訪問
minio：開源的對象存儲軟件，提供和 AWS S3 兼容的接口，簡單易用

除了這些開源的存儲技術之外，還有很多容器存儲圈的技術公司：

DELL EMC：商業存儲的典範，提供企業級各種需求的存儲解決方案，作爲商業存儲的大哥，自然也會在容器存儲上發力
NetApp：致力於混合雲的存儲方案，是一家老牌的公司，在存儲行業深耕多年
Datera：一家存儲創業公司，主要產品是 EDF(Elastic Data Fabric)，提供 API 優先的企業級存儲方案，有純軟件和一體機兩種不同的版本
Diamanti：Diamanti 一家超融合基礎設施初創公司，主要爲企業數據中心提供基於容器的硬件及軟件支持服務
Hedvig：爲私有云和混合雲提供統一的數據存儲服務，爲虛擬機和容器提供軟件定義存儲
Infinit：開源的軟件定義存儲公司，之前是做文件跨平臺傳輸的。產品也是統一的存儲平臺，爲各種計算平臺提供塊存儲、對象存儲和文件存儲等接口。已經被 docker 收購
Pure Storage：一家明星存儲創業公司，最大的特定是對閃存的支持
StorageOS：爲容器提供分佈式存儲的統一視圖，對上層提供 API 實現存儲的自動化管理，作爲容器部署。產品也分爲免費版和收費版
Quobyte：數據中心文件系統，被 kubernetes volume 插件直接支持

因爲不同用戶對存儲需求不同，採取的存儲方案也不同，不管是開源方案、商業方案還是自研方案，或者是文件存儲、對象存儲還是塊存儲，怎麼把這些技術用到容器平臺，以及保證標準化和統一化的接口，是非常有挑戰性的事情，目前也有很多努力：

CSI（Container Storage Interface）：定義雲應用調度平臺和各種存儲服務接口的項目，核心的目標就是存儲 provider 只需要編寫一個 driver，就能集成到任何的容器平臺上
libStorage：EMC 旗下研發的一個存儲開發框架，旨在開發與容器平臺無關的存儲框架，大致的思想是 libstorage 來處理和容器平臺的交互，存儲框架只需要接入到該框架就行
REX-Ray：基於 libStorage 實現的存儲管理平臺，支持大部分的存儲提供商，也能運行在大多數操作系統上
openSDS：開放的軟件定義存儲標準，集合各大存儲廠商，提供統一管理的存儲標準，隸屬於 Linux 基金會
rook：基於 ceph 作爲後臺存儲技術，深度集成到 kubernetes 容器平臺的容器項目，因爲選擇了 ceph 和 kubernetes 這兩個都很熱門的技術，並且提供自動部署、管理、擴展、升級、遷移、災備和監控等功能，所以很受關注
portworx：針對容器技術打造的，把每個節點的存儲資源組成一個存儲池，每個數據自動進行備份，並通過和容器平臺調度深度集成保證數據高可用。分爲免費版和商業版

Cloud Native Network

網絡最重要的功能是提供不同計算資源的連通，隨着虛擬化和容器技術的發展，傳統的網絡方案已經無法滿足雲計算快速增長、不斷變化的網絡需求。不同用戶對網絡的要求也越來越高：

安全性：保證私有和公有云網絡的安全，網絡流量能夠加密，不被竊聽和修改
多租戶：雲計算需要同時爲多個租戶提供網絡服務，不同租戶之間互相獨立而且隔離
快速響應：容器的生命週期大大縮短，集羣的網絡在實時動態變化，網絡方案需要感知網絡的變化，並快速提供服務
網絡遷移：虛擬機和容器會在集羣上遷移和調度，網絡方案需要支持計算資源跨主機遷移後的連通
監控和調試：雲上的網絡環境，讓整個網絡的流量變得更加複雜，我們需要新的工具讓網絡可視化，並做到自動化運維
……

因此，在雲計算和容器這塊湧現出很多網絡解決方案和廠商，試圖解決這些問題：

cni（Container Network Interface）：kubernetes 和 CoreOS 提出的容器網絡接口標準，旨在爲容器平臺提供統一的網絡訪問模式，目前很多網絡方案都已經集成進來
calico：基於 BGP 的純三層網絡方案，性能很高，並且提供強大的網絡防火牆功能，以滿足用戶對安全性的需求
canal：基於 flannel 和 calico 提供 kubernetes pod 之間網絡防火牆的項目
contiv：思科推出的網絡方案，支持 vxlan 和 vlan 方案，提供了多租戶和主機訪問控制策略功能
cilium：利用 Linux 原生技術提供的網絡方案，支持 L7 和 L3、L4 層的訪問策略
flannel：CoreOS 主要的容器網絡項目，主要用於 kubernetes 平臺提供 pod 之間的連通性，提供多種連網方案，部署和管理簡單
midokura：日本 SDN 網絡公司，主要產品是開源的 MidoNet，之前廣泛用於 openstack 中，目前有很多把它應用到容器領域的嘗試
openContrail：Juniper 收購的開源網絡虛擬化平臺，目前已經加入 linux 基金會。OpenContrail 是一個可擴展的網絡虛擬化控制層，提供了豐富的軟件定義網絡功能和安全性
Open vSwitch：linux 平臺的虛擬交換機軟件，除了提供和 Linux 虛擬網橋類似功能外，還支持 openflow 協議
weave net：Weaveworks 公司開源的 docker 跨主機網絡方案，安裝和使用都比較簡單，內部也是通過 overlay 網絡實現的
romana：Panic Networks 推出的網絡開源方案，基於 L3 實現的網絡連通，因此沒有 overlay 網絡帶來的性能損耗，但是隻能通過 IP 網段規劃來實現租戶劃分，不夠靈活
tigera：網絡方案初創公司，主推的方案是把 flannel 和 calico 集成到一起的 canal，應用Calico的網絡策略到 Flannel 中

也有很多的商業公司爲企業提供網絡解決方案：

aviatrix：混合雲網絡解決方案提供商，集成 AWS、Azure、Google 等公有云網絡，在同一平臺管理公司混合雲網絡
Big Switch：下一代數據中心網絡公司，提供 SDN 可編程的網絡方案，主要有 Big Cloud Fabric 和 Big Monitoring Fabric 兩種產品方案
vmware NSX：虛擬化廠商 vmware 提供虛擬化網絡方案
cumulus：主要產品是 cumulus 操作系統，繼承了衆多的網絡軟件，提供豐富的網絡功能。能夠解除數據中心網絡設備硬件和軟件鎖定的局面，爲網絡硬件帶來軟件的靈活特性
nuagenetworks：致力於數據中心 SDN 網絡的公司，提供解決方案

4. Orchestration & Management（編排和管理）

當在生產環境中使用容器時，單臺主機上的容器已經不能滿足需求，需要管理多主機容器集羣，也就需要有個工具能夠提供資源管理、容器調度和服務發現等功能，保證多主機容器能夠正常工作。可以說，對於雲原生系統，orchestration 纔是最核心的東西。

Scheduling & Orchestration

調度和集羣管理一直是容器技術的熱點領域，競爭也非常激烈。打個可能不那麼恰當的比喻，如果把容器 runtime 比作引擎，那麼容器集羣管理工具就是汽車。用戶購買的是汽車，儘管引擎非常重要，但是它終歸只是個可以替換的零件。

集羣管理競爭還在，並沒有最終的唯一勝利者，但總的來說 google 公司的 kubernetes 處於絕對的領先狀態，也是目前社區發展最快的平臺，隨着 docker 官方支持 kubernetes，以及 azure 和 aws 。目前社區三個主流的容器調度平臺是：

kubernetes：起源於 google 內部的 Borg 系統，率先提出 pod 的概念，提供自動化管理、服務發現、服務升級、有狀態服務等等特性
docker swarm：docker 公司官方的容器管理平臺，最大的特點是和 docker 兼容的 API 和操作命令
mesos：apache 旗下的任務調度平臺，後來應用於容器調度

對於公有云上的容器服務，各大雲服務商也有對應的產品：

Amazon ECS：亞馬遜推出的容器服務，特點是虛擬機收費，容器免費
Azure Service Fabric：微軟 Azure 的容器服務調度平臺
Nomad：hashicorp 旗下的數據中心調度平臺，同時支持服務和任務兩種 Job，也已經支持 docker 容器

Coordination & Service Discovery

有了容器集羣管理工具，容器的規模逐漸變多，另外一個需要解決的問題是服務之間怎麼互相發現對方。因爲集羣的容器是不斷變化的，IP 地址也是不穩定的。這個問題再往下思考，就是集羣的狀態應該怎麼保存，才能讓所有節點能當前集羣自己想要的信息，而且保證不會發生衝突和錯誤。

目前，集羣的狀態都會保存在一個分佈式的鍵值存儲裏，這個存儲保證數據的一致性，目前三款常用的鍵值存儲工具是：

Zookeeper：Hadoop 的一個子項目，本來是作爲 Hadoop 集羣管理的數據存儲，目前也被應用到容器領域，開發語言是 Java。一個缺點是使用和維護比較複雜
Consul：HashiCorp 開發的分佈式服務發現和配置管理工具，docker swarm 集羣之前默認使用的就是這個
Etcd：CoreOS 旗下的鍵值存儲工具，是 kubernetes 默認的選擇，因此使用範圍很廣

有了分佈式鍵值存儲保證一致性，還需要工具把集羣數據自動寫入到裏面，並且需要格式化地讀取和解析數據。圍繞這一話題，周邊也有很多工具：

Registrator：自動監控 docker 容器，把每個容器的信息（IP、端口等）寫入到鍵值存儲中，支持 etcd、Consul
SkyDNS：基於 etcd 中的數據，對外提供 DNS 數據查詢，是對 etcd 的一層封裝。因爲使用 etcd，所以 DNS 查詢是實時的，避免了緩存導致的問題
CoreDNS：SkyDNS 繼承者，主要特點是插件系統能完成各種各樣的功能
ContainerPilot：Joyent 開源的容器服務發現工具，作爲容器的 init 系統運行，通過定義一個 json 文件，它會把容器相關的信息更新到 consul 中、進行健康檢查、運行用戶定義的代碼等

除外，還有兩個公司開源的服務發現工具要提一下：

SmartStack：Airbnb 開源的服務發現工具，由 nerve 和 synapse 組成，安裝和運維相對複雜了些
netflix OSS Eureka：netflix 開源的用於 AWS 的服務發現工具

總的來說，這些工具保證這個集羣的動態信息能統一保存，並保證一致性，這樣每個節點和容器就能正確地獲取到集羣當前的信息。

Service Management

伴隨着容器技術而變得火熱的一個話題是微服務，每個服務作爲容器或者 pod 運行，不同服務之間通過服務發現知道對方的地址進行通信。隨着集羣規模的增大、服務數量的增多，用戶的需求也不斷增加，微服務架構也面臨更多的問題：

認證和安全：爲了安全，調用方需要進行身份認證，而且不同的微服務只能運行不同的用戶訪問
統計：每個微服務需要知道它的使用情況，什麼人在什麼時候調用了什麼接口，方便監控和排查錯誤
健康檢查和自動恢復：系統能自動檢測服務的可用性，一旦不可用就重啓恢復或者從調用鏈中刪除
自動重試：如果調用某個服務發生錯誤，可以自動按照特定算法重試
限速：服務應該限制它能接收請求的速率，以保證它不會被過量的請求壓垮
服務可用性和雪崩：每個服務的可用性都不可能是 100% 的，簡單的串聯調用會降低整個集羣的可用性。如何保證每個服務不可用不會導致調用方的僵死
負載均衡：怎麼自動把請求分配到不同的後端進行處理，調度算法能否滿足各種各樣的需求
升級發佈：每個微服務的升級怎麼做到不影響其他服務，怎麼進行灰色發佈，出錯怎麼快速回滾
測試：單個服務可以獨立測試，但是整個集羣怎麼進行功能和性能測試
……

這些東西都是每個微服務平臺必須要考慮的，如果放在每個服務代碼中實現某些功能，不僅增加了每個服務的複雜性，也會導致重複的工作，所以，微服務需要更好的框架和平臺統一提供這些功能。總的來說，微服務雖然降低了單個服務的複雜性，但是把複雜性下沉到微服務管理平臺層面。

針對這些問題，有很多軟件和方案。對於負載均衡來說，HAProxy、nginx 和 F5 都是常用的方案，Traefik 是後起之秀，專門爲微服務設計；RPC 框架用來在微服務內部進行通信，因爲比 HTTP API 效率高而被大量使用，常用的用 Google 開源的 GRPC 、apache 旗下的 thrift 框架、Netflix 開源的自帶負載均衡的 ribbon 和 avra 數據序列化框架。

微服務 gateway 是統一化管理 API 註冊接入、權限認證、限速、日誌等功能，是微服務對外的接口。

Kong：Mashape 開源的項目，基於 openrestry（Nginx + Lua）的微服務網關，以插件爲中心組織功能
Netflix Zuul：Netflix 微服務網關，使用 Java 開發，因此適用於 Java 應用，需要添加代碼來使用 Zuul 提供的功能
Nginx：Nginx Plus 產品爲企業提供負載均衡、代理、微服務網關的各種功能
3scale：紅帽公司的 API 網關工具

這個領域也有一些公司在提供產品，比如 datawire 就專門爲 kubernetes 應用提供 API gateway 和自動化源碼部署的工具。

微服務開發框架 Hystrix 是 Netflix 開源的項目，能夠幫助程序處理微服務交互的超時處理和容錯的問題，提供熔斷、隔離、降級等功能，但是隻能用於 Java 語言項目，需要在程序中修改代碼。

特別要強調一下微服務領域最近比較熱門的概念：Service Mesh，它的主要想法是把微服務通用的功能單獨抽象爲一層，部署在容器管理平臺中，對應用透明，並且通過簡單自動化的接口來控制整個微服務的連通、灰度訪問、升級、降級等功能。

linkerd：開源的網絡代理服務，使用 scala 語言編寫，最早提出了 service mesh 的概念
envoy：C++ 編寫的網絡代理工具，和 linkerd 的定位相同，turbine labs 公司專門提供 envoy 的部署和管理工作
Istio：Google、IBM 和 Lyft 聯合發佈的微服務管理、配置和監控框架，使用 envoy 或者 linkerd 作爲內部 worker，控制層面負責配置和管理，深度集成到 kubernetes 平臺

service mesh 相較於之前微服務框架的最大優勢是它對業務是透明的，不需要像 Netflix 提供的很多微服務工具那樣對應用有侵入性，因此就不再和任何語言綁定，可以看做整個網絡棧的另一個抽象層。

5. Platform（平臺）

平臺這塊主要是基於容器技術做的更上面一層的封裝，有直接是接管公有云或者私有云的容器平臺，也有 Faas 這一類服務。

PaaS/Container Service

因爲容器技術的隔離性，以及對應用非常友好，因此可以直接拿來做 Paas 服務，當然也有種叫法是 Caas（Container as a service）。很多初創公司的業務也就是這塊，基於容器提供應用的發佈、升級、運維等管理工作。大部分公司做的事情都大同小異，因爲最終的需求是一樣的：讓應用的開發、部署、擴展、升級、運維更輕鬆，用戶無需關心基礎架構，只需要考慮如何去實現業務邏輯就行，主要的區別在於側重點，有些側重私有的數據中心部署和管理，有的側重 docker 容器的管理，有的測試 kubernetes 等容器集羣的維護，有的提供應用平臺，有的和公有云平臺深度集成……

heroku 是老牌的公有云類型的 PaaS 平臺，界面友好，成熟穩定，所有操作提供命令行實現自動化，提供完整的監控和日誌方案。

cloud foundry 和 openshift 是兩款重要的開源 Paas 平臺，其中 cloud foundry 是 Pivotal 開源，支持多種語言、框架、雲平臺，旨在讓開發者能夠忽略架構問題，快速部署和擴展應用；openshift 是 redhat 開源的，功能和 cloud foundry 差不多，網絡上有很多兩者的對比文章，這裏不再贅述。目前兩者都已經開始擁抱容器、docker、kubernetes 技術，希望能和容器深度集成。它們的特點是功能強大，可擴展性強，但是相應的，複雜程度也高。

隨着 kubernetes 的快速發展，很多以 kubernetes 爲容器管理平臺和應用管理的公司也都出來了，datawire 基於 kubernetes，側重於微服務的管理；containerShip 也是 kubernetes 的管理平臺，可以在多個雲平臺自動化部署和統一管理；Giant Swarm 提供混合雲和多租戶的 kubernetes 管理；kubermatic 能夠給用戶提供一鍵 kubernetes 集羣安裝和多集羣管理服務；Gravitational 提供多 region 的 kubernetes 集羣管理。

atomist 和 cloud66 側重於 devOps 流程；flynn 是基於 docker 容器技術的開源 PaaS 軟件，相比 cloud foundry 算是輕量級的實現；hyper.sh 比較有趣，它們以容器接口來提供虛擬機服務。

其他一些平臺提供的服務如下：

Apcera: 一個企業級的容器管理平臺，包括了運行容器所需編排、網絡和安全功能。Apcera的一個特點是支持傳統的應用，同時兼容傳統應用和雲原生應用，支持把前者遷移到雲上
apprenda：PaaS 雲平臺軟件公司，基於 kubernetes 打造的應用管理平臺，目前的商業版本 ACP(Apprenda Cloud Platform)提供了 kerberos 身份認證、應用審計等額外功能
convox：基於 AWS 的應用部署、管理、監控的平臺服務，提供了命令行實現任務的自動化
DC/OS：mesos 的企業級產品，是一套開源項目，基於 mesos 分佈式系統和 marathon，提供了編排、應用商店、GUI 界面等功能
Diamanti 也是一家解決方案公司，基於 kubernetes 調度平臺，同時支持 openshift PaaS 平臺
docker：沒有看錯，這裏的 docker 指的是 docker 公司，而不是容器技術。作爲一家商業化的公司，docker 也提供了商業化的產品和解決方案，開源的部分稱爲 docker CE（community edition），商業化產品爲 docker EE（Enterprise Edition）
mitantis cloud platform：原來有名的 openstack 公司，目前也逐漸接納 kubernetes，一起構建雲平臺
moby project：docker 公司把開源組件命名成 moby，意在把多個開源技術組件按照需求組合成滿足用戶需求的產品，docker CE 就是其中的產出
platform9：同時支持 openstack 和 kubernetes 爲核心的 Paas 服務
portainer.io：docker 的界面化管理工具
rancher：容器管理平臺，之前同時支持 swarm、mesos 和 kubernetes，目前把重心逐漸遷移到 kubernetes 上
tectonic：coreOS 推出的 kubernetes 集羣服務，集成了 quay 鏡像服務、coreOS 系統、和 promethues 監控等
ubuntu：ubuntu 系統也內嵌了 LXD 容器技術，提供更多的容器技術

這塊內容主要是容器創業公司，提供的都是基於 docker、kubernetes 或者其他容器技術的方案，因此做的事情大同小異，就不再一一介紹了，感興趣的可以根據圖中列出的公司自行了解。

Serverless/Event-based

容器技術把微服務的概念吵得火熱，隨後也讓 serverless 這個詞出現了大衆的面前。既然容器能夠屏蔽基礎設施，讓開發者只關心交付的應用（容器鏡像），那麼我們可不可以更進一步，讓開發者也不要關心交付的鏡像，只關注業務的核心邏輯呢？這就是 serverless 的想法，開發者定義好基於事件觸發的業務邏輯，其他一切都交給平臺，當用戶發出請求或者其他事件發生時，平臺會根據事先的配置自動運行響應的業務邏輯代碼，從而實現真正的按需服務。如果說容器關心的是應用，那麼 serverless 關心的則是函數。serverless 不是沒有服務器，而是不用關心服務器和系統。

serverless 是一個很新穎的技術，雖然理念非常好，但現階段還不適用於所有的應用，主要是因爲它的性能問題，以及距離成熟使用還缺少很多工具和方案，另外開發流程要接納這種理念還需要一段時間。

AWS Lambda 服務算是商業產品中比較成熟的，它的出現讓 serverless 從概念化和實驗化的東西變成了可行的方案。微軟家的雲平臺也推出了 Azure functions；Google 家對應的產品叫做 cloud functions，從命名來看亞馬遜略勝一籌。

openFaas、fission 和 kubeless 都是基於 docker 和 kubernetes 開源的 serverless 開發框架，如果要想打造自己的 serverless 平臺可以參考。

Apex：幫助構建、管理和運行 AWS Lambda 的工具
nstack 和 nuclio 都是專門用作數據分析的 Faas 軟件工具
OpenWhisk：apache 旗下的 serverless 框架，目前還是孵化項目
Oracle application container cloud
pubnub blocks：PubNub 提供的 serverless 服務，用於集成到自家的服務推送中
serverless 是一個集成工具，它能幫助開發者在 serverless 應該部署到 AWS Lambda、Azure Functions、GCP Cloud Functions、kubeless 等平臺，也就是說它封裝了這些平臺差異，提供了一致的接口，方便遷移和管理多 serverless 平臺應用

6. Observability & Analysis（觀察和分析）

基於雲原生的平臺建立起來之後，我們要保證整個平臺能夠正常工作，保證運行在其上的服務不會因爲平臺錯誤而導致不可用，而且還要知道應用整體的運行情況，提前對某些可能出錯的地方進行報警，一旦出錯能夠提供合適的信息便於調試和修復……這些都是觀察（observability）和分析（analysis）要做的工作，爲了方便下面統一使用監控（monitoring）一詞。

NOTE：對於監控、觀察、分析、日誌等詞語的使用並沒有非常嚴格的定義，監控是 IT 行業比較傳統的叫法，表示對應用和系統運行情況的數據統計和展示。目前有個叫法是觀察，分爲metrics/monitoring、logging 和 tracing 三個部分。爲了容易理解，我們使用監控一詞來代替，它廣義地包含了以上所有內容。

監控對於系統來說非常重要，沒有監控的平臺就像沒有儀表盤的飛機。監控的目標有幾點：

瞭解系統的使用情況，可以用於容量規劃、性能調優
提前或者及時發現問題，因爲硬件總是會有故障的軟件總是有 bug 的，及時發現能夠更快處理，不影響到應用的正常運行。這些問題包括網卡不能工作、硬盤老化、或者軟件異常等
幫助排查錯誤：當發現軟件bug或者硬件故障時，監控能夠幫忙分析哪個組件在什麼時候出現了問題，方便定位問題

Monitoring

簡單來說，監控就是了解應用和系統運行情況。

我們最常見的監控是對主機的監控，瞭解 CPU、內存、磁盤 IO、網絡等資源的使用數據，以此瞭解主機是否正常，是否需要加硬盤或者擴展集羣，是否有內存泄露等等。另外一個監控是應用的監控，不管是數據庫、緩存服務器、消息隊列、代理和緩存服務器，還是自己編寫的應用，我們需要知道它們的運行情況，這個監控依據每個應用而定，監控方法、監控的數據以及解讀方法對不同的應用來說會千差萬別。

而容器的出現，讓監控出現了另外一個維度：容器和平臺的監控。我們不僅要知道每個主機的運行數據，還需要知道每個容器的數據，這個容器使用的 CPU、內存、磁盤 IO 和網絡等，這個新的需求也就催生了新的監控思想和工具。

zabbix 是老牌的監控工具，功能強大，最近界面也改進了不少；Nagios 和 graphite 是另外兩個經典的監控工具。sensu 是一款較新的監控工具，Riemann 也能夠進行分佈式系統的集中式監控處理。

influxdb 和 openTSDB 都是時序數據庫，後者是基於 HBase 的。

AWS CloudWatch 是AWS 自家的監控工具，當然是負責 AWS 雲上的服務監控；Azure Log Analytics 是微軟家日誌監控工具。很多商業公司也提供各種各樣的監控產品：AppNeta、Axibase、APPDynamics、datadog、dynatrace、NewRelic 和 splunk 都提供應用級別的監控和數據分析業務。

再介紹一下經常聽到的監控工具：

Prometheus：時序數據庫，提供了工具能讀取 HTTP 接口暴露的數據保存起來，提供了豐富的查詢接口以及一個 web 界面
grafana：監控管理界面，能夠從多個數據源導入數據，提供優美的界面和豐富的面板配置
coscale：專門爲容器和微服務優化的監控平臺
sentry：錯誤收集工具，能夠集中式地查看應用的 crash report 和 traceback 信息
server density：專注於服務監控的 SaaS 服務平臺
statsD：etsy 開源的數據統計信息，可以把數據繼續發到後端的監控平臺，比如 graphite
sysdig：容器和 kubernetes 監控工具，同時提供了付費的監控服務

圖中列出的監控公司和工具還有很多，這塊的創業公司也很多，因爲監控的數據不像業務數據那樣機密，因此很多公司願意使用 SaaS 監控服務。

Logging

日誌容易理解，就是程序運行輸出的信息，它們是調試的利器，當程序出錯的時候，有效的日誌分析能夠快速定位問題。同時日誌也能承擔一部分的監控功能，反應系統運行是否正常。

fluented 是一個開源的基於數據流（stream）的日誌收集框架；graylog 是另外一個開源的選擇，它們的思想都是把日誌從系統各處收集起來進行統一分析、過濾和管理；elastic 提供 ELK（Elasticsearch、Logstash、Kibana）技術棧負責日誌收集，也提供在線的企業級 Saas 服務。

除了使用開源的組件自己搭建日誌服務平臺，還可以使用一些公司提供的在線日誌服務，只要把日誌數據導入到它們的平臺，不用關心日誌服務的維護工作。loggly 是一個在線的日誌分析服務，需要付費使用；logz.io 提供管理的 ELK 在線服務，提供 ELK as a service，並且可以基於 AI 對數據進行分析；另外一家聲稱支持 AI 分析的日誌服務公司是 loom systems；splunk 這家公司也提供日誌分析服務；papertrail、sematext、sumologic 也都提供類似的日誌分析服務。

tracing

隨着微服務的採用，用戶的一個請求可以中間會經過多個不同的微服務才最終得到應答。傳統的監控、日誌都是針對單個組件的分析，用來了解當前組件的健康和運行狀態，並不能給我們一個整體的動態的情況。

對於微服務來說，我們需要知道一個請求到底經過了哪些組件，每個組件耗費了多少時間，錯誤發生在中間的哪個步驟，每次調用的網絡延遲是多少等等。對於使用不同語言、開發框架、數據庫、和系統的微服務，我們需要有統一的跟蹤標準，這就是 tracing 要做的事情。分佈式的 tracing，一般都受到 google Daper 系統的設計影響。

opentracing是一個開放的 tracing 接口標準和文檔，提供了各種語言客戶端的實現，支持的 tracing 工具包括 Jaeger、appdash 和 Zipkin（twitter 開源）；Cloud Sleuth 是 spring cloud 全家桶中一員，主要負責 tracing 功能。

這些 tracing 工具都需要在應用中編寫對應的代碼，和 logging 和 metrics 類似，用戶可以自定義要 tracing 代碼塊的範圍和父子關係。此外，也有很多工具會自動化嵌入服務組件之間的 tracing 數據，比如之前講過的 Istio。

tracing 可以和 metrics 結合一起使用，tracing 負責組件和微服務之間的數據分析，metrics 負責單個組件內的性能數據監控。

7. Application（應用）

容器平臺最終還是要跑應用的，最主要的應用當然是各個公司的業務應用，除此之外還有一些比較通用的應用，這個表格裏也有列舉，可以根據需求提供類似應用市場的功能。

Database & Data Analytics

數據庫一直是軟件領域的核心組件，所以包括了很多老牌的數據庫軟件，比如 MySQL、DB2、oracle DB、postgreSQL、MariaDB 等關係型數據庫。基於這些傳統的數據庫也有很多周邊的工具和軟件，比如 vitess 這種數據庫集羣工具；阿里巴巴開源的 SQL 數據庫連接池工具 druid，它還同時提供了監控功能。

NoSQL 的發展也讓很多新型的數據庫出現在了我們的視野：有 redis、couchbase 這一類的 KV 數據庫；也有 MongoDB、rethinkDB、ravenDB 爲代表的文檔類數據庫；Cassandra、Hbase、vertica（列式關係數據庫）、scylla（kvm 之父的作品，旨在成爲下一代的 Cassandra 數據庫）這樣的 column 數據庫。它們最重要的特點是能夠輕鬆進行集羣擴容，不支持 SQL 查詢，因此接口上都以其他形式滿足用戶各種各樣的數據需求。

後來 newSQL 的概念出現，旨在結合 SQL 和 NoSQL 的優勢，還是以 SQL 方式使用，但同時支持快速橫向擴容和分佈式事務，google 內部的 F1/spanner 是這方面的先驅，發過論文但是沒有把項目開源，cockroachDB 和 TiDB 是這類數據庫的代表，都是開源項目。

其他相關的數據庫產品包括：

bigchainDB：區塊鏈數據庫
carbondata：面向大數據平臺的列數據文件存儲格式，由國內的華爲公司貢獻給 Apache 基金會
crate.io：基於 elasticsearch 的分佈式 SQL 數據庫，適用於需要快速搜索和聚合的查詢場景
MEMSQL：從名字也能看出來，這是一款內存數據庫，特點自然是性能高，
Noms：採用 git 思想的支持版本控制、fork和同步的數據庫
pachyderm：旨在成爲一個更現代的大數據處理平臺，資源調度基於 docker 和 kubernetes，底層是自己的分佈式存儲系統
iguazio 和 Qubole：自動化數據分析公司
SQL data warehouse：Azure SQL 數據庫產品

數據庫是整個軟件技術的基礎，現在有個很流行的觀念是：數據是一家公司最重要的資產之一。我們對數據庫的要求也是更快、更多、更好，所以會有很多數據庫相關的產品來解決各種各樣的數據存儲和處理需求。

Streaming

流處理與批處理對應，要求對海量數據的實時採集、計算和查詢，很多業務場景要求儘可能快得對數據進行分析，從而做出決策，比如傳感器、流量監控、股市行情、遊戲數據分析等，對此類需求也催生了很多實時處理工具。

Kinesis 是亞馬遜官方的流數據處理平臺，是其雲計算產品的一部分；cloud dataflow 是 google 的流處理產品；開源方面，Apex 是 apache 旗下開源的新型實時數據處理平臺；heron 是 twitter 開源的數據處理平臺，是 apache storm 的繼承者；spark 和 flink 支持流處理的同時也支持批處理操作，兩者定位非常相似，但內部實現的差距挺大

kafka 和 rabbitMQ 這類消息隊列可以做到數據的快速收集；nifi 是另一個 apache 項目，是一個數據整合和分發系統，專門爲數據流設計。

和大數據一樣，流處理這個領域也是 apache 佔據了大半的江山。

SCM（Source Code Management）

雖然容器讓產品以鏡像的作爲產出，但是代碼還是要維護的，最有名的社區源碼管理平臺自然是 github，gitlab 是開源自建 SCM 的推薦選擇，bitbucket 和 github 定義類似，提供免費也提供商業版本的服務。

Application Definition

應用定義並沒有明確的定義，大概要做的事情是屏蔽底層基礎設置、雲平臺以及容器運行時，封裝一個標準化的應用定義，從而實現應用自動化運行在任何地方。

apache brooklyn：應用管理平臺，可以通過簡單的操作把應用部署到常用的雲平臺
docker compose：定義多個容器的運行關係，docker compose 可以自動化管理這些容器的構建、生命週期、和網絡連通等問題
habitat：應用自動化管理平臺，可以定義應用，並且提供 Supervisor 來保證應用的正確運行
kubeVirt：用於 kubernetes 的虛擬機運行時標準接口
Packer：通過一個 yaml 文件，生成各種虛擬化平臺的鏡像
OPEN API：標準化的 API 接口，規範化應用和服務之間的調用

CI/CD

持續集成和持續部署主要用於自動化地處理所有的 ops 的工作，包括從代碼提交一直到應用部署到線上的整個過程的自動化。CI 側重於構建和測試，CD 側重於部署。

jenkins 算是這個領域的翹楚，非常經典的一款軟件，功能強大穩定，擁有很豐富的插件，算是開源界使用比較廣泛的工具
travis CI 爲開源的 github 項目免費，對私有項目收費，因此很多 github 上項目能看到它的身影
circleCI、 codeship、shippable、semaphore 都是 PaaS 產品，提供在線的 CI、CD 服務，一般提供免費和企業收費兩種版本
Bamboo 是 Atlassian 公司（開發了著名的 jira 和 confluence）旗下的產品，當然也是商業化的，需要付費才能使用
drone：原生支持 docker 的 CI 開源產品，使用 go 編寫，整個工作流都是基於 docker 的，最終也會自動化構建 docker 鏡像，push 到 registry 上
gitlab runner：gitlab 提供的 CI 工具，gitlab CI 和 gitlab runner 一起工作，前者做控制，後者實際執行任務
spinnaker：開源的 CI 軟件，可以在多個雲平臺運行構建和部署過程

網絡也有很多文章對 CI/CD 的軟件進行比較，比如這篇就比較了 jenkins vs travis vs teamcity vs codeship vs gitlab vs bamboo，其他的工具就不一一介紹了，感興趣可以自行搜索。

總結

如果做個總結的話，2017 年 CNCF 雲原生生態目前有如下的趨勢：

容器的標準化工作正在逐步完善，不會有太多新的功能出現，但是這方面的東西作爲整個體系的核心仍舊非常重要
容器調度和編排平臺的核心作用日漸突出，目前看來 kubernetes 是領先者，未來和其他競爭產品差距會進一步拉大。個人看法，kubernetes 將會竊取 docker 的果實，成爲整個系統最大的受益者
網絡和存儲有大量的產品和技術存在，但是目前沒有統一的標準和絕對的領先者。如何把這兩塊功能更好地和容器結合，需要新的突破
監控和日誌是容器平臺運維的重中之重，雲原生建設降低了應用部署、升級、構建、測試的難度，但是把難度下沉到容器平臺這塊，原來的運維工具和思路需要變化以適應新的容器平臺，瞭解集羣中正在發生的事情、及時發現可能出現的問題，才能保證業務應用穩定高效地運行
微服務怎麼更好地和容器集羣技術結合，是目前非常熱門的一個話題，因此 Istio、convoy、linkerd 這些技術發展迅速，也被很多人看好，認爲是下一代微服務
serverless 作爲容器更高一層的封裝，將會逐步進入我們的視野，繼容器（container）之後，應用（application）的概念將會發生新的變化和革命
應用仍舊是最終目的。保證應用快速穩定地測試、構建、部署、升級，支持；減少代碼開發時間人力成本；快速響應業務需求；降低應用的運維和使用成本……這些目標多久都不會變化

CNCF 列出的生態只是一個參考，很多軟件和公司並沒有出現在這裏，在構建雲原生應用時不必拘謹於此。構建雲原生架構是一個過程，不同的階段會選擇不同的工具和平臺，並沒有完全”標準”的做法。

另外一個沒有出現在這裏，但是隨平臺規模增長變得越發重要的話題是性能分析和優化，因爲這個話題並沒有統一的標準和方案，只能具體問題具體分析，而且整個過程比較複雜，所以很少有提供一站式方案的軟件和公司。

每個特定的問題都有多個工具和解決方案，這樣的情況就要求我們必須做出選擇，知道每個工具要解決什麼問題，有哪些取捨，和其他組件是否容易集成，社區活躍度……然後根據自身的情況和需求，找到最適合自己當前發展的工具。切不可一心求新求全，不然會帶來嚴重的後果：

社區並不友好或者活躍，對用戶需求響應很慢
選擇沒過一年就停止了開發，只能重新選擇新的工具
工具因爲開發過快或者組件複雜等原因不夠穩定，在使用過程中遇到很多問題，維護成本很高
選擇的工具棧過大，完全超過了自己現在的問題，導致需要額外的人員來維護這些多餘的功能
……

推薦的方式是循序漸進，以滿足最核心需求爲主去選擇合適的技術，優先使用比較穩定、文檔豐富和社區活躍的。充分了解選擇版本哪些功能是非常穩定可以直接使用的；哪些功能不太穩定，但是可以在開發和測試環境中小規模使用的；哪些功能是不穩定，需要測試開發或者等待社區進度的。如果有應用需要從舊環境遷移，編寫自動化工具，並提供回滾的功能，以灰度發佈的方式逐步遷移到容器集羣。對於新技術，可以花時間去跟進，在合適的時候及時引進。

切不可聽到別的公司使用了某個技術，自己就一定要用。如果沒有問題要解決，引入新工具只會帶來新的問題而已。

參考資料

原文鏈接