除了技術分享，本次大會也非常重視客戶案例，包括Spotify、維基百科、Booking.com、Youtube、阿迪達斯、金融時報、eBay、挪威稅務管理中心等企業(yè)客戶將前來分享他們在生產環(huán)境中如何使用容器及其周邊技術。
Kubernetes 商用成熟
多云成為必然趨勢
Kubernetes作為CNCF的核心項目，也是第一個順利進入商用Ready的項目，圍繞它的生產實踐分享成為本次大會的一大焦點。
CERN
在第一天的Keynote上，來自歐洲核子研究中心（CERN）的生產實踐案例分享驚艷了全場。
作為世界上最大的粒子物理研究中心，CERN有著非常龐大的計算需求。在一個自建的數(shù)據(jù)中心，CERN已經搭建了210余個K8S集群來調度、管理擁有32萬核、1萬多hypervisor的基礎設施。這些集群部署規(guī)模大小不一，最小的只有幾十個節(jié)點，而最大的已經到了上千節(jié)點。
為了便于統(tǒng)一管理這些集群中的工作負載，CERN使用了K8S Federation（集群聯(lián)邦）作為統(tǒng)一的平臺入口。同時CERN還在華為伙伴公有云Open Telekom Cloud、Google Cloud、Azure、AWS等云平臺上創(chuàng)建K8S集群并接入了他們的平臺，以便于快速響應技術峰會等大型活動期間暴漲的計算量。
歐洲粒子研究中心的專家分享
使用集群聯(lián)邦管理k8s多集群的案例
在兩個或更多的云平臺上創(chuàng)建K8S集群，并部署工作負載，已經成為許多K8S采用者的常規(guī)做法。較之以往，用戶可以相對容易地在云平臺上同時部署業(yè)務，并享受到不同云平臺的優(yōu)勢。
不難發(fā)現(xiàn)，當下基于Kubernetes的容器服務，已經幾乎成為各家云平臺標配的服務。得益于K8S軟件一致性認證項目的推動，越來越多的廠商將提供認證的K8S發(fā)行版作為基本要求。多云的支持，已成為必然趨勢。而隨著CloudNative的發(fā)展，相信在不久的將來，以K8S為核心的云原生平臺將真正實現(xiàn)“Cloud Agnostic”。用戶可以真正輕松地實現(xiàn)，跨云、跨集群的Workload自由遷移。
核心與基礎問題已經解決
如何消除Cloud Native背景下的安全焦慮
過去的兩年是CNCF的創(chuàng)業(yè)期，社區(qū)以Kubernetes和容器技術為平臺核心，圍繞可觀測性，可運維性，微服務發(fā)現(xiàn)等領域進行能力補齊，構建了靈活易擴展的基礎平臺。
隨著容器、微服務等技術被越來越多地采用實施和運行于生產環(huán)境，越來越多的人關注到新興技術背景下的安全問題。如何消除這些顧慮，也正是CNCF在接下來發(fā)力的重點。
gVisor
Runtime方面，Google帶來了他們自己的安全容器方案 —— gVisor。gVisor提供新型沙箱容器運行時環(huán)境，能夠在保證輕量化優(yōu)勢的同時，提供與虛擬機類似的隔離效果。
gVisor通過在用戶空間內攔截應用程序系統(tǒng)調用并充當訪客內核（guest kernel）來提供隔離邊界。此外，gVisor不需要固定資源，它能夠隨時適應不斷變化的資源條件。
gVisor項目為容器安全性提供了新思路，豐富了安全容器技術的生態(tài)，雖然距離商用還有一段路要走，但就將安全容器推向主流市場而言，它未來帶來的幫助無疑會是巨大的。
Kubeflow發(fā)布0.1版本
大幅降低機器學習框架部署門檻
近年來，機器學習的發(fā)展可謂突飛猛進。如何發(fā)揮Kubernetes的優(yōu)勢，將其作為部署平臺來提供便捷、可擴展的機器學習框架，是其中一個重點話題之一。Kubeflow項目的發(fā)起，正是試圖找到一種最簡便的開源解決方案。
Kubeflow
自去年北美的KubeCon + CloudNativeCon宣布項目成立之后，Kubeflow已經吸引了來自包括Google、微軟、Redhat、華為、阿里云等在內的20多個組織的70多名貢獻者貢獻了700多條代碼提交，并獲得了3.1k的star，增長速度之快躍居Github前2%。
本次發(fā)布的0.1版本提供了一套最精簡的軟件包，方便用戶開發(fā)、訓練和部署機器學習框架。
在之后的幾個月里，Kubeflow項目將致力于0.2的發(fā)布。到今年年底Kubeflow發(fā)布1.0版本之后，kubeflow項目將尋求一個正式的治理社區(qū)，托管在CNCF或其他社區(qū)下。
Service Mesh持續(xù)走俏
Istio 引領大潮
企業(yè)上云，容器和微服務是兩大利器。容器屏蔽了應用對環(huán)境的感知，簡化了軟件包分發(fā)的一致性問題，避免重復勞動。而轉向微服務的架構，屏蔽了應用對服務的感知，可以使業(yè)務團隊更專注于自身專業(yè)領域。而關于如何做負載均衡、熔斷和遙測等等問題，都可以通過Service Mesh卸掉。高度的聚焦可以大幅度提高生產力。
Istio
Istio作為最有希望成為Service Mesh事實標準的項目，自去年5月份發(fā)布以來，憑借與K8S的深度集成、零侵入性、易擴展等優(yōu)勢，加以Google、IBM等大廠商支持，迅速走紅。在不到一年的時間里獲得了8000+的star，吸引到近200個貢獻者參與代碼開發(fā)，成為去年以來K8S生態(tài)中最火熱的項目。
本次大會中Istio的一大話題是多云和多集群。K8S在多云之間提供了一致的平臺環(huán)境，但是如何實現(xiàn)跨云、跨集群的服務發(fā)現(xiàn)和流量控制卻一直懸而未決。
在K8S Federation項目中，有一個簡單版的實現(xiàn)——本集群優(yōu)先路由。而Istio在最新發(fā)布的0.8版本中提供了多集群支持的特性，補齊K8S在多集群場景下的服務管理能力。
Serverless領域發(fā)布事件
標準CloudEvents 0.1
隨著云技術的發(fā)展和廣泛采用，應用程序變得越來越分散，集成的數(shù)量不斷增長，基于事件驅動的架構和Serverless的概念隨之興起。
為了解決Serverless的互操作性問題，CNCF Serverless工作組自去年年底完成白皮書之后，便致力于Serverless事件標準規(guī)范——CloudEvents的制定。開源玩家華為，谷歌，微軟，IBM，紅帽等，都積極投入其中，為該項目做出了巨大的貢獻。
本次大會上發(fā)布的CloudEvents 0.1的范圍很簡單：
- 提供一組一致的元數(shù)據(jù)，可以將其包含在事件數(shù)據(jù)中，使事件更容易適用于發(fā)布者、中間件、訂閱者和應用程序。簡而言之，就是一個標準的事件信封。
- CloudEvents的通用元數(shù)據(jù)使得事件更易于路由，扇出，追蹤，重放，并且基本保持“在線”。它們更便攜，更流暢，更易于跨平臺傳輸。目前，網絡帶寬，成本和延遲仍然是主要挑戰(zhàn)，但CloudEvents簡單的元數(shù)據(jù)定義已經可以在諸多場景中為數(shù)據(jù)帶來不錯的可移植性。
聚焦K8S加速創(chuàng)新
CloudNative編程框架應運而生
眾所周知，kubernetes早在設計之初就做到了架構上的松耦合，在而后的演進中又進行了多處插件化框架和可擴展性的改進和增強。Operator概念的引入，更是標準化了一大部分對k8s有定制擴展需求的場景。
然而，Operator本身的開發(fā)、測試、運維等，仍然有一定的門檻。Operator開發(fā)框架旨在歸納已有實現(xiàn)中優(yōu)秀的實踐經驗，形成一套標準，來幫助降低K8S上應用程序的開發(fā)、測試和運維的門檻。這對那些苦于業(yè)務改造上云后運維難、對K8S有定制需求的企業(yè)用戶來說，是一大福音。
Ballerina
本次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)力量，已經進入與諸多分布式系統(tǒng)走向商業(yè)化相似的發(fā)展歷程，日漸變得適合日常的開發(fā)者，適合日常的企業(yè)，最終成為被業(yè)界普遍采用的橫向技術。
未來
K8S的使用門檻將從白盒轉向黑盒，開發(fā)者不用掌握太多K8S的知識，只需基于一套標準化原語，便可實現(xiàn)分布式系統(tǒng)風格的編程。
人們不必再糾結代碼如何編譯，鏡像如何構建，測試與生產環(huán)境的配置有何不同，尋常的一個代碼提交動作便可以觸發(fā)從編譯構建測試到生產運維全流程的交付流水線。而出現(xiàn)問題時的回滾也會是如此的簡單，因為代碼提交的操作都是原子的。
回顧當下，或許很多人會覺得K8S已經逐漸穩(wěn)定，也逐漸變得無聊，但縱觀整個CloudNative生態(tài)，許多新鮮有趣的項目正在雨后春筍般地涌現(xiàn)——畢竟，我們只是搭好了云原生的大舞臺，真正的好戲，才剛剛開始。
