PaaS的前世今生
我們所熟悉的云計算分為3個層面：IaaS(基礎架構即服務)、PaaS(平臺即服務)、SaaS(軟件即服務)。與SaaS相比，PaaS和IaaS的概念相對較新，也是最近幾年云計算領域的集中發力點，像Amazon、微軟、谷歌、阿里云等還有很多初創公司都推出了IaaS和PaaS產品。
下面一張圖比較經典的比較傳統IT、IaaS和PaaS：
目前市面上有很多PaaS平臺，我自己認為可以分為3個階段：
第一代PaaS，比如Google App Engine、SAE，這是最早期的PaaS，當時并沒有PaaS這個概念，但是他們做的事情，現在看來是包含在PaaS范圍內的。
第二代PaaS，比如 Cloud Foundry、OpenShift。這是各大IaaS流行之后，順勢推出的PaaS， 并且迅速發展。
第三代PaaS，比如Kubernetes。這是在Docker火爆之后，利用Docker的特性構建出許多PaaS，這些PaaS更加靈活，更加適應企業，逐漸成為PaaS的主力，我想也是很多人正在做的方向。
接下來給大家說明下剛才提到的幾個典型的項目， Cloud Foundry、Docker和Kubernetes，從中就可以看到幾代PaaS進化的技術驅動力。
Cloud Foundry
Cloud Foundry是VMware于2011年推出的業界第一個開源PaaS云平臺，后來分拆出Pivotal公司進行接管，2014創立Cloud Foundry基金會，希望吸引更多的公司參與，而不是Pivotal一家獨大。
現在說的Cloud Foundry是V2架構，它的結構圖如下：
Router：路由模塊，所有的數據面和管理面請求都通過Router進行分發。
UAA/Login Server：鑒權模塊。
NATS：消息總線， Cloud Foundry內部組件的通信主要通過NATS進行通信。
Cloud Controller(CC)：管理中心，負責應用的生命周期管理等等。
Health Manager：應用的健康監控狀態。
DEA：應用的運行時節點，應用都是運行在DEA上。
Warden：容器管理模塊，類似Docker，提供給應用容器運行環境。
Service Brokers：用于適配對接各類的第三方服務，可以是各種關系數據庫、中間件、緩存、云存儲、內存數據庫等各種服務。
Metrics Collector/App Log Aggregator：平臺應用的日志和監控數據收集。
Cloud Foundry推出以后逐漸得到了各大廠商的支持， 華為云、IBM BlueMix、 HP Cloud和Dell云服務都采用了 Cloud Foundry作為基礎，一時間成為PaaS的代表。那么 Cloud Foundry的優勢有哪些呢?
開源、開發的架構。 開源是趨勢， Cloud Foundry順應了趨勢，自然可以吸引大批的開發者和公司參與其中。同時 Cloud Foundry是一個開發的架構，定義了一套標準，可以擴展多種框架、語言、運行時環境及應用服務，支持運行在云平臺IaaS上。
運維智能化。 運維能力是PaaS最最最最最重要的能力，這決定了PaaS的成功與否，如果PaaS無法提供強大的運維支持，為什么我要把應用托管在PaaS，我需要看日志和監控，我需要經常升級應用等等，IaaS可是提供了相當靈活的處理機制。 Cloud Foundry在這方面做出了很多努力，提供應用的容錯容災、彈性伸縮、負載均衡、安全控制、監控日志的收集匯總等等。
容器。 這里不得不提容器技術，容器輕量、隔離的特性是非常適合PaaS的需求的， Cloud Foundry中開發了Warden組件來實現容器管理，實際上Warden和Docker類似，只不過 Cloud Foundry當時并沒有專注于容器這一塊，Warden在易用性和設計上都不如Docker，自然被Docker搶了風頭。
Cloud Foundry最大的問題是它只能支持簡單的Web類應用：應用只能暴露一個HTTP端口，應用之間通信也只能通過HTTP等等，這是因為 Cloud Foundry一開始的設計模型是比較簡單的，很多復雜場景應該是沒考慮的，目前V3架構Diego正在開發中，應該有這方面的考慮。
總之Cloud Foundry最為第二代PaaS的代表，它在運作、架構和技術上相比第一代PaaS都有一定的提高，在云計算大潮中引領了PaaS的發展，但是PaaS 一直處在一個不溫不火的尷尬程度，使用PaaS絕大多數是開發者個人的玩票性質，真正使用的企業用戶其實很少。接下來Docker登場。
Docker
Docker是PaaS提供商dotCloud開源的高級容器引擎，Docker自2013年以來非常火熱，2014年就已經火得沒有朋友了。
這篇文章講Docker的由來的，蠻有趣的，有點無心插柳柳成蔭的意思。
關于Docker的好處，現在有許多文章都會說明，這里我講講個人的理解：
像很多文章提到的Docker快速敏捷(啟動、停止都是以秒或毫秒為單位的)，隔離輕量級(不添加額外的操作系統)，這些實際上是Linux內核提供的能力，Docker是沿用了這些特性，像Cloud Foundry的Warden也有這些能力，Docker最大的創新點在于Docker鏡像的設計，下面是張Docker鏡像的層次圖，分層的文件系統，一層層地搭建出一個完整的容器運行環境：
這樣一來，我們可以像樂高玩具一樣搭建各式各樣的鏡像，同時Docker提供了一整套鏡像存儲方案(Docker Registry)，可以非常方便地獲取想要的鏡像，然后快速地啟動運行，而不必像以前那樣安裝各種麻煩的依賴軟件。
Docker 更像個微創新者，但是解決了最大痛點，像Warden只解決了應用運行的問題，而Docker解決了應用的發布、構建和運行，創建了很多想象空間，所以基于Docker衍生出了很多新的解決方案，特別是PaaS，即第三代的PaaS，Kubernetes是其中最具代表性的一員，最后講一下 Kubernetes。
Kubernetes
Kubernetes是Google開源的容器集群管理系統。它構建Docker技術之上，為容器化的應用提供資源調度、部署運行、服務發現、擴容縮容等整一套功能，本質上可看作是基于容器技術的micro-PaaS平臺。
因為Docker解決了應用編譯構建的問題，所以Kubernetes架構上就可以專注在容器編排，服務發現等等運維相關特性上，像Cloud Foundry就是花了很大精力在應用編譯構建上，集成了BuildPack，各種文件傳輸，效果其實不是特別好。
PaaS的價值不是在幫你編譯打包上，而是在于節省運維成本。
Kubernetes的設計模型我認為有幾個好的地方：
Label的設計： Pod、Service、Replication Controller之間的是通過Label進行關聯，這是一種輕綁定的方式，可以方便地組合業務，做灰度升級等等。
網絡模型: Kubernetes采用扁平化的網絡模型，每個Pod都有一個全局唯一的IP(IP-per-pod)，Pod之間可以跨主機通信，相比于Docker 原生的NAT方式來說，這樣使得容器在網絡層面更像虛擬機或者物理機，復雜度整體降低，更加容易實現服務發現、遷移、負載均衡等功能。
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的三個典型代表： Cloud Foundry、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。
京公網安備 11010502049343號