DockOne技術分享（十九）：暢談PaaS

PaaS（平臺即服務）是云計算中的一個火熱的話題，本次分享跟大家聊聊PaaS，特別是PaaS的三個典型代表：CloudFoundry、Docker和Kubernetes，包括一些技術性和非技術性話題，希望更加全面地幫助大家了解PaaS。

PaaS的前世今生

我們所熟悉的云計算分為3個層面：IaaS（基礎架構即服務）、PaaS（平臺即服務）、SaaS（軟件即服務）。 與SaaS相比，PaaS和IaaS的概念相對較新，也是最近幾年云計算領域的集中發力點，像Amozon、微軟、谷歌、阿里云等還有很多初創公司都推出 了IaaS和PaaS產品。

下面一張圖比較經典的比較傳統IT、IaaS和PaaS：

目前市面上有很多PaaS平臺，我自己認為可以分為3個階段：

• 第一代PaaS，比如Google App Engine, SAE.這是最早期的PaaS，當時并沒有PaaS這個概念，但是他們做的事情，現在看來是包含在PaaS范圍內的。
• 第二代PaaS,比如CloudFoundry, Openshift.這是各大IaaS流行之后，順勢推出的PaaS, 并且迅速發展。
• 第三代Paas，比如Kubernetes。這是在Docker火爆之后，利用Docker的特性構建出許多PaaS，這些PaaS更加靈活，更加適應企業，逐漸成為PaaS的主力，我想也是在座各位很多人正在做的方向。
</ul>
接下來給大家說明下剛才提到的幾個典型的項目，CloudFoundry、Docker和Kubernetes，從中就可以看到幾代PaaS進化的技術驅動力。


CloudFoundry

Cloud Foundry是VMware于2011年推出的業界第一個開源PaaS云平臺，后來分拆出Pivotal公司進行接管，2014創立Cloud Foundry基金會，希望吸引更多的公司參與，而不是Pivotal一家獨大。
現在說的Cloud Foundry是V2架構，它的結構圖如下：





• Router：路由模塊，所有的數據面和管理面請求都通過Router進行分發。
• UAA/Login Server:：鑒權模塊。
• NATS：消息總線，CloudFoundry內部組件的通信主要通過NATS進行通信。
• Cloud Controller（CC）：管理中心，負責應用的生命周期管理等等。
• Health Manager：應用的健康監控狀態。
• DEA：應用的運行時節點，應用都是運行在DEA上。
• Warden：容器管理模塊，類似Docker，提供給應用容器運行環境。
• Service Brokers：用于適配對接各類的第三方服務，可以是各種關系數據庫、中間件、緩存、云存儲、內存數據庫等各種服務。
• Metrics Collector/App Log Aggregator：平臺應用的日志和監控數據收集。
</ul>
CloudFoundry推出以后逐漸得到了各大廠商的支持， 華為云、IBM BlueMix、 HP Cloud和Dell云服務都采用了CloudFoundry作為基礎，一時間成為PaaS的代表。那么CloudFoudry的優勢有哪些呢？


• 開源、開發的架構 開源是趨勢，CloudFoundry順應了趨勢，自然可以吸引大批的開發者和公司參與其中。同時CloudFoundry是一個開發的架構，定義了一套標準，可以擴展多種框架、語言、運行時環境及應用服務，支持運行在云平臺IaaS上。
• 運維智能化 運維能力是PaaS最最最最最重要的能力，這絕定了PaaS的成功與否，如果PaaS無法提供強大的運維支持，為什么我要把應用托管在PaaS，我需要看 日志和監控，我需要經常升級應用等等，IaaS可是提供了相當靈活的處理機制。CloudFoudry在這方面做出了很多努力，提供應用的容錯容災，彈性 伸縮，負載均衡，安全控制，監控日志的收集匯總等等。
• 容器 這里不得不提容器技術，容器的快速，隔離的特性是非常適合PaaS的需求的，CloudFoundry中開發了Warden組件來實現容器管理，實際上 Warden和Docker類似，只不過CloudFoundry當時并沒有專注于容器這一塊，Warden在易用性和設計上都不如Docker，自然被 Docker搶了風頭。
</ul>
CloudFoundry最大的問題是它只能支持簡單的Web類應用：應用只能暴露一個HTTP端口，應用之間通信也只能通過HTTP等等，這是 因為CloudFoundry一開始的設計模型是比較簡單的，很多復雜場景應該是沒考慮的，目前V3架構Diego正在開發中，應該有這方面的考慮。

總之CloudFoundry最為第二代PaaS的代表，它在運作，架構和技術上相比第一代PaaS都有一定的提高，在云計算大潮中引領了 PaaS的發展，但是PaaS一直處在一個不溫不火的尷尬程度，使用PaaS絕大多數是開發者個人的玩票性質，真正使用的企業用戶其實很少。接下來 Docker登場。


Docker

Docker 是 PaaS 提供商 dotCloud 開源的高級容器引擎，Docker自2013年以來非常火熱，2014年就已經火得沒有朋友了。



這篇文章 講Docker的由來的，蠻有趣的，有點無心插柳柳成蔭的意思。

關于Docker的好處，現在有許多文章都會說明，這里我講講個人的理解：

像很多文章提到的Docker快速敏捷（啟動，停止都是以秒或毫秒為單位的），隔離輕量級（不添加額外的操作系統），這些實際上是Linux內核 提供的能力，Docker是沿用了這些特性，像CloudFoundry的Warden也有這些能力，Docker最大的創新點在于Docker Image的設計，下面是張Docker Image的層次圖，分層的文件系統，一層層地搭建出一個完整的容器運行環境：



