摘要：自年月舉辦以來，規(guī)模持續(xù)增大。本屆大會議題數(shù)量接近，比去年規(guī)模較大的北美峰會多出了近一倍。同時還在華為伙伴公有云等云平臺上創(chuàng)建集群并接入了他們的平臺，以便于快速響應技術峰會等大型活動期間暴漲的計算量。

Kubernetes，云原生，service mesh，這些驚人的全球增長趨勢，令人欣喜之余迫不及待想要看看云原生在未來究竟會發(fā)展出怎樣一派繁榮的景象。

容器領域最具影響力的技術峰會之一 KubeCon + CloudNativeCon Europe 2018 于今年 5 月 2 日 -5 月 4 日在丹麥哥本哈根召開。來自華為、AWS、Azure、Google、IBM、Red Hat、VMWare 等 IT 巨頭的專家們分享了各自在 Kubernetes、安全、微服務、機器學習、Serverless、DevOps 等領域的技術經(jīng)驗。除了技術研討，本次大會也非常重視客戶案例，包括歐洲粒子研究中心（CERN），Spotify、維基百科、Booking.com、YouTube、NVIDIA、阿迪達斯、金融時報、eBay、挪威稅務管理中心等企業(yè)客戶分享了他們在生產(chǎn)環(huán)境中使用容器及其周邊技術的實踐案例。

KubeCon + CloudNativeCon 自 2015 年 11 月舉辦以來，規(guī)模持續(xù)增大。本屆大會議題數(shù)量接近 300，比去年規(guī)模較大的北美峰會多出了近一倍。參會人數(shù)更是達到了 4300 人，幾乎是去年柏林那次的 3 倍。值得一提的是，這一次的峰會，有很大部分與會者都是首次參加。而從活躍度來看，在成立不到 3 年的時間里，CNCF 已經(jīng)吸引了超過 2.2 萬開發(fā)者參與其項目代碼貢獻，來自 155 個國家超過 2.4 萬的用戶在 Edx 上注冊學習了 Kubernetes 的教學課程，55 個廠商提供了認證的 K8S 發(fā)行版。CNCF 的注冊會員數(shù)也呈現(xiàn)爆發(fā)式的增長，從去年的 81 家，發(fā)展到今年的 216 家（其中包括 52 家 end user 成員）。

這些驚人的全球增長趨勢，令人欣喜之余迫不及待想要看看 云原生在未來究竟會發(fā)展出怎樣一派繁榮的景象。

Kubernetes 商用成熟，多云成為必然趨勢

Kubernetes 作為 CNCF 的核心項目，也是第一個順利進入商用 Ready 的項目，圍繞它的生產(chǎn)實踐分享成為本次大會的一大焦點。

在第一天的 Keynote 上，來自歐洲核子研究中心（CERN）的生產(chǎn)實踐案例分享驚艷了全場。作為世界上較大的粒子物理研究中心，CERN 有著非常龐大的計算需求，對撞機每秒可產(chǎn)生 PB 級的數(shù)據(jù)，而即使經(jīng)過了硬件和軟件過濾器的兩級處理，仍然擁有每秒幾個 G 的數(shù)據(jù)量。這些數(shù)據(jù)仍然很龐大，但卻已經(jīng)能夠用于分析處理了。

在一個自建的數(shù)據(jù)中心，CERN 已經(jīng)搭建了 210 多個 K8S 集群，用來調度、管理擁有 32 萬核、1 萬多 hypervisor 的基礎設施。這些集群部署規(guī)模大小不一，小的只有幾十個節(jié)點，而較大的已經(jīng)到了上千節(jié)點。該數(shù)據(jù)中心保存了 250PB 的數(shù)據(jù)科研數(shù)據(jù)，并且保持每年 60-70PB 的速度增長；服務著 3 千多個用戶，進行 4 千多個項目的分析和研究。

為了便于統(tǒng)一管理這些集群中的工作負載，CERN 使用了 Kubernetes federation（集群聯(lián)邦）作為統(tǒng)一的平臺入口。同時 CERN 還在華為伙伴公有云 Open Telekom Cloud、Google Cloud、Azure、AWS 等云平臺上創(chuàng)建 K8S 集群并接入了他們的平臺，以便于快速響應技術峰會等大型活動期間暴漲的計算量。

在兩個或更多的云平臺上創(chuàng)建 K8S 集群并部署工作負載，已經(jīng)成為許多 K8S 采用者的常規(guī)做法。較之以往，用戶可以相對容易地在多個云平臺上同時部署業(yè)務，而享受到不同云平臺的優(yōu)勢服務。

