歡迎光臨
每天分享高質量文章

Cloud Foundry和Kubernetes結合的過去與未來

過去的幾年中,在雲計算領域的開源社區中最有爭議的話題莫過於Cloud Foundry和Kubernetes的關係。大家的疑問緊緊圍繞著三個問題:“它們會互相取代對方嗎?”,“它們是互斥的嗎?” ,“還是說它們是可以融合的?”。放眼望去在目前的商業產品中,兩者幾乎沒什麼關聯和集成,都可以運行在各種IaaS之上。
多年以來,我們一直從事Cloud Foundry部署的相關工作,從原來傳統的BOSH CPI到現在的容器化Cloud Foundry的工作。在這期間,我們對兩者結合的多種技術選型的進行探索,包括可行性分析、最佳實踐、經驗總結和價值意義等方面,旨在最大程度上利用和發揮兩者的優勢,並提升開發者體驗。
本文將從Cloud Foundry部署的層面,來介紹業界和我們如何去把兩套系統進行整合的。當然任何整合方案都會有各自的優缺點,而且所有的整合還在一個快速發展的階段,所以在這裡算是給大家拋磚引玉,為以後的工作和學習提供一些幫助。

 

Cloud Foundry和Kubernetes簡介

Cloud Foundry
Cloud Foundry是一個獨立於雲的平臺即服務解決方案,也是業界最成功的PaaS平臺。Cloud Foundry提供了一個可輕鬆運行、擴展和維護應用程式的環境和快速便捷的開發者體驗。Cloud Foundry支持Java、NodeJS、Ruby、Python等大多數語言和環境。
開源的Cloud Foundry由Cloud Foundry基金會開發並支持,基金會包括Pivotal、IBM、VMware以及其它許多廠商。商業版本的Cloud Foundry,如IBM Bluemix和Pivotal Cloud Foundry,是基於開源的Cloud Foundry專案併在其基礎上提供企業級的支持。
Kubernetes
Kubernetes是一個來源於谷歌Borg專案的開源雲平臺。它由Cloud Native Computing Foundation發起,該基金會的成員包括了許多行業巨頭,如AWS、Azure、Intel、IBM、RedHat、Pivotal等許多公司。
Kubernetes首要的功能是一個容器編排和容器生命周期的管理。儘管不限於此,但它通常是被用來運行Docker容器,它的受眾人群更廣泛一些,比如想要構建在容器服務之上的應用和服務開發人員。有一些解決方案基於Kubernetes提供了PaaS體驗,比如IBM的Container Service和RedHat的OpenShift等。
兩個平臺的比較
兩個平臺都很成熟和完整,而且隨著不斷的開發和改進,所以兩個平臺的相同和不同之處也會隨之變。當然兩大專案有很多相似之處,包括容器化,命名空間和身份驗證等機制。而兩者也有各自的優勢:
Cloud Foundry的優勢在於:
  1. 成熟的身份驗證系統UAA,用戶組和multi-tenancy的支持

  2. 方便快捷的cf push

  3. 自帶負載均衡Router

  4. 強大的日誌和metrics整合

  5. 成熟的部署工具BOSH

Kubernetes的優勢在於:
  1. 大量社區和第三方支持,提供強大的擴展性

  2. 完善的容器生命周期和自動伸縮管理

  3. 方便快捷的容器化應用部署

  4. 良好、多樣的持久層支持

  5. 多種開源UI支持


現階段兩者的關係及結合情況

從上面的比較,我們可以看到,兩大平臺各有各的優勢及強大之處。業界有很多廠商都想嘗試將兩者融合,從而將優勢發揮到最大化。從現在來看兩者整合主要有以下三種方式:
Kubernetes CPI
我們知道BOSH是Cloud Foundry官方指定的部署工具,它是一個針對大規模分佈式系統的部署和生命周期管理的開源工具。但是BOSH不僅僅局限於部署Cloud Foundry,也可以應用於別的分佈式系統,只需要其提供符合要求的Release即可。CPI全稱Cloud Provider Interface,是BOSH用來與IaaS通信完成虛擬機實體和模板的創建和管理的一個API接口,CPI目前能夠支持Amazon的AWS、微軟的Azure、IBM的SoftLayer等IaaS平臺,國內阿裡雲也提供了CPI的支持。BOSH的主控制器Director通過CPI與底層的IaaS層交互,將BOSH manifest.yaml 檔案定義任務及組件部署到IaaS層的VM上,如下圖所示:

所以,第一種整合,也就是開發一套Kubernetes的CPI,通過BOSH和manifest.yaml的配置將Cloud Foundry部署到Kubernetes上。現在有一些大的廠商如IBM、SAP在開發相應的Kubernetes CPI,大家可以在GitHub中搜索到。我個人覺得,這種方式雖然容易上手,但還是以IaaS的角度來看待Kubernetes,底層還是通過BOSH來管理的,沒能最大地發揮Kubernetes平臺的優勢的。
Cloud Foundry Container Runtime(CFCR)
Cloud Foundry基金會在2017年底宣佈把Pivotal和谷歌捐獻的Kubo專案改名為CFCR(Cloud Foundry Container Runtime)。總體來說是利用BOSH來部署Cloud Foundry和Kubernetes,並通過Application Runtime管理Cloud Foundry的Application Service;通過Container Runtime管理Kubernetes的Container Service,比如一些無法部署在Cloud Foundry內的服務,如資料庫、監控等。然後通過Open Service Broker將兩者連接起來,如下圖所示:

