PaaS將吞噬云計算?Kubernetes的市場沖擊波

dzpp8015 6年前發布 | 35K 次閱讀 PaaS Kubernetes

2017年是Kubernetes的勝利之年,很多人還不明白這意味著什么。但如果看一下云計算業界的動向,你會發現,Kubernetes的影響正在擴散。

在本文中我將分享我們的發現,并試圖說服你:基于容器+Kubernetes的新型PaaS將會成為云計算的主流。

我將引用很多內容,包含國內外專家的真知灼見,讓你看到專家是如何看待此事的,以及分享我們自己做的調研和采訪,看看業界實際在發生什么。

Kubernetes(k8s)在很短的一段時間內走過了很長的一段路。僅僅兩年以前,它還需要與CoreOS的Fleet、Docker Swarm、Cloud Foundry Diego、HashiCorp的Nomad、Kontena、Rancher的Cattle、Apache Mesos、Amazon ECS等進行競爭,來證明自己比那些產品都要優秀。而現如今已經是完全不同的一幅景象了。其中的一些公司公開宣布了項目的終止并且開始加入到Kubernetes陣營中,還有一些公司沒有公開宣布自己項目的失敗,而是在戰略上宣布了對Kubernetes的部分支持或者完全整合,這也就意味著他們的容器編排工具將會安靜而緩慢地死掉。不論是哪一種情況,k8s都是最后一個活下來的平臺。除此之外,不僅僅是用戶和白金贊助商們,越來越多的大公司都將繼續加入到Kubernetes的生態系統中,將自己的業務完全押注于Kubernetes的成功。我們首先能想到的有Google的Kubernetes Engine、Red Hat的OpenShift、Microsoft的Azure Container Service、IBM的 Cloud Container Service、Oracle的Container Engine。

但是這些意味著什么呢?首先,這意味著開發人員必須要掌握一個與90%的容器工作相關的容器編排平臺。這是一個學習Kubernetes很好的理由。同時這還意味著我們已經深深地依賴于Kubernetes,Kubernetes就像容器領域中的Amazon。在Kubernetes上進行設計、實現和運行應用程序可以讓你在不同的云提供商、Kubernetes發行版和服務提供商之間自由地對應用程序進行遷移。它能讓你有機會找到Kubernetes認證的開發人員,讓他們來開發項目并且在以后持續提供支持。Kubernetes不是VM,也不是JVM,它是全新的應用程序可移植層,它是大家共同的選擇。

——Bilgin Ibryam,Red Hat首席架構師(Source)

基于“容器+k8s”的新型PaaS

Kubernetes并不是傳統意義上的PaaS,事實上,傳統PaaS可以基于Kubernetes構建。

在過去,PaaS經歷了這樣的發展:

  • 第一代:如最早的Heroku,嚴格限定的運行時,不可修改的環境。對于Ruby on Rails這種小型單體應用來說很合適。
  • 第二代:Cloud Foundry (DEA版本) ,可以簡單的自定義環境,包括云端構建。也開始對多服務的應用有所支持。
  • 第三代:Cloud Foundry (Diego版本),如當前版本的GAE和AWS Elastic Beanstalk,它們都經過之前兩代PaaS迭代而來。在這個版本里增加了對容器的支持,更自由的環境配置,對微服務的支持更強大。
  • 第四代:Kubernetes以及其它容器編排引擎。這一代的平臺變成了Kubernetes本身,它是面向云原生應用計算的、徹底基于分布式和容器的計算平臺。

第四代PaaS的關注點也和之前不一樣,我們可以把前三代PaaS稱為應用級PaaS(Application PaaS),它們關注的是應用的運行,第四代稱為容器PaaS,或者CaaS、KaaS,它們關注的是應用的打包和分發。

第四代PaaS當然也可以使用其它的技術達到類似的效果,但就像前面所說的,Kubernetes贏得了這場競爭。

從下面的PaaS平臺架構圖中可以看到,我用了 Docker+Kubernetes 層來做了一個“技術緩沖層”。也就是說,如果沒有 Docker 和 Kubernetes,構建 PaaS 將會復雜很多。當然,如果你正在開發一個類似 PaaS 的平臺,那么你會發現自己開發出來的東西會跟 Docker 和 Kubernetes 非常像。相信我,最終你還是會放棄自己的輪子而采用 Docker+Kubernetes 的。

——陳皓 《洞悉PaaS平臺的本質》

PaaS將吞噬云計算?Kubernetes的市場沖擊波

這是一個大而全的PaaS平臺架構,實際中可以根據需求進行裁剪。

業界趨勢:全在做PaaS

如果我們看一下業界,會發現,從公有云到私有云,從傳統企業到互聯網新貴,都在擁抱Kubernetes,都在做PaaS。