不難發(fā)現(xiàn)，當下基于 Kubernetes 的容器服務，已經(jīng)幾乎成為各家云平臺的標配服務。得益于 K8S 軟件一致性認證項目的推動，越來越多的廠商已將提供認證的 K8S 發(fā)行版作為基本要求。多云的支持，已成為必然趨勢。而隨著 Cloud Native 的發(fā)展，相信在不久的將來，以 K8S 為核心的云原生平臺將真正實現(xiàn)“Cloud Agnostic”。用戶可以輕松地完成跨云、跨集群的 Workload 自由遷移。

如何消除 Cloud Native 背景下的安全焦慮

過去的兩年是 CNCF 的創(chuàng)業(yè)期，社區(qū)以 Kubernetes 和容器技術為平臺核心，圍繞可觀測性，可運維性，服務發(fā)現(xiàn)等領域進行能力補齊，構建了靈活易擴展的基礎平臺。

隨著容器、微服務等技術被越來越多地采用實施和運行于生產(chǎn)環(huán)境，越來越多的人關注到新興技術背景下的安全問題。如何消除這些顧慮，也正是 CNCF 在接下來發(fā)力的重點。

Runtime 方面，Google 帶來了他們自己的安全容器方案 —— gVisor。gVisor 提供新型沙箱容器運行時環(huán)境，能夠在保證輕量化優(yōu)勢的同時，提供與虛擬機類似的隔離效果。這與去年在 Austin 的 KubeCon 上宣布成立的 KataContainer 項目定位十分類似。KataContainer 源自于 Intel 的 Clear Container 和 hyper 的 runV，是一種基于輕量級虛擬化的容器技術。它通過在容器外加裝一層經(jīng)過大量裁剪和優(yōu)化的虛擬化，實現(xiàn)容器間的內核隔離。

與 KataContainer 略微不同，gVisor 通過在用戶空間內攔截應用程序系統(tǒng)調用并充當訪客內核（guest kernel），來提供強大的隔離邊界。另一處不同是 gVisor 不需要固定資源，它能夠隨時適應不斷變化的資源條件，這一點更像是普通 Linux 進程。gVisor 很像是一種超虛擬化操作系統(tǒng)，其與完整虛擬機相比擁有更靈活的資源利用方式與更低的固定成本，但這種靈活性的代價是其系統(tǒng)調用成本更高且應用程序兼容性略差。

gVisor 項目為容器安全性提供了新思路，豐富了安全容器技術的生態(tài)，雖然距離商用還有一段路要走，但就將安全容器推向主流市場而言，它未來帶來的幫助無疑會是巨大的。

Kubeflow 發(fā)布 0.1 版本，大幅降低機器學習框架部署門檻

近年來，機器學習的發(fā)展可謂突飛猛進。如何發(fā)揮 Kubernetes 的優(yōu)勢，將其作為部署平臺來提供便捷、可擴展的機器學習框架，是其中一個重點話題之一。Kubeflow 項目的發(fā)起，正是試圖找到一種最簡便的開源解決方案。

自去年北美的 KubeCon + CloudNativeCon 宣布項目成立之后，Kubeflow 已經(jīng)吸引了來自包括 Google、微軟、Redhat、華為、阿里云等在內的 20 多個組織的 70 多個貢獻者貢獻了 700 多條代碼提交，并獲得了 3.1k 的 star，增長速度之快躍居 Github 前 2%。本次發(fā)布的 0.1 版本提供了一套最精簡的軟件包，方便用戶開發(fā)、訓練和部署機器學習框架。

在之后的幾個月里，Kubeflow 項目將致力于 0.2 的發(fā)布，屆時將提供：

通過引導容器簡化設置；

優(yōu)化 GPU 集成；

支持更多的機器學習框架，如 Spark ML，XGBoost，sklearn；

支持 TF 服務的自動伸縮；

編程數(shù)據(jù)轉換，如 tf.transform。

而今年年底 Kubeflow 發(fā)布 1.0 版本之后，kubeflow 項目將尋求一個正式的治理社區(qū)，托管在 CNCF 或其他社區(qū)下。

Service Mesh 持續(xù)走俏，Istio 引領大潮

企業(yè)上云，容器和微服務是兩大利器。容器屏蔽了應用對環(huán)境的感知，簡化了軟件包分發(fā)的一致性問題，避免重復勞動。而轉向微服務的架構，屏蔽了應用對服務的感知，可以使業(yè)務團隊更專注于自身專業(yè)領域。關于如何做負載均衡、熔斷和遙測等等問題，都可以通過 Service Mesh 卸掉。高度的聚焦可以大幅度提高生產(chǎn)力。

