上個月，Pivotal [url=https://content.pivotal.io/blog/pivotal-brings-the-magic-of-cf-push-to-kubernetes]宣佈[/url]他們的旗艦產品 - 基於Cloud Foundry的Pivotal應用服務 將使用Kubernetes。我進行了實驗：請求訪問私有alpha，並被允許進入。在新增一些資源後，我在實驗室環境中部署了它。

安裝完成後，cf push足以讓我的應用程式程式碼在Kubernetes上作為容器執行。

• 所以您可能會問：“但是等等，自2010年以來，部署在Cloud Foundry上的應用程式不會作為容器執行嗎？” 

  是的。

• “Cloud Foundry沒有配備執行所有這些應用程式的容器協調器（如Kubernetes）嗎？” 

  是的，它的協調器被稱為Diego。

• “它Diego更復雜嗎？” 

  相反。它不要求使用者投資容器或容器協調器知識。

• “我想它Diego必不如Kubernetes成熟？” 

  不完全是這樣。它及其前身 - Droplet執行代理（DEA） - 多年來已經在這個世界上最大的企業組織中執行了數十萬甚至數百萬的應用程式。事實上，甚至在Kubernetes或Docker之前還是那麼一回事。

• “但我們肯定可以用Kubernetes做更多的事，對吧？” 

  是的，也不是，Kubernetes有更多的旋鈕和螺栓來調整應用程式的執行方式。但是，它還沒有Diego現在提供的所有選項。

• “我很困惑：鑑於上述情況，你為什麼要用Kubernetes取代Diego？” 

  因為開源並不是一場零和遊戲，正數之和由玩家數決定。

• “再來一次？” 

  無論喜歡與否，到目前為止，致力於Kubernetes的組織數量如此巨大，幾乎可以肯定它將成為基礎架構的未來，因為虛擬機器已經擺在面前。

• “因此，我們的想法是從轉向標準平臺中獲利？” 

  Cloud Foundry貢獻者將不再需要維護他們自己的自定義容器協調器，因為他們可以釋放他們最好的人來處理技術棧中更高的功能。增加更多價值。

  其次，Kubernetes社群有這樣的勢頭，當我們從同一點開始時，可​​能會以類似的方式替換Cloud Foundry的更多元件。

  最後，客戶特別要求它。儘管容器協調器只是更豐富的Cloud Foundry產品中的實現細節，但仍有一些人關心。

• “當我們擁有Kubernetes時，我們還需要Cloud Foundry嗎？” 

  沒有任何改變。雖然Kubernetes可能是基礎架構的未來，但它不是開發人員平臺。但有些人認為也是開發者平臺，但如果你強迫 - 或允許 - 你的開發人員直接與容器和容器協調器一起工作，你可以確定他們將大部分時間花在這上面，而不是編寫為你的業務增加價值的程式碼。

• “所以在K8上的PAS中，一切都作為容器執行嗎？”

  不。只是應用程式。兩年前，IBM啟動了一項名為Eirini的計劃，將Cloud Foundry的容器協調器從Diego切換到Kubernetes。Pivotal今年加入，結果是Kubernetes（K8s）的Pivotal Application Service（PAS）。

  還有另一個計劃 - 專案Quarks - 旨在將Cloud Foundry元件（目前使用虛擬機器上的BOSH版本部署）切換到Kubernetes可部署的Helm圖表。這還沒有在K8上的PAS中。此外，Helm包管理器存在嚴重問題，需要在它變得像BOSH一樣堅固之前加以解決。

• “終端使用者會注意到什麼嗎？” 

  理想情況下，不會注意到。Cloud Foundry的終端使用者一直是開發人員，對他們來說沒什麼變化。請注意，這不是第一次或最後一次將Cloud Foundry的自定義元素替換為已成為開源標準的軟體。例如，自定義路由器層正在被Istio服務網格取代，這項工作正在進行中。

• “它將如何幫助我們自己的客戶？” 

  與常規PAS一樣：通過授權他們更快，更安全地建立和部署新業務功能而無需停機。