公有云全在做k8s和容器

從AWS到Google Cloud、微軟Azure,到國內的阿里云、騰訊云、華為云等,都在提供k8s容器服務。如果一個公有云到現在還沒有提供k8s服務,或者沒有計劃做,那么可以認為它的技術已經落后于時代了。

公有云提供的k8s和容器服務,具體來說分為兩類:

一類是提供多租戶的單容器實例,這種其實類似于上面提到的第三類PaaS,用戶創建的是單個容器,值得一提的是,這類PaaS仍可構建于k8s之上,并且不少云計算廠商已經采用這種方案。另外,由KataContainer技術逐漸應用到生產環境,帶來將無服務器概念和容器結合的Serverless Container Cloud理念,讓容器也能兼具傳統虛擬化的優點,讓這類服務的未來充滿了想象空間。

Kubernetes所要扮演的角色,乃是取代傳統的Infrastructure Layer并鼓勵技術人員進行上層的“二次創新”,而并不是直接面對最終用戶。真正為最終用戶提供云服務的,很大概率應該是構建于Kubernetes之上的、更加簡潔高效的服務型API,而Serverless,尤其是Serverless Container Cloud的設計,正是這種需求下最為貼切的實現方式之一。

——張磊,浙江大學博士研究員,Hyper項目成員,Kubernetes項目資深成員與社區維護者。

另一類是提供Kubernetes引擎,這種情況下用戶創建的是Kubernetes集群,如GKE、Azure AKS、騰訊云CCS等。

第二類服務是目前公有云研發的重點,發布的時間基本集中在去年下半年到現在,我們采訪和調研了微軟Azure、騰訊云、華為云,情況基本類似,具體內容可進一步閱讀:

劍指Kubernetes 揭秘騰訊云的PaaS技術選型策略

華為云的Kubernetes實踐之路

k8s將成私有云的標準解法

私有云的情況分為兩類,一類是企業搭建數據中心和私有云自用,另一類是服務提供商,為客戶提供私有云解決方案。在這兩類情況中我們都看到Kubernetes被使用的越來越多,并且無論是企業、服務提供商,還是客戶都嘗到了Kubernetes PaaS的甜頭。

對于自用型私有云來說,系統的演進是一個復雜的問題,盲目采用新技術有時不僅無助于業務,還造成資源浪費。k8s的表現如何呢?我們讓京東的經驗來說話吧:

(采用容器和Kubernetes的)JDOS 2.0接入了包含大數據、Web利用、深度學習等多種類型的利用,并為每一種利用依據類型采取了不同的資源限制方式,并打上了Kubernetes的不同標簽。基于多樣的標簽,我們實現了更加多樣和靈便的調度方式,并在部份IDC試驗性地混合部署了在線任務和離線任務。相較于1.0,總體資源應用率提升了約30%。

——鮑永成,京東基礎平臺部技術總監

對于服務提供商來說,Kubernetes健康的生態可以保證它們有大量的第三方軟件和工具使用,同時PaaS易于開發和代碼/應用復用的特性,也降低了它們交付項目的成本,并縮短了交付周期。

對于客戶來說,基于Kubernetes的PaaS可以實現應用自由遷移,這使企業可以采用多重云策略,并變相提升了對供應商的議價能力。

云計算經過了十多年的發展,已然進入的云原生的新階段,企業應用優先考慮部署在云環境,如何順應云原生的大潮,使用容器和Kubernetes構建云原生平臺,踐行DevOps理念和敏捷IT,開源軟件和社區如何助力IT轉型,所有這些問題的解決方案就是PaaS平臺,其對于企業的重要性不言而喻。

——宋凈超 TalkingData容器平臺負責人(Source)

一些業界的經驗可參考:

京東如何從OpenStack遷移至Kubernetes

你知道嗎?傳統企業已經在用最新互聯網架構了

運維也需要PaaS

騰訊互娛的運維團隊,需要為公司的在線游戲提供運維能力,這可能是中國挑戰最大要求最高的運維服務,因此他們有數百人的研發團隊,他們的做法可以很大程度上代表運維的發展方向,而不斷思考和迭代的結果就是自研了一套PaaS平臺藍鯨。藍鯨本身不使用Docker、Kubernetes等,完全自研,但我們可以看到,運維的發展方向就是PaaS。

PaaS將吞噬云計算?Kubernetes的市場沖擊波

PaaS本身與DevOps的理念完全契合,它改變了傳統運維的職責,讓他們變成運維開發,為企業研發運維工具乃至是PaaS平臺。而對于沒有藍鯨團隊開發能力的人,容器和Kubernetes能為他們提供彎道超車的捷徑。