Istio 作為最有希望成為 Service Mesh 事實標準的項目，自去年 5 月份發(fā)布以來，憑借與 K8S 的深度集成、零侵入性、易擴展等優(yōu)勢，加以 Google、IBM 等大廠商支持，迅速走紅。在不到一年的時間里獲得了 8000+ 的 star，吸引到近 200 個貢獻者參與代碼開發(fā)，成為去年以來 K8S 生態(tài)中最火熱的項目。

而在技術上，早期版本的性能問題也得到了一定程度的改善，p99 和 p99.9 時延有 10 倍左右的提升，2 vCPU 下的較大吞吐量也達到了 1700 QPS。大部分場景只有 10% 左右消耗，已經(jīng)能夠為人們接受。

本次大會中 Istio 的一大話題是多云和多集群。K8S 在多云之間提供了一致的平臺環(huán)境，但是如何實現(xiàn)跨云、跨集群的服務發(fā)現(xiàn)和流量控制卻一直懸而未決。在 K8S Federation 項目中，有一個簡單版的實現(xiàn)——本集群優(yōu)先路由。而 Istio 在發(fā)布的 0.8 版本中提供了多集群支持的特性，補齊 K8S 在多集群場景下的服務管理能力。

當然，Istio 作為一個剛滿一年的年輕項目，離生產(chǎn)可用還有一定的距離，但這并不削減人們對其使用的興趣。有調查顯示，已有相當一部分 K8S 的用戶開始在生產(chǎn)中部署使用 Istio。相信經(jīng)過 2018 年市場的打磨和沉淀，Istio 的成熟度會有一個質的飛越。

Serverless 領域發(fā)布事件標準 CloudEvents 0.1

隨著云技術的發(fā)展和越來越廣泛的采用，應用程序變得越來越分散，集成的數(shù)量也在不斷增長。人們越來越多地發(fā)布事件，在各種環(huán)境之間傳遞事件，利用事件驅動的設計模式構建應用。而另一方面，Serverless 概念興起，各大云平臺開始提供函數(shù)服務（事件驅動計算服務），支持的事件類型也在不斷增加。然而，各個平臺對于事件的描述卻各不相同。開發(fā)人員不得不學習、適配各個平臺特定的術語和語義。由于邏輯和基礎設施缺少一致的信息，開發(fā)者難以實現(xiàn)對事件的智能決策處理，事件的傳遞也因此頗受阻礙。

為了解決 Serverless 的互操作性問題，CNCF Serverless 工作組自去年年底完成白皮書之后，便致力于 Serverless 事件標準規(guī)范 —— CloudEvents 的制定。開源玩家包括華為，谷歌，微軟，IBM，紅帽等，都積極投入其中，為該項目做出了巨大的貢獻。

本次大會上發(fā)布的 CloudEvents 0.1 的范圍很簡單：提供一組一致的元數(shù)據(jù)，可以將其包含在事件數(shù)據(jù)中，使事件更容易適用于發(fā)布者、中間件、訂閱者和應用程序。簡而言之，就是一個標準的事件信封。

CloudEvents 的通用元數(shù)據(jù)使得事件更易于路由，扇出，追蹤，重放，并且基本保持“在線”。它們更便攜，更流暢，更易于跨環(huán)境傳輸。項目同時還在制定適用于每種協(xié)議的 CloudEvents 元數(shù)據(jù)映射到現(xiàn)有協(xié)議的規(guī)范。目前，網(wǎng)絡帶寬，成本和延遲仍然是主要挑戰(zhàn)。但 CloudEvents 簡單的元數(shù)據(jù)定義已經(jīng)可以在諸多場景中為數(shù)據(jù)帶來不錯的可移植性。

聚焦 K8S 加速創(chuàng)新，Cloud Native 編程框架應運而生

眾所周知，Kubernetes 早在設計之初就做到了架構上的松耦合，在而后的演進中又進行了多處插件化框架和可擴展性的改進和增強。Operator 概念的引入，更是標準化了一大部分對 K8S 有定制擴展需求的場景。

然而，Operator 本身的開發(fā)、測試、運維等，仍然有一定的門檻。開發(fā)者往往是尋找一個現(xiàn)有的 Operator 實現(xiàn)，刨除原有的業(yè)務代碼，填入自己應用相關的管理邏輯。完成這個過程往往需要對 K8S 的 API 有比較深入的了解，并且具備相當?shù)慕?jīng)驗和技術知識。而想要完整地實現(xiàn) Operator 的測試和運維，所需的額外工作就更多了。

