摘要:自年月舉辦以來,規模持續增大。本屆大會議題數量接近,比去年規模較大的北美峰會多出了近一倍。同時還在華為伙伴公有云等云平臺上創建集群并接入了他們的平臺,以便于快速響應技術峰會等大型活動期間暴漲的計算量。
Kubernetes,云原生,service mesh,這些驚人的全球增長趨勢,令人欣喜之余迫不及待想要看看云原生在未來究竟會發展出怎樣一派繁榮的景象。
容器領域最具影響力的技術峰會之一 KubeCon + CloudNativeCon Europe 2018 于今年 5 月 2 日 -5 月 4 日在丹麥哥本哈根召開。來自華為、AWS、Azure、Google、IBM、Red Hat、VMWare 等 IT 巨頭的專家們分享了各自在 Kubernetes、安全、微服務、機器學習、Serverless、DevOps 等領域的技術經驗。除了技術研討,本次大會也非常重視客戶案例,包括歐洲粒子研究中心(CERN),Spotify、維基百科、Booking.com、YouTube、NVIDIA、阿迪達斯、金融時報、eBay、挪威稅務管理中心等企業客戶分享了他們在生產環境中使用容器及其周邊技術的實踐案例。
KubeCon + CloudNativeCon 自 2015 年 11 月舉辦以來,規模持續增大。本屆大會議題數量接近 300,比去年規模較大的北美峰會多出了近一倍。參會人數更是達到了 4300 人,幾乎是去年柏林那次的 3 倍。值得一提的是,這一次的峰會,有很大部分與會者都是首次參加。而從活躍度來看,在成立不到 3 年的時間里,CNCF 已經吸引了超過 2.2 萬開發者參與其項目代碼貢獻,來自 155 個國家超過 2.4 萬的用戶在 Edx 上注冊學習了 Kubernetes 的教學課程,55 個廠商提供了認證的 K8S 發行版。CNCF 的注冊會員數也呈現爆發式的增長,從去年的 81 家,發展到今年的 216 家(其中包括 52 家 end user 成員)。
這些驚人的全球增長趨勢,令人欣喜之余迫不及待想要看看 云原生在未來究竟會發展出怎樣一派繁榮的景象。
Kubernetes 商用成熟,多云成為必然趨勢
Kubernetes 作為 CNCF 的核心項目,也是第一個順利進入商用 Ready 的項目,圍繞它的生產實踐分享成為本次大會的一大焦點。
在第一天的 Keynote 上,來自歐洲核子研究中心(CERN)的生產實踐案例分享驚艷了全場。作為世界上較大的粒子物理研究中心,CERN 有著非常龐大的計算需求,對撞機每秒可產生 PB 級的數據,而即使經過了硬件和軟件過濾器的兩級處理,仍然擁有每秒幾個 G 的數據量。這些數據仍然很龐大,但卻已經能夠用于分析處理了。
在一個自建的數據中心,CERN 已經搭建了 210 多個 K8S 集群,用來調度、管理擁有 32 萬核、1 萬多 hypervisor 的基礎設施。這些集群部署規模大小不一,小的只有幾十個節點,而較大的已經到了上千節點。該數據中心保存了 250PB 的數據科研數據,并且保持每年 60-70PB 的速度增長;服務著 3 千多個用戶,進行 4 千多個項目的分析和研究。
為了便于統一管理這些集群中的工作負載,CERN 使用了 Kubernetes federation(集群聯邦)作為統一的平臺入口。同時 CERN 還在華為伙伴公有云 Open Telekom Cloud、Google Cloud、Azure、AWS 等云平臺上創建 K8S 集群并接入了他們的平臺,以便于快速響應技術峰會等大型活動期間暴漲的計算量。
在兩個或更多的云平臺上創建 K8S 集群并部署工作負載,已經成為許多 K8S 采用者的常規做法。較之以往,用戶可以相對容易地在多個云平臺上同時部署業務,而享受到不同云平臺的優勢服務。
不難發現,當下基于 Kubernetes 的容器服務,已經幾乎成為各家云平臺的標配服務。得益于 K8S 軟件一致性認證項目的推動,越來越多的廠商已將提供認證的 K8S 發行版作為基本要求。多云的支持,已成為必然趨勢。而隨著 Cloud Native 的發展,相信在不久的將來,以 K8S 為核心的云原生平臺將真正實現“Cloud Agnostic”。用戶可以輕松地完成跨云、跨集群的 Workload 自由遷移。
如何消除 Cloud Native 背景下的安全焦慮
過去的兩年是 CNCF 的創業期,社區以 Kubernetes 和容器技術為平臺核心,圍繞可觀測性,可運維性,服務發現等領域進行能力補齊,構建了靈活易擴展的基礎平臺。
隨著容器、微服務等技術被越來越多地采用實施和運行于生產環境,越來越多的人關注到新興技術背景下的安全問題。如何消除這些顧慮,也正是 CNCF 在接下來發力的重點。
Runtime 方面,Google 帶來了他們自己的安全容器方案 —— gVisor。gVisor 提供新型沙箱容器運行時環境,能夠在保證輕量化優勢的同時,提供與虛擬機類似的隔離效果。這與去年在 Austin 的 KubeCon 上宣布成立的 KataContainer 項目定位十分類似。KataContainer 源自于 Intel 的 Clear Container 和 hyper 的 runV,是一種基于輕量級虛擬化的容器技術。它通過在容器外加裝一層經過大量裁剪和優化的虛擬化,實現容器間的內核隔離。
與 KataContainer 略微不同,gVisor 通過在用戶空間內攔截應用程序系統調用并充當訪客內核(guest kernel),來提供強大的隔離邊界。另一處不同是 gVisor 不需要固定資源,它能夠隨時適應不斷變化的資源條件,這一點更像是普通 Linux 進程。gVisor 很像是一種超虛擬化操作系統,其與完整虛擬機相比擁有更靈活的資源利用方式與更低的固定成本,但這種靈活性的代價是其系統調用成本更高且應用程序兼容性略差。
gVisor 項目為容器安全性提供了新思路,豐富了安全容器技術的生態,雖然距離商用還有一段路要走,但就將安全容器推向主流市場而言,它未來帶來的幫助無疑會是巨大的。
Kubeflow 發布 0.1 版本,大幅降低機器學習框架部署門檻
近年來,機器學習的發展可謂突飛猛進。如何發揮 Kubernetes 的優勢,將其作為部署平臺來提供便捷、可擴展的機器學習框架,是其中一個重點話題之一。Kubeflow 項目的發起,正是試圖找到一種最簡便的開源解決方案。
自去年北美的 KubeCon + CloudNativeCon 宣布項目成立之后,Kubeflow 已經吸引了來自包括 Google、微軟、Redhat、華為、阿里云等在內的 20 多個組織的 70 多個貢獻者貢獻了 700 多條代碼提交,并獲得了 3.1k 的 star,增長速度之快躍居 Github 前 2%。本次發布的 0.1 版本提供了一套最精簡的軟件包,方便用戶開發、訓練和部署機器學習框架。
在之后的幾個月里,Kubeflow 項目將致力于 0.2 的發布,屆時將提供:
通過引導容器簡化設置;
優化 GPU 集成;
支持更多的機器學習框架,如 Spark ML,XGBoost,sklearn;
支持 TF 服務的自動伸縮;
編程數據轉換,如 tf.transform。
而今年年底 Kubeflow 發布 1.0 版本之后,kubeflow 項目將尋求一個正式的治理社區,托管在 CNCF 或其他社區下。
Service Mesh 持續走俏,Istio 引領大潮
企業上云,容器和微服務是兩大利器。容器屏蔽了應用對環境的感知,簡化了軟件包分發的一致性問題,避免重復勞動。而轉向微服務的架構,屏蔽了應用對服務的感知,可以使業務團隊更專注于自身專業領域。關于如何做負載均衡、熔斷和遙測等等問題,都可以通過 Service Mesh 卸掉。高度的聚焦可以大幅度提高生產力。
Istio 作為最有希望成為 Service Mesh 事實標準的項目,自去年 5 月份發布以來,憑借與 K8S 的深度集成、零侵入性、易擴展等優勢,加以 Google、IBM 等大廠商支持,迅速走紅。在不到一年的時間里獲得了 8000+ 的 star,吸引到近 200 個貢獻者參與代碼開發,成為去年以來 K8S 生態中最火熱的項目。
而在技術上,早期版本的性能問題也得到了一定程度的改善,p99 和 p99.9 時延有 10 倍左右的提升,2 vCPU 下的較大吞吐量也達到了 1700 QPS。大部分場景只有 10% 左右消耗,已經能夠為人們接受。
本次大會中 Istio 的一大話題是多云和多集群。K8S 在多云之間提供了一致的平臺環境,但是如何實現跨云、跨集群的服務發現和流量控制卻一直懸而未決。在 K8S Federation 項目中,有一個簡單版的實現——本集群優先路由。而 Istio 在發布的 0.8 版本中提供了多集群支持的特性,補齊 K8S 在多集群場景下的服務管理能力。
當然,Istio 作為一個剛滿一年的年輕項目,離生產可用還有一定的距離,但這并不削減人們對其使用的興趣。有調查顯示,已有相當一部分 K8S 的用戶開始在生產中部署使用 Istio。相信經過 2018 年市場的打磨和沉淀,Istio 的成熟度會有一個質的飛越。
Serverless 領域發布事件標準 CloudEvents 0.1
隨著云技術的發展和越來越廣泛的采用,應用程序變得越來越分散,集成的數量也在不斷增長。人們越來越多地發布事件,在各種環境之間傳遞事件,利用事件驅動的設計模式構建應用。而另一方面,Serverless 概念興起,各大云平臺開始提供函數服務(事件驅動計算服務),支持的事件類型也在不斷增加。然而,各個平臺對于事件的描述卻各不相同。開發人員不得不學習、適配各個平臺特定的術語和語義。由于邏輯和基礎設施缺少一致的信息,開發者難以實現對事件的智能決策處理,事件的傳遞也因此頗受阻礙。
為了解決 Serverless 的互操作性問題,CNCF Serverless 工作組自去年年底完成白皮書之后,便致力于 Serverless 事件標準規范 —— CloudEvents 的制定。開源玩家包括華為,谷歌,微軟,IBM,紅帽等,都積極投入其中,為該項目做出了巨大的貢獻。
本次大會上發布的 CloudEvents 0.1 的范圍很簡單:提供一組一致的元數據,可以將其包含在事件數據中,使事件更容易適用于發布者、中間件、訂閱者和應用程序。簡而言之,就是一個標準的事件信封。
CloudEvents 的通用元數據使得事件更易于路由,扇出,追蹤,重放,并且基本保持“在線”。它們更便攜,更流暢,更易于跨環境傳輸。項目同時還在制定適用于每種協議的 CloudEvents 元數據映射到現有協議的規范。目前,網絡帶寬,成本和延遲仍然是主要挑戰。但 CloudEvents 簡單的元數據定義已經可以在諸多場景中為數據帶來不錯的可移植性。
聚焦 K8S 加速創新,Cloud Native 編程框架應運而生
眾所周知,Kubernetes 早在設計之初就做到了架構上的松耦合,在而后的演進中又進行了多處插件化框架和可擴展性的改進和增強。Operator 概念的引入,更是標準化了一大部分對 K8S 有定制擴展需求的場景。
然而,Operator 本身的開發、測試、運維等,仍然有一定的門檻。開發者往往是尋找一個現有的 Operator 實現,刨除原有的業務代碼,填入自己應用相關的管理邏輯。完成這個過程往往需要對 K8S 的 API 有比較深入的了解,并且具備相當的經驗和技術知識。而想要完整地實現 Operator 的測試和運維,所需的額外工作就更多了。
Operator 開發框架旨在歸納已有實現中優秀的實踐經驗,形成一套標準,來幫助降低 K8S 上應用程序的開發、測試和運維的門檻。開發框架包含 3 部分 —— SDK、生命周期管理以及監控度量。
Operator SDK 提供了開發者構建、測試和封裝 Operators 的工具。生命管理組件提供監督跨 Kubernetes 集群運行的所有 Operator(及其關聯服務)的生命周期的安裝,更新和管理。而未來幾個月內將會實現的監控度量組件,則會提供 CPU、內存等基礎指標以及自定義指標的監控采集。
Operator 開發運維門檻的降低,對那些苦于業務改造上云后運維難、對 K8S 有定制需求的企業用戶來說,是一大福音。
本次 KubeCon 還帶來了一個十分新穎的項目——Ballerina。這是一門用于集成的 Cloud Native 編程語言。
Ballerina 的開發者認為,未來人們編寫的應用程序會越來越依賴于 API, 而集成則是打通各端點間彈性通信的重要規范。因此,他們將分布式系統集成的基本概念融合到語言中,設計了這門編譯型、事務性、靜態強類型編程語言,并提供了類型安全的并發環境。
Ballerina 支持文本和圖形語法,除常規的文本編寫代碼外,開發者還可以通過在設計器中編輯圖表來組織代碼。這更進一步降低了云原生應用的開發門檻,開發者可以輕松地實現具有分布式事務、可靠消息傳遞、流處理和工作流的微服務。
大幕拉開,真正的好戲才剛剛開始
過去,面向分布式應用開發,我們看到的是 Erlang、容錯編程和開發框架等,更多的是綁定于不同的編程社區和軟件棧。
現在,我們可以欣喜地看到,Kubernetes 憑借著它許多驚艷的特性和龐大的生態力量,已經進入與諸多分布式系統走向商業化相似的發展歷程——日漸變得適合日常的開發者,適合日常的企業,最終成為被業界普遍采用的橫向技術。
而在以 K8S 為核心的基座之上,良好的開發監控和運維體驗使得創新越來越快。眼下,諸如在微服務治理、機器學習等領域生態中,我們已經可以見到 K8S 被用作標配的底座和強力的助推器。
在接下來的幾年里,市面上各類應用定義工具與服務將呈現爆發式增長,大大簡化云上部署運維應用的門檻。毫無疑問,將來如果一個軟件不能以某種形式直接或者插件化運行在 K8S 上,將沒有人為它們買單。
未來,K8S 的使用門檻將從白盒轉向黑盒,開發者甚至不用掌握太多 K8S 的知識,只需基于一套標準化原語,便可實現分布式系統風格的編程。人們不必在糾結代碼如何編譯,鏡像如何構建,測試與生產環境的配置有何不同,甚至連“kubernetes just run my code” 這樣的命令都不用執行,尋常的一個代碼提交動作便可以觸發從編譯構建測試到生產運維全流程的交付流水線。而出現問題時的回滾也會是如此的簡單,因為代碼提交的操作都是原子的。
回顧當下,或許很多人會覺得 K8S 已經逐漸穩定,也逐漸變得無聊,但縱觀整個 Cloud Native 生態,許多新鮮有趣的項目正在雨后春筍般地涌現 —— 畢竟,我們只是搭好了云原生的大舞臺,真正的好戲,才剛剛開始。
聲明:文章收集于網絡,如有侵權,請聯系小編及時處理,謝謝!
歡迎加入本站公開興趣群
軟件開發技術群
興趣范圍包括:Java,C/C++,Python,PHP,Ruby,shell等各種語言開發經驗交流,各種框架使用,外包項目機會,學習、培訓、跳槽等交流
QQ群:26931708
Hadoop源代碼研究群
興趣范圍包括:Hadoop源代碼解讀,改進,優化,分布式系統場景定制,與Hadoop有關的各種開源項目,總之就是玩轉Hadoop
QQ群:288410967?
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/3496.html
摘要:本屆大會議題數量接近,比去年規模較大的北美峰會多出了近一倍。同時還在華為伙伴公有云等云平臺上創建集群并接入了他們的平臺,以便于快速響應技術峰會等大型活動期間暴漲的計算量。Kubernetes,云原生,service mesh,這些驚人的全球增長趨勢,令人欣喜之余迫不及待想要看看云原生在未來究竟會發展出怎樣一派繁榮的景象。 容器領域最具影響力的技術峰會之一 KubeCon + Cloud...
摘要:百度企業智能大會現場新一輪搶灘賽將放在位的百度云,自然有著自己的考量。站在百度云的角度而言,云計算進入到綜合實力的較量,恰恰是以己所長攻彼之短的最佳時機。2018年下半年,To B迎來了從未有過的熱度,也把云計算重新捧上了風口浪尖。和幾年前新興業務的身份不同,處于風暴中心的云計算,早已成為互聯網巨頭和創業者們最激烈的戰場,并相繼宣布了醞釀許久的動作。阿里在財報中努力擴大云計算的占比,并視之為...
摘要:就國內市場而言,百度云選擇三位一體戰略的時候不乏長遠性思考。百度云將放在位的另一個用意正是在領域樹立差異化優勢,并通過等深耕垂直場景。至少就目前來看,百度云已經找到了最適合自己的競爭方式。2018年下半年,To B迎來了從未有過的熱度,也把云計算重新捧上了風口浪尖。和幾年前新興業務的身份不同,處于風暴中心的云計算,早已成為互聯網巨頭和創業者們最激烈的戰場,并相繼宣布了醞釀許久的動作。阿里在財...
摘要:云原生路徑谷歌花了十幾年時間開發應用和提煉云原生計算的原則。和云原生模式將通過滾動更新版本控制和新組件新功能的金絲雀部署來提高生命周期管理。此外,用戶將受益于可自我恢復的基礎設施,使更易于管理,對核心服務和單個計算節點的故障恢復更具有彈性。 Mirantis是OpenStack的主要貢獻者,今天他宣布將使用Kubernetes作為底層編排引擎重寫其私有云平臺。我們認為這是推進OpenS...
摘要:在這篇文章中,華裔血統的分享了有價值的會議收獲等首次訪問中國的多元化獎學金經歷。在之后,我感謝我一生中第一次來的中國,作為華裔人士和多元化獎學金獲得者。和贊助方案出爐和多元化獎學金現正接受申請和即將首次合體落地中國 CNCF為開發者和學生提供多元化獎學金,以參加KubeCon + CloudNativeCon China 2018。在這篇文章中,華裔血統的Emmelyn Wang分享了...
閱讀 3717·2021-10-11 10:59
閱讀 1300·2019-08-30 15:44
閱讀 3478·2019-08-29 16:39
閱讀 2887·2019-08-29 16:29
閱讀 1800·2019-08-29 15:24
閱讀 807·2019-08-29 15:05
閱讀 1264·2019-08-29 12:34
閱讀 2302·2019-08-29 12:19