京東金融的運維團隊就采用了Kubernetes來搭建他們的PaaS平臺:

PasS平臺化將問題的關注點從基礎資源上升到了應用層面,目標是提供一個幫助開發人員運行、管理應用的平臺,讓使用者更關注運行的代碼(業務邏輯)。

PaaS能解決的問題:

  • 應用聚合:如開發需要一個Redis,直接啟動一個Redis容器即可
  • 服務發現、快速伸縮、狀態管理等
  • 服務監控、恢復、容災
  • 費用統計:提供計算資源信息匯總,針對不同項目收費
  • 安全管控:不管什么平臺,安全都非常重要,例如A應用可以訪問B,B不允許訪問A以及安全審計等。
  • 快速部署。

隨著Docker容器技術的出現,讓我們有了更合適的工具建設PaaS平臺,具備了基于應用構建服務的能力。在Docker容器調度框架上,我們又選擇了Kubernetes平臺。

——張龍,京東金融PE

為什么PaaS會成為云計算主流?

除了上面的這些,我們還可以看到,PaaS是SaaS服務發展到一定程度后必然會做的事情,這么做不僅可以滿足客戶更全面、定制化的需求,也讓SaaS廠商可以向更多領域拓展。如果要舉一個例子的話,大家想想微信和小程序就能理解。

而為什么Kubernetes會成為PaaS的選擇,為什么PaaS會成為云計算的主流,是因為容器和Kubernetes是今日云原生概念的核心和基礎。云計算誕生到現在有十來年了,但云時代的應用應該長什么樣子,過去一直沒有人能說清楚,直到容器誕生后,我們終于離想象中的云時代稍微近了一些。

通過了解軟件工程的這三個本質,你會發現,我們上面所說的那些分布式的技術點是高度一致的,也就是下面這三個方面的能力。

  • 分布式多層的系統架構。
  • 服務化的能力供應。
  • 自動化的運維能力。

只有做到了這些,我們才能夠真正擁有云計算的威力。這就是所謂的 Cloud Native。而這些目標都完美地體現在 PaaS 平臺上。前面講述的分布式系統關鍵技術和軟件工程的本質,都可以在 PaaS 平臺上得到完全體現。

——陳皓 《洞悉PaaS平臺的本質》

云計算的未來

過去幾年云計算的發展令人眼花繚亂,想要預測它的未來無疑是極為困難的,但只要把握住Kubernetes這條主線,理解從虛擬化到容器再到兩者融合的發展路線,在短期內我們還是能做一些預測。

這個問題(Kubernetes在五年后會變成怎樣)很好。我希望,在接下來的五年中,我們對Kubernetes的討論不比對Linux內核的討論多。它真的應該成為所有工作的基礎。如果我們接下來的行為正確,我認為,有些事情就會成真。

大多數開源和ISV(軟件供應商)的安裝指令都是始于“選擇一個經過認證的Kubernetes集群”。第2步將是“運行這個kubectl命令”。Kubernetes將讓第三方軟件不再憂慮開發針對無數平臺的版本,讓那些供應商更容易提供云提供商托管服務之外的方案。在許多情況下,使用云服務并沒什么不對,但是,你應該從你自己的基礎設施上也能獲得類似的體驗。

我相信,對于開發流程,我們將從封閉的PaaS服務,轉向企業可以使用一流組件組裝類似PaaS功能。其中,有些可能是領域專屬的,只在一個特定的行業里應用。企業能夠快速組裝一個完整的解決方案,提供從代碼到有強大防護的生產環境的簡單路徑,也提供在需要時“打破玻璃”運行自定義功能的能力。

——Craig McLuckie,Kubernetes創始人

Kubernetes已經勝利,但基于Kubernetes的各類組件、工作流并不成熟,就像Kubernetes創始人McLuckie所說的,Kubernetes需要成為討論的“背景”,我們討論的將是基于容器編排的各種創新和應用,比如Service Mesh。

在我看來,在三到五年之后, Kubernetes 會成為服務器端的標準環境, 就像現在的Linux,而 Service Mesh 就是運行在 Kubernetes 上的分布式應用的動態鏈接器,屆時開發一個分布式應用將會像開發單機程序一樣簡單,業界在分布式操作系統上長達三十多年的努力將以這種方式告一段落。

——宋瀟男,普元信息云計算架構師(Source)

 

來自:http://www.infoq.com/cn/articles/kubernetes-and-pass

 

 本文由用戶 dzpp8015 自行上傳分享,僅供網友學習交流。所有權歸原作者,若您的權利被侵害,請聯系管理員。
 轉載本站原創文章,請注明出處,并保留原始鏈接、圖片水印。
 本站是一個以用戶分享為主的開源技術平臺,歡迎各類分享!