Operator 開發(fā)框架旨在歸納已有實現(xiàn)中優(yōu)秀的實踐經(jīng)驗，形成一套標準，來幫助降低 K8S 上應用程序的開發(fā)、測試和運維的門檻。開發(fā)框架包含 3 部分 —— SDK、生命周期管理以及監(jiān)控度量。

Operator SDK 提供了開發(fā)者構建、測試和封裝 Operators 的工具。生命管理組件提供監(jiān)督跨 Kubernetes 集群運行的所有 Operator（及其關聯(lián)服務）的生命周期的安裝，更新和管理。而未來幾個月內將會實現(xiàn)的監(jiān)控度量組件，則會提供 CPU、內存等基礎指標以及自定義指標的監(jiān)控采集。

Operator 開發(fā)運維門檻的降低，對那些苦于業(yè)務改造上云后運維難、對 K8S 有定制需求的企業(yè)用戶來說，是一大福音。

本次 KubeCon 還帶來了一個十分新穎的項目——Ballerina。這是一門用于集成的 Cloud Native 編程語言。

Ballerina 的開發(fā)者認為，未來人們編寫的應用程序會越來越依賴于 API， 而集成則是打通各端點間彈性通信的重要規(guī)范。因此，他們將分布式系統(tǒng)集成的基本概念融合到語言中，設計了這門編譯型、事務性、靜態(tài)強類型編程語言，并提供了類型安全的并發(fā)環(huán)境。

Ballerina 支持文本和圖形語法，除常規(guī)的文本編寫代碼外，開發(fā)者還可以通過在設計器中編輯圖表來組織代碼。這更進一步降低了云原生應用的開發(fā)門檻，開發(fā)者可以輕松地實現(xiàn)具有分布式事務、可靠消息傳遞、流處理和工作流的微服務。

大幕拉開，真正的好戲才剛剛開始

過去，面向分布式應用開發(fā)，我們看到的是 Erlang、容錯編程和開發(fā)框架等，更多的是綁定于不同的編程社區(qū)和軟件棧。

現(xiàn)在，我們可以欣喜地看到，Kubernetes 憑借著它許多驚艷的特性和龐大的生態(tài)力量，已經(jīng)進入與諸多分布式系統(tǒng)走向商業(yè)化相似的發(fā)展歷程——日漸變得適合日常的開發(fā)者，適合日常的企業(yè)，最終成為被業(yè)界普遍采用的橫向技術。

而在以 K8S 為核心的基座之上，良好的開發(fā)監(jiān)控和運維體驗使得創(chuàng)新越來越快。眼下，諸如在微服務治理、機器學習等領域生態(tài)中，我們已經(jīng)可以見到 K8S 被用作標配的底座和強力的助推器。

在接下來的幾年里，市面上各類應用定義工具與服務將呈現(xiàn)爆發(fā)式增長，大大簡化云上部署運維應用的門檻。毫無疑問，將來如果一個軟件不能以某種形式直接或者插件化運行在 K8S 上，將沒有人為它們買單。

未來，K8S 的使用門檻將從白盒轉向黑盒，開發(fā)者甚至不用掌握太多 K8S 的知識，只需基于一套標準化原語，便可實現(xiàn)分布式系統(tǒng)風格的編程。人們不必在糾結代碼如何編譯，鏡像如何構建，測試與生產(chǎn)環(huán)境的配置有何不同，甚至連“kubernetes just run my code” 這樣的命令都不用執(zhí)行，尋常的一個代碼提交動作便可以觸發(fā)從編譯構建測試到生產(chǎn)運維全流程的交付流水線。而出現(xiàn)問題時的回滾也會是如此的簡單，因為代碼提交的操作都是原子的。

回顧當下，或許很多人會覺得 K8S 已經(jīng)逐漸穩(wěn)定，也逐漸變得無聊，但縱觀整個 Cloud Native 生態(tài)，許多新鮮有趣的項目正在雨后春筍般地涌現(xiàn) —— 畢竟，我們只是搭好了云原生的大舞臺，真正的好戲，才剛剛開始。

聲明：文章收集于網(wǎng)絡，如有侵權，請聯(lián)系小編及時處理，謝謝！

歡迎加入本站公開興趣群

軟件開發(fā)技術群

興趣范圍包括：Java，C/C++，Python，PHP，Ruby，shell等各種語言開發(fā)經(jīng)驗交流，各種框架使用，外包項目機會，學習、培訓、跳槽等交流

QQ群：26931708

Hadoop源代碼研究群

興趣范圍包括：Hadoop源代碼解讀，改進，優(yōu)化，分布式系統(tǒng)場景定制，與Hadoop有關的各種開源項目，總之就是玩轉Hadoop

QQ群：288410967?