這樣一來，我們可以像樂高玩具一樣搭建各式各樣的鏡像，同時Docker提供了一整套鏡像存儲方案（Docker Registry），可以非常方便地獲取想要的鏡像，然后快速地啟動運行，而不必像以前那樣安裝各種麻煩的依賴軟件。

Docker更像個微創新者，但是解決了最大痛點，像Warden只解決了應用運行的問題，而Docker解決了應用的發布，構建和運行，創建了 很多想象空間，所以基于Docker衍生出了很多新的解決方案，特別是PaaS，即第三代的PaaS， Kubernetes是其中最具代表性的一員，最后講一下Kubernetes。


Kubernetes

Kubernetes是Google開源的容器集群管理系統。它構建Ddocker技術之上，為容器化的應用提供資源調度、部署運行、服務發現、擴容縮容等整一套功能，本質上可看作是基于容器技術的micro-PaaS平臺。



關于Kubernetes的技術分析可以參考我的 系列文章，這里不做展開。

因為Docker解決了應用編譯構建的問題，所以Kubernetes架構上就可以專注在容器編排，服務發現等等運維相關特性上，像CloudFoundry就是花了很大精力在應用編譯構建上，集成了BuildPack，各種文件傳輸，效果其實不是特別好。

PaaS的價值不是在幫你編譯打包上，而是在于節省運維成本。

Kubernetes的設計模型我認為有幾個好的地方：


1. Label的設計： Pod、Service、Replication Controller之間的是通過Label進行關聯，這是一種輕綁定的方式，可以方便地組合業務，做灰度升級等等。
2. 網 絡模型: Kubernetes采用扁平化的網絡模型，每個Pod都有一個全局唯一的IP（IP-per-pod），Pod之間可以跨主機通信，相比于Docker 原生的NAT方式來說，這樣使得容器在網絡層面更像虛擬機或者物理機，復雜度整體降低，更加容易實現服務發現，遷移，負載均衡等功能。
</ol>


Q&A

問：開源勢必引入安全問題。Cloud Foundry的安全保護機制？
答：Cloud Foundry對于應用有個安全組的特性，可以控制應用容器的訪問。但是實際上能力不強，容器安全這塊一直是被擔心的地方。

問：Cloud Foundry的DEA,即應用的運行時節點，是虛擬的操作系統么？Warden對底層的操作系統有和要求？Warden如何實現的隔離性？
答：DEA是個服務，其實還是linux系統 Warden對內核有要求，實現原理和Docker類似。

問：va/spring/web 應用很容易在Docker/Kubernetes環境運行，如果要遷移到CF，工作量大嗎？
答：CF V2工作量應該挺大，V3的話因為支持Docker，所以還好。

問：關于k8s中Flannel和Weave兩者哪個更適合生產環境？
答：這個我最近正在分析，感覺flannel和weave都還不成熟，推薦ovs。

問：Docker既然是namespace隔離的，就算不安全應該也影響不是很大吧？
答：其實如果你清楚原理，很容易進入到容器環境中的，沒辦法，安全是個大問題。

問：k8s可以實現應用的自主遷移嗎？
答：目前沒有Pod遷移的API。

問：CloudFoundary中監控部分有插件機制么？
答：支持導入到各種第三方監控系統。

問：Pod直接通信需要開通隧道么？換句話說他們之間是如何實現通信的？
答：容器跨主機的通信，是對Docker的增強，像Flannel、ovs等。

問：PaaS的三個典型代表：CloudFoundry、Docker和Kubernetes，最近的DaoCloud、靈雀 云、時速云等以Docker為核心提出了新的CaaS概念。CaaS和PaaS都使用了Docker，Kubernetes等技術，您是怎么理解PaaS 和CaaS的？
答：CaaS容器即服務，我的理解就是PaaS，只不過主打這Docker容器，所以叫CaaS。

問：Docker在CentOS上使用devicemapper，據說容易使系統crash，對于其他的文件系統有沒有推薦，brtfs和aufs哪個更好？
答：aufs是內核不接受的，聽說是因為代碼太亂。

問：對于管理Docker這件事情，除了Kubernetes, openstack（IaaS陣營）, YARN（Hadoop陣營）也開始發力，怎么看待這幾者間的競爭？
答：沒有任何技術是銀彈，不同需求不同設計。當然大家都想占據制高點了，這就是運作了。

問：k8s現在具備auto scaling能力嗎，比如應用響應時間變長，k8s可以自動擴容？
答：沒有。

問：如果將Flannel替換成ovs是不是也可以替換掉kube-proxy，如果是那會不會影響集群中SVC的使用？
答：flannel/ovs和kube-proxy的作用是不一樣的，可以看下 http://dockone.io/article/545。

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
以上內容根據2015年9月1日晚微信群分享內容整理。分享人 吳龍輝，現任網宿科技高級運營工程師，致力于云計算PaaS的研究和實踐，活躍于CloudFoundry、Docker、Kubernetes等開源社區，貢獻代碼和撰寫技術文檔。郵箱：wulh@chinanetcenter.com/wlh6666@qq.com。DockOne每周都會組織定向的技術分享，歡迎感興趣的同學加微信：liyingjiesx，進群參與，您有想聽的話題可以給我們留言。

來自：http://dockone.io/article/635