|
新聞中心
當(dāng)前位置：網(wǎng)站首頁 > 新聞中心
PaaS將吞噬云計(jì)算？看國(guó)內(nèi)外專家怎么說
2017年是Kubernetes的勝利之年，很多人還不明白這意味著什么。但如果看一下云計(jì)算業(yè)界的動(dòng)向，你會(huì)發(fā)現(xiàn)，Kubernetes的影響正在擴(kuò)散。
在本文中我將分享我們的發(fā)現(xiàn)，并試圖說服你：基于容器+Kubernetes的新型PaaS將會(huì)成為云計(jì)算的主流。
我將引用很多內(nèi)容，包含國(guó)內(nèi)外專家的真知灼見，讓你看到專家是如何看待此事的，以及分享我們自己做的調(diào)研和采訪，看看業(yè)界實(shí)際在發(fā)生什么。
Kubernetes(k8s)在很短的一段時(shí)間內(nèi)走過了很長(zhǎng)的一段路。僅僅兩年以前，它還需要與CoreOS的Fleet、Docker Swarm、Cloud Foundry Diego、HashiCorp的Nomad、Kontena、Rancher的Cattle、Apache Mesos、Amazon ECS等進(jìn)行競(jìng)爭(zhēng)，來證明自己比那些產(chǎn)品都要優(yōu)秀。而現(xiàn)如今已經(jīng)是完全不同的一幅景象了。其中的一些公司公開宣布了項(xiàng)目的終止并且開始加入到Kubernetes陣營(yíng)中，還有一些公司沒有公開宣布自己項(xiàng)目的失敗，而是在戰(zhàn)略上宣布了對(duì)Kubernetes的部分支持或者完全整合，這也就意味著他們的容器編排工具將會(huì)安靜而緩慢地死掉。不論是哪一種情況，k8s都是最后一個(gè)活下來的平臺(tái)。除此之外，不僅僅是用戶和白金贊助商們，越來越多的大公司都將繼續(xù)加入到Kubernetes的生態(tài)系統(tǒng)中，將自己的業(yè)務(wù)完全押注于Kubernetes的成功。我們首先能想到的有Google的Kubernetes Engine、Red Hat的OpenShift、Microsoft的Azure Container Service、IBM的 Cloud Container Service、Oracle的Container Engine。
但是這些意味著什么呢?首先，這意味著開發(fā)人員必須要掌握一個(gè)與90%的容器工作相關(guān)的容器編排平臺(tái)。這是一個(gè)學(xué)習(xí)Kubernetes很好的理由。同時(shí)這還意味著我們已經(jīng)深深地依賴于Kubernetes，Kubernetes就像容器領(lǐng)域中的Amazon。在Kubernetes上進(jìn)行設(shè)計(jì)、實(shí)現(xiàn)和運(yùn)行應(yīng)用程序可以讓你在不同的云提供商、Kubernetes發(fā)行版和服務(wù)提供商之間自由地對(duì)應(yīng)用程序進(jìn)行遷移。它能讓你有機(jī)會(huì)找到Kubernetes認(rèn)證的開發(fā)人員，讓他們來開發(fā)項(xiàng)目并且在以后持續(xù)提供支持。Kubernetes不是VM，也不是JVM，它是全新的應(yīng)用程序可移植層，它是大家共同的選擇。
——Bilgin Ibryam，Red Hat首席架構(gòu)師(Source)基于“容器+k8s”的新型PaaS
Kubernetes并不是傳統(tǒng)意義上的PaaS，事實(shí)上，傳統(tǒng)PaaS可以基于Kubernetes構(gòu)建。
在過去，PaaS經(jīng)歷了這樣的發(fā)展：
第一代：如最早的Heroku，嚴(yán)格限定的運(yùn)行時(shí)，不可修改的環(huán)境。對(duì)于Ruby on Rails這種小型單體應(yīng)用來說很合適。
第二代：Cloud Foundry (DEA版本) ，可以簡(jiǎn)單的自定義環(huán)境，包括云端構(gòu)建。也開始對(duì)多服務(wù)的應(yīng)用有所支持。
第三代：Cloud Foundry (Diego版本)，如當(dāng)前版本的GAE和AWS Elastic Beanstalk，它們都經(jīng)過之前兩代PaaS迭代而來。在這個(gè)版本里增加了對(duì)容器的支持，更自由的環(huán)境配置，對(duì)微服務(wù)的支持更強(qiáng)大。
第四代：Kubernetes以及其它容器編排引擎。這一代的平臺(tái)變成了Kubernetes本身，它是面向云原生應(yīng)用計(jì)算的、徹底基于分布式和容器的計(jì)算平臺(tái)。
第四代PaaS的關(guān)注點(diǎn)也和之前不一樣，我們可以把前三代PaaS稱為應(yīng)用級(jí)PaaS(Application PaaS)，它們關(guān)注的是應(yīng)用的運(yùn)行，第四代稱為容器PaaS，或者CaaS、KaaS，它們關(guān)注的是應(yīng)用的打包和分發(fā)。
第四代PaaS當(dāng)然也可以使用其它的技術(shù)達(dá)到類似的效果，但就像前面所說的，Kubernetes贏得了這場(chǎng)競(jìng)爭(zhēng)。
從下面的PaaS平臺(tái)架構(gòu)圖中可以看到，我用了 Docker+Kubernetes 層來做了一個(gè)“技術(shù)緩沖層”。也就是說，如果沒有 Docker 和 Kubernetes，構(gòu)建 PaaS 將會(huì)復(fù)雜很多。當(dāng)然，如果你正在開發(fā)一個(gè)類似 PaaS 的平臺(tái)，那么你會(huì)發(fā)現(xiàn)自己開發(fā)出來的東西會(huì)跟 Docker 和 Kubernetes 非常像。相信我，最終你還是會(huì)放棄自己的輪子而采用 Docker+Kubernetes 的。
——陳皓 《洞悉PaaS平臺(tái)的本質(zhì)》這是一個(gè)大而全的PaaS平臺(tái)架構(gòu)，實(shí)際中可以根據(jù)需求進(jìn)行裁剪。業(yè)界趨勢(shì)：全在做PaaS
如果我們看一下業(yè)界，會(huì)發(fā)現(xiàn)，從公有云到私有云，從傳統(tǒng)企業(yè)到互聯(lián)網(wǎng)新貴，都在擁抱Kubernetes，都在做PaaS。公有云全在做k8s和容器
從AWS到Google Cloud、微軟Azure，到國(guó)內(nèi)的阿里云、騰訊云、華為云等，都在提供k8s容器服務(wù)。如果一個(gè)公有云到現(xiàn)在還沒有提供k8s服務(wù)，或者沒有計(jì)劃做，那么可以認(rèn)為它的技術(shù)已經(jīng)落后于時(shí)代了。
公有云提供的k8s和容器服務(wù)，具體來說分為兩類：
一類是提供多租戶的單容器實(shí)例，這種其實(shí)類似于上面提到的第三類PaaS，用戶創(chuàng)建的是單個(gè)容器，值得一提的是，這類PaaS仍可構(gòu)建于k8s之上，并且不少云計(jì)算廠商已經(jīng)采用這種方案。另外，由KataContainer技術(shù)逐漸應(yīng)用到生產(chǎn)環(huán)境，帶來將無服務(wù)器概念和容器結(jié)合的Serverless Container Cloud理念，讓容器也能兼具傳統(tǒng)虛擬化的優(yōu)點(diǎn)，讓這類服務(wù)的未來充滿了想象空間。
Kubernetes所要扮演的角色，乃是取代傳統(tǒng)的Infrastructure Layer并鼓勵(lì)技術(shù)人員進(jìn)行上層的“二次創(chuàng)新”，而并不是直接面對(duì)最終用戶。真正為最終用戶提供云服務(wù)的，很大概率應(yīng)該是構(gòu)建于Kubernetes之上的、更加簡(jiǎn)潔高效的服務(wù)型API，而Serverless，尤其是Serverless Container Cloud的設(shè)計(jì)，正是這種需求下最為貼切的實(shí)現(xiàn)方式之一。
——張磊，浙江大學(xué)博士研究員，Hyper項(xiàng)目成員，Kubernetes項(xiàng)目資深成員與社區(qū)維護(hù)者。
另一類是提供Kubernetes引擎，這種情況下用戶創(chuàng)建的是Kubernetes集群，如GKE、Azure AKS、騰訊云CCS等。
第二類服務(wù)是目前公有云研發(fā)的重點(diǎn)，發(fā)布的時(shí)間基本集中在去年下半年到現(xiàn)在，我們采訪和調(diào)研了微軟Azure、騰訊云、華為云，情況基本類似，具體內(nèi)容可進(jìn)一步閱讀：
劍指Kubernetes 揭秘騰訊云的PaaS技術(shù)選型策略
華為云的Kubernetes實(shí)踐之路k8s將成私有云的標(biāo)準(zhǔn)解法
私有云的情況分為兩類，一類是企業(yè)搭建數(shù)據(jù)中心和私有云自用，另一類是服務(wù)提供商，為客戶提供私有云解決方案。在這兩類情況中我們都看到Kubernetes被使用的越來越多，并且無論是企業(yè)、服務(wù)提供商，還是客戶都嘗到了Kubernetes PaaS的甜頭。
對(duì)于自用型私有云來說，系統(tǒng)的演進(jìn)是一個(gè)復(fù)雜的問題，盲目采用新技術(shù)有時(shí)不僅無助于業(yè)務(wù)，還造成資源浪費(fèi)。k8s的表現(xiàn)如何呢?我們讓京東的經(jīng)驗(yàn)來說話吧：
(采用容器和Kubernetes的)JDOS 2.0接入了包含大數(shù)據(jù)、Web利用、深度學(xué)習(xí)等多種類型的利用，并為每一種利用依據(jù)類型采取了不同的資源限制方式，并打上了Kubernetes的不同標(biāo)簽?；诙鄻拥臉?biāo)簽，我們實(shí)現(xiàn)了更加多樣和靈便的調(diào)度方式，并在部份IDC試驗(yàn)性地混合部署了在線任務(wù)和離線任務(wù)。相較于1.0，總體資源應(yīng)用率提升了約30%。
——鮑永成，京東基礎(chǔ)平臺(tái)部技術(shù)總監(jiān)
對(duì)于服務(wù)提供商來說，Kubernetes健康的生態(tài)可以保證它們有大量的第三方軟件和工具使用，同時(shí)PaaS易于開發(fā)和代碼/應(yīng)用復(fù)用的特性，也降低了它們交付項(xiàng)目的成本，并縮短了交付周期。
對(duì)于客戶來說，基于Kubernetes的PaaS可以實(shí)現(xiàn)應(yīng)用自由遷移，這使企業(yè)可以采用多重云策略，并變相提升了對(duì)供應(yīng)商的議價(jià)能力。
云計(jì)算經(jīng)過了十多年的發(fā)展，已然進(jìn)入的云原生的新階段，企業(yè)應(yīng)用優(yōu)先考慮部署在云環(huán)境，如何順應(yīng)云原生的大潮，使用容器和Kubernetes構(gòu)建云原生平臺(tái)，踐行DevOps理念和敏捷IT，開源軟件和社區(qū)如何助力IT轉(zhuǎn)型，所有這些問題的解決方案就是PaaS平臺(tái)，其對(duì)于企業(yè)的重要性不言而喻。
——宋凈超 TalkingData容器平臺(tái)負(fù)責(zé)人(Source)
一些業(yè)界的經(jīng)驗(yàn)可參考：
京東如何從OpenStack遷移至Kubernetes
你知道嗎?傳統(tǒng)企業(yè)已經(jīng)在用最新互聯(lián)網(wǎng)架構(gòu)了運(yùn)維也需要PaaS
騰訊互娛的運(yùn)維團(tuán)隊(duì)，需要為公司的在線游戲提供運(yùn)維能力，這可能是中國(guó)挑戰(zhàn)最大要求最高的運(yùn)維服務(wù)，因此他們有數(shù)百人的研發(fā)團(tuán)隊(duì)，他們的做法可以很大程度上代表運(yùn)維的發(fā)展方向，而不斷思考和迭代的結(jié)果就是自研了一套PaaS平臺(tái)藍(lán)鯨。藍(lán)鯨本身不使用Docker、Kubernetes等，完全自研，但我們可以看到，運(yùn)維的發(fā)展方向就是PaaS。PaaS本身與DevOps的理念完全契合，它改變了傳統(tǒng)運(yùn)維的職責(zé)，讓他們變成運(yùn)維開發(fā)，為企業(yè)研發(fā)運(yùn)維工具乃至是PaaS平臺(tái)。而對(duì)于沒有藍(lán)鯨團(tuán)隊(duì)開發(fā)能力的人，容器和Kubernetes能為他們提供彎道超車的捷徑。
京東金融的運(yùn)維團(tuán)隊(duì)就采用了Kubernetes來搭建他們的PaaS平臺(tái)：
PasS平臺(tái)化將問題的關(guān)注點(diǎn)從基礎(chǔ)資源上升到了應(yīng)用層面，目標(biāo)是提供一個(gè)幫助開發(fā)人員運(yùn)行、管理應(yīng)用的平臺(tái)，讓使用者更關(guān)注運(yùn)行的代碼(業(yè)務(wù)邏輯)。
PaaS能解決的問題：
應(yīng)用聚合：如開發(fā)需要一個(gè)Redis，直接啟動(dòng)一個(gè)Redis容器即可
服務(wù)發(fā)現(xiàn)、快速伸縮、狀態(tài)管理等
服務(wù)監(jiān)控、恢復(fù)、容災(zāi)
費(fèi)用統(tǒng)計(jì)：提供計(jì)算資源信息匯總，針對(duì)不同項(xiàng)目收費(fèi)
安全管控：不管什么平臺(tái)，安全都非常重要，例如A應(yīng)用可以訪問B，B不允許訪問A以及安全審計(jì)等。
快速部署。
隨著Docker容器技術(shù)的出現(xiàn)，讓我們有了更合適的工具建設(shè)PaaS平臺(tái)，具備了基于應(yīng)用構(gòu)建服務(wù)的能力。在Docker容器調(diào)度框架上，我們又選擇了Kubernetes平臺(tái)。
——張龍，京東金融PE為什么PaaS會(huì)成為云計(jì)算主流?
除了上面的這些，我們還可以看到，PaaS是SaaS服務(wù)發(fā)展到一定程度后必然會(huì)做的事情，這么做不僅可以滿足客戶更全面、定制化的需求，也讓SaaS廠商可以向更多領(lǐng)域拓展。如果要舉一個(gè)例子的話，大家想想微信和小程序就能理解。
而為什么Kubernetes會(huì)成為PaaS的選擇，為什么PaaS會(huì)成為云計(jì)算的主流，是因?yàn)槿萜骱蚄ubernetes是今日云原生概念的核心和基礎(chǔ)。云計(jì)算誕生到現(xiàn)在有十來年了，但云時(shí)代的應(yīng)用應(yīng)該長(zhǎng)什么樣子，過去一直沒有人能說清楚，直到容器誕生后，我們終于離想象中的云時(shí)代稍微近了一些。
通過了解軟件工程的這三個(gè)本質(zhì)，你會(huì)發(fā)現(xiàn)，我們上面所說的那些分布式的技術(shù)點(diǎn)是高度一致的，也就是下面這三個(gè)方面的能力。
分布式多層的系統(tǒng)架構(gòu)。
服務(wù)化的能力供應(yīng)。
自動(dòng)化的運(yùn)維能力。
只有做到了這些，我們才能夠真正擁有云計(jì)算的威力。這就是所謂的 Cloud Native。而這些目標(biāo)都完美地體現(xiàn)在 PaaS 平臺(tái)上。前面講述的分布式系統(tǒng)關(guān)鍵技術(shù)和軟件工程的本質(zhì)，都可以在 PaaS 平臺(tái)上得到完全體現(xiàn)。
——陳皓 《洞悉PaaS平臺(tái)的本質(zhì)》云計(jì)算的未來
過去幾年云計(jì)算的發(fā)展令人眼花繚亂，想要預(yù)測(cè)它的未來無疑是極為困難的，但只要把握住Kubernetes這條主線，理解從虛擬化到容器再到兩者融合的發(fā)展路線，在短期內(nèi)我們還是能做一些預(yù)測(cè)。
這個(gè)問題(Kubernetes在五年后會(huì)變成怎樣)很好。我希望，在接下來的五年中，我們對(duì)Kubernetes的討論不比對(duì)Linux內(nèi)核的討論多。它真的應(yīng)該成為所有工作的基礎(chǔ)。如果我們接下來的行為正確，我認(rèn)為，有些事情就會(huì)成真。
大多數(shù)開源和ISV(軟件供應(yīng)商)的安裝指令都是始于“選擇一個(gè)經(jīng)過認(rèn)證的Kubernetes集群”。第2步將是“運(yùn)行這個(gè)kubectl命令”。Kubernetes將讓第三方軟件不再憂慮開發(fā)針對(duì)無數(shù)平臺(tái)的版本，讓那些供應(yīng)商更容易提供云提供商托管服務(wù)之外的方案。在許多情況下，使用云服務(wù)并沒什么不對(duì)，但是，你應(yīng)該從你自己的基礎(chǔ)設(shè)施上也能獲得類似的體驗(yàn)。
我相信，對(duì)于開發(fā)流程，我們將從封閉的PaaS服務(wù)，轉(zhuǎn)向企業(yè)可以使用一流組件組裝類似PaaS功能。其中，有些可能是領(lǐng)域?qū)俚?，只在一個(gè)特定的行業(yè)里應(yīng)用。企業(yè)能夠快速組裝一個(gè)完整的解決方案，提供從代碼到有強(qiáng)大防護(hù)的生產(chǎn)環(huán)境的簡(jiǎn)單路徑，也提供在需要時(shí)“打破玻璃”運(yùn)行自定義功能的能力。
——Craig McLuckie，Kubernetes創(chuàng)始人
Kubernetes已經(jīng)勝利，但基于Kubernetes的各類組件、工作流并不成熟，就像Kubernetes創(chuàng)始人McLuckie所說的，Kubernetes需要成為討論的“背景”，我們討論的將是基于容器編排的各種創(chuàng)新和應(yīng)用，比如Service Mesh。
在我看來，在三到五年之后， Kubernetes 會(huì)成為服務(wù)器端的標(biāo)準(zhǔn)環(huán)境， 就像現(xiàn)在的Linux，而 Service Mesh 就是運(yùn)行在 Kubernetes 上的分布式應(yīng)用的動(dòng)態(tài)鏈接器，屆時(shí)開發(fā)一個(gè)分布式應(yīng)用將會(huì)像開發(fā)單機(jī)程序一樣簡(jiǎn)單，業(yè)界在分布式操作系統(tǒng)上長(zhǎng)達(dá)三十多年的努力將以這種方式告一段落。
——宋瀟男，普元信息云計(jì)算架構(gòu)師(Source)
|
