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的優勢在於：
- 成熟的身份驗證系統UAA，使用者組和multi-tenancy的支援
- 方便快捷的cf push
- 自帶負載均衡Router
- 強大的日誌和metrics整合
- 成熟的部署工具BOSH
Kubernetes的優勢在於：
- 大量社群和第三方支援，提供強大的擴充套件性
- 完善的容器生命週期和自動伸縮管理
- 方便快捷的容器化應用部署
- 良好、多樣的持久層支援
- 多種開源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），他的主要構件流程如下：
- 首先我們需要將BOSH的Release通過SUSE的轉換工具Fissile將其編譯並製作成CF元件相應的Docker映象。
- 之後我們需要通過Fissile將預設的引數轉換成Helm或者Kubernetes的配置資原始檔。
- 利用IBM Cloud強大的服務資源，增加企業級服務的支援，比如資料庫服務，安全服務和負載均衡服務。
- 最後釋出新的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的介紹：
ofollow,noindex" target="_blank">https://console.bluemix.net/do ... ating 。
在部署頁面中，使用者可以配置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平臺，其他平臺是非結構化的，使用者的需求是多元化的，並不是一定要如何容器化，而是希望平臺能夠更開放、支援更多的型別。”
不管未來兩者怎麼發展，兩者的結合絕對是適應市場的趨勢，同時又能給使用者帶來多方面的價值提升。未來兩者還能碰撞出什麼樣的火花？讓我們拭目以待！