如今，容器正在吃掉整個軟件世界，而其中Kubernetes又是容器之王。因此，當人們想要在企業內開展軟件項目時，他們遲早會用上容器與Kunbernetes。上週，在波士頓舉辦的開發者大會上提出的Cloud Foundry就是一個有趣的例子。
對於大多數非企業開發人員來說，Cloud Foundry是一個陌生詞語，儘管它的用戶有一半都來自於財富500強公司。從某種程度上來說，Cloud Foundry與Heroku相類似，不過它是一個具有大型商業生態系統的開源項目，並且能夠在任何雲和本地模式中進行大規模的部署與運行。開發人員將可以通過編寫他們的代碼（遵循twelve-factor methodology）以定義運行所需的內容，而Cloud Foundry也可以去處理所有底層的基礎設施，並在有必要時進行擴展。理想情況下，這能夠讓開發人員不必去考慮他們的應用程序將在何處運行，並使他們能夠進行更有效地工作。
為了實現這一目標，Cloud Foundry 基金會很早就在容器方面下了賭注，甚至要早於Docker的上市。由於當時Kubernetes並不存在，參與Cloud Foundry項目的各個公司聯合起來構建了自己的容器編制系統，在今天，該系統仍然是大部分服務的基礎。而隨著技術的不斷髮展，向Kubernets提供支持成為了Cloud Foundry 生態中需要邁出的重要一步。去年，基金會做出決定，推出了基於Kubernetes的Container Runtime,以用以進行容器的管理，並可以與現有的Application Runtime進行同步運行。藉助於此，開發人員就可以使用Cloud Foundry運行和管理他們全新或現有的單塊應用程序，並與他們所開發的新服務進行同步運行。
但是，還記得Cloud Foundry是如何讓用戶為自身Application Runtime時運行自己的容器的嗎？其實，既然Kubernetes（以及其生態系統中的其他各種項目）已經成為了容器項目的默認選擇，這種做法已經失去了意義。所以當有了一個利用Kubernetes以取代傳統系統的Cloud Foundry項目時，企業紛紛會選擇應用就不足為奇了。而容器管理並不是加以區分Cloud Foundry的關鍵，相反，開發者的經驗才是重點，所以Cloud Foundry的重心在於開發者們不必對內部基礎設施進行過多的關注。
在有關於Cloud Foundry生態如何擁抱Kubernetes方面，還可以指出的一點就是Cloud Foundry本身也是軟件，這為Kubernetes的流暢運行提供了重要的保證。所以，我們也可以見到，像SUSE和IBM這樣的Cloud Foundry服務商都在提供相關的技術與服務。
比如SUSE的Cloud Application Platform，可以在任何公有云Kubernetes的基礎設施上進行運行，支持包括Microsoft Azure在內的容器服務。這樣SUSE的服務既容易部署，而且運行時所需要的資源也較少。
類似的，IBM也為它的客戶提供基於Kubernetes的Cloud Foundry服務，儘管目前公司只是將其作為實驗性的產品。IBM Cloud Developer Services的總經理Don Boulia強調，IBM的客戶更多會選擇一個不與其他IBM客戶進行共享的孤立環境中進行工作內容的運行。
同時，Boulia也指出，對於大多數客戶來說，這並不涉及到Kubernetes與Cloud Foundry相對比的問題。因為大多數的IBM客戶會選擇使用Kubernetes進行現有應用的轉移，而使用Cloud Foundry去進行新應用程序方面的項目。SUSE的團隊也強調了這一點，他們發現的一種潛在應用模式就是，客戶想要利用建立容器環境以實現自身的願望，然後在與SUSE的溝通中決定使用Cloud Foundry。
歸根到底，Kubernetes和Cloud Foundry其實是互補性的技術，這也正是Google 容器引擎及Kubernetes工程總監Chen Goldberg 在會上所強調的。
翻譯與整理：張飛逸
2018年6月15日 一場「中國軟件渠道夥伴大會」將在北京舉行，歡迎您的到來，我們共謀未來發展。
閱讀更多 人稱T客 的文章
