歡迎光臨
每天分享高質量文章

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

CNCF(Cloud Native Compute Foundation) 是 Linux 基金會旗下的一個組織,旨在推動以容器為中心的雲原生系統。從 2016 年 11 月,CNCF 開始維護了一個名為 Cloud Native Landscape [1]的 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 是這個領域的老大哥,以成熟穩定著稱,社區文件也更豐富

這篇博客[2]和這篇文章[3]比較了 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 和鏡像的標準化協議,這部分內容可以參考我之前的介紹文章[4]。

  • 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 開源的專案,基於 OpenResty(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 是 Red Hat 開源的,功能和 Cloud Foundry 差不多,網絡上有很多兩者的對比文章,這裡不再贅述。目前兩者都已經開始擁抱容器、Docker、Kubernetes 技術,希望能和容器深度集成。它們的特點是功能強大,可擴展性強,但是相應的,複雜程度也高。

隨著 Kubernetes 的快速發展,很多以 Kubernetes 為容器管理平臺和應用管理的公司也都出來了,Datawire 基於 Kubernetes,側重於微服務的管理;Containership 也是 Kubernetes 的管理平臺,可以在多個雲平臺自動化部署和統一管理;Giant Swarm 提供混合雲和多租戶的 Kubernetes 管理;Kubermatic 能夠給用戶提供一鍵 Kubernetes 集群安裝和多集群管理服務;Gravitational 提供多 Regions 的 Kubernetes 集群管理。

Atomist 和 Cloud 66 側重於 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)

  • Mirantis 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 系統、和 Prometheus 監控等

  • 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 檔案,生成各種虛擬化平臺的鏡像

  • OpenAPI:標準化的 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[5]》,其他的工具就不一一介紹了,感興趣可以自行搜索。


總結

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

  • 容器的標準化工作正在逐步完善,不會有太多新的功能出現,但是這方面的東西作為整個體系的核心仍舊非常重要

  • 容器調度和編排平臺的核心作用日漸突出,目前看來 Kubernetes 是領先者,未來和其他競爭產品差距會進一步拉大。個人看法,Kubernetes 將會竊取 Docker 的果實,成為整個系統最大的受益者

  • 網絡和儲存有大量的產品和技術存在,但是目前沒有統一的標準和絕對的領先者。如何把這兩塊功能更好地和容器結合,需要新的突破

  • 監控和日誌是容器平臺運維的重中之重,雲原生建設降低了應用部署、升級、構建、測試的難度,但是把難度下沉到容器平臺這塊,原來的運維工具和思路需要變化以適應新的容器平臺,瞭解集群中正在發生的事情、及時發現可能出現的問題,才能保證業務應用穩定高效地運行

  • 微服務怎麼更好地和容器集群技術結合,是目前非常熱門的一個話題,因此 Istio、Convoy、Linkerd 這些技術發展迅速,也被很多人看好,認為是下一代微服務

  • Serverless 作為容器更高一層的封裝,將會逐步進入我們的視野,繼容器(Container)之後,應用(Application)的概念將會發生新的變化和革命

  • 應用仍舊是最終目的。保證應用快速穩定地測試、構建、部署、升級,支持;減少代碼開發時間人力成本;快速響應業務需求;降低應用的運維和使用成本……這些標的多久都不會變化

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

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

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

  • 社區並不友好或者活躍,對用戶需求響應很慢

  • 選擇沒過一年就停止了開發,只能重新選擇新的工具

  • 工具因為開發過快或者組件複雜等原因不夠穩定,在使用過程中遇到很多問題,維護成本很高

  • 選擇的工具棧過大,完全超過了自己現在的問題,導致需要額外的人員來維護這些多餘的功能

  • ……

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

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

參考資料

  • Cloud Native Landscape Celebrates First Anniversary[6]

  • Monitoring in the time of cloud native[7]

  • Introducing Redpoint’s FaaS Landscape[8]

相關鏈接:

  1. https://github.com/cncf/landscape

  2. https://www.intigua.com/blog/puppet-vs.-chef-vs.-ansible-vs.-saltstack

  3. https://www.upguard.com/articles/the-7-configuration-management-tools-you-need-to-know

  4. http://cizixs.com/2017/11/05/oci-and-runc

  5. https://blog.takipi.com/jenkins-vs-travis-ci-vs-circle-ci-vs-teamcity-vs-codeship-vs-gitlab-ci-vs-bamboo/

  6. https://medium.com/memory-leak/cloud-native-landscape-celebrates-first-anniversary-69a4eb829505

  7. https://medium.com/@copyconstruct/monitoring-in-the-time-of-cloud-native-c87c7a5bfa3e

  8. https://medium.com/memory-leak/this-year-gartner-added-serverless-to-its-hype-cycle-of-emerging-technologies-reflecting-the-5dfe43d818f0

原文鏈接:http://cizixs.com/2017/12/30/cncf-cloud-native-landscape

基於Kubernetes的容器雲平臺實踐培訓

本次培訓包含:Kubernetes核心概念;Kubernetes集群的安裝配置、運維管理、架構規劃;Kubernetes組件、監控、網絡;針對於Kubernetes API接口的二次開發;DevOps基本理念;Docker的企業級應用與運維等,點擊識別下方二維碼加微信好友瞭解具體培訓內容

點擊閱讀原文鏈接即可報名。
赞(0)

分享創造快樂