容器化Cloud Foundry
將Cloud Foundry所有組件容器化,並部署到Kubernetes上是一種比較新型的整合方式。現在有一些大的廠商做這方面的工作,比如SUSE、IBM和SAP。其核心就是通過將Cloud Foundry的BOSH Release轉化成Docker鏡像,然後通過Kubernetes的部署工具Helm來將Cloud Foundry更加自然地部署到Kubernetes上。只有在生成Cloud Foundry組件的Docker鏡像是需要用到BOSH Cli去轉化BOSH release,部署及部署之後的管理,都不需要BOSH,而是交給Kubernetes來對所有Cloud Foundry組件的Pod、服務及相應配置資源的生命周期進行管理。這樣既享受到了Cloud Foundry帶來的良好的開發者體驗,又用到了Kubernetes強大的管理和擴展能力:


IBM在兩者結合上做的工作和成果

IBM主要是和SUSE合作,在上面第三種方案的基礎上,創建一套可以在IBM Cloud上快速部署的企業級Cloud Foundry。這個新的服務名稱叫做IBM Cloud Foundry Enterprise Environment(CFEE),他的主要構件流程如下:
  1. 首先我們需要將BOSH的Release通過SUSE的轉換工具Fissile將其編譯並製作成CF組件相應的Docker鏡像。

  2. 之後我們需要通過Fissile將預設的引數轉換成Helm或者Kubernetes的配置資源檔案。

  3. 利用IBM Cloud強大的服務資源,增加企業級服務的支持,比如資料庫服務,安全服務和負載均衡服務。

  4. 最後發佈新的IBM CF版本,用戶可以直接在IBM Cloud的Catalog裡面找到並自動部署出一套CFEE環境。

和傳統的BOSH CPI的部署方式的比較,新的Cloud Foundry版本發佈後,管理員只需執行一次來構建任務來創建新版本Docker鏡像和Helm配置,之後就可以重覆使用了。這種部署Cloud Foundry的方式時間大概在15-20分鐘,和之前BOSH部署4-6個小時相比,快了很多。
IBM已於2018上半年的Cloud Foundry Summit上發佈了Experimental版本:

在剛過去的2018年10月初,IBM又發佈了CFEE的GA版,主要為企業級客戶提供更好的服務、帶來更大的價值。部署出來的CFEE環境不但與其他環境是相互隔離的,而且CFEE環境中部署的Cloud Foundry應用還可以很輕鬆地使用IBM Cloud上豐富的服務資源,如AI,大資料,IoT和Blockchain等:

感興趣的用戶可以通過IBM Cloud的Catalog找到CFEE的介紹:https://console.bluemix.net/docs/cloud-foundry/index.html#creating。
在部署頁面中,用戶可以配置CFEE的域名,Diego-cell的個數以及CF版本等信息,然後CFEE可以實現全自動化一鍵部署,大概1個小時左右,一個企業級的CF環境就部署成功了:

當然在部署完成後,CFEE還提供了強大的管理,監控和命令列等功能,如圖所示,用戶可以很輕鬆地在頁面上查看Cloud Foundry和應用的使用情況,創建相應的資源或者系結IBM的外部服務等:


未來兩者結合的發展方向

當然兩者結合的探索工作不止於此,現在越來越多的廠商和開發者加入到兩者整合的研究中。其中比較火的有IBM主導的Cloud Foundry孵化專案Eirini,其想法是想將Cloud Foundry中的Diego-cell容器Garden替換成Kubernetes的容器,從而將兩者更緊密地連接在一起:
還有像SUSE主導的Fissile專案,未來其想法是想通過BOSH命令可以直接生成CF的Docker鏡像和Helm配置,從而可以更好地和社區融合到一起。


總結

綜上所述,Kubernetes之於Cloud Foundry的關係不是挑戰也不是競爭關係,Cloud Foundry希望與其更好地融合,就像Cloud Foundry Foundation執行董事Abby Kearns說的:“Cloud Foundry是結構化的PaaS平臺,其他平臺是非結構化的,用戶的需求是多元化的,並不是一定要如何容器化,而是希望平臺能夠更開放、支持更多的型別。”
不管未來兩者怎麼發展,兩者的結合絕對是適應市場的趨勢,同時又能給用戶帶來多方面的價值提升。未來兩者還能碰撞出什麼樣的火花?讓我們拭目以待!

Kubernetes應用實戰培訓

Kubernetes應用實戰培訓將於2018年11月9日在北京開課,3天時間帶你系統學習Kubernetes本次培訓包括:容器特性、鏡像、網絡;Docker特性、架構、組件、概念、Runtime;Docker安全;Docker實踐;Kubernetes架構、核心組件、基本功能;Kubernetes設計理念、架構設計、基本功能、常用物件、設計原則;Kubernetes的實踐、運行時、網絡、插件已經落地經驗;微服務架構、DevOps等,點擊下方圖片查看詳情。

赞(0)

分享創造快樂