Kubo更名為CFCR，成為Cloud Foundry部署Kubernetes的預設方案
更新後的Kubo釋出工具，改名為Cloud Foundry Container Runtime（CFCR），被Cloud Foundry採納作為利用Kubernetes和BOSH來部署容器的預設方案。
根據其CTO Chip Childers的說法， Cloud Foundry 基金會（https://www.cloudfoundry.org/）已經把Container Runtime加入了他們的Application Runtime家族中，並將兩者改名（Application Runtime之前被稱作Elastic Runtime）。改名有助於向開發者介紹該專案，也有利於業界理解現階段的兩種抽象。基金會在這周於瑞士舉辦的Cloud Foundry Summit Europe 2017（https://www.cloudfoundry.org/event/europe-2017/）上正式宣佈了這次改動。
Application Runtime是一種以應用為主的平臺，旨在簡化整個部署的流程。Container Runtime則運用了與Cloud Foundry不同的元件（比如說BOSH），提供了一種統一的方式來建立、部署和管理任何雲上的高可用Kubernetes叢集。
“這個專案最初是由那些使用Cloud Foundry的生態系統，BOSH工具以及Application Runtime的大公司牽頭髮起的。從工作的經驗中，他們看到了對這層額外抽象（Container Runtime）的需求，”他說：“通過社群提供的服務，他們可以在公共雲和私人云之間以一種輕便的方式進行工作。”
BOSH是一個為釋出，部署以及管理大規模分散式服務的生命週期提供一系列工具的開源專案。
在New Stack釋出的文章（https://thenewstack.io/living-multi-cloud-world/）中，Childers解釋了在原生雲的世界中，有對多平臺協同工作的需求。他提到Kubo和Open Service Broker API（OSBAPI）（https://www.openservicebrokerapi.org/），這兩個專案正在實現這樣的需求。
他把BOSH形容成一個抽象層來幫助你和各種型別的基礎設施互動，包括了公有云（Amazon或者Azure），私有云以及虛擬化的基礎設定（OpenStack，vSphere叢集或是裸機）。他還強調說BOSH在設計上旨在滿足下一代部署流程的需求。
Childer還提到說：儘管Kubernetes很火，但是對Kubernetes叢集的生命週期管理也漸漸變成了一個痛點。
來自紅帽公司的架構師，同時也是多個開源專案（Apache Camel，OFBiz and Isis 專案）的貢獻者Bilgin Ibryam在另一篇博文（https://thenewstack.io/myth-cloud-native-portability/）中提到說，那種覺得只要把應用封裝在容器內部，就能在不同的原生雲平臺上輕鬆地移植的想法是錯誤的。
他說：“無論是使用Mesos，Cloud Foundry，Kubernetes，Docker Swarm 還是亞馬遜的ECS，你都要花大量的精力來所選的平臺以及對應的工具，去理解它們的工作方式，還要與這些日新月異的技術和公司打交道。”Cloud Foundry的Container Runtime就是Cloud Foundry基金會給出的一種解決方案。
提供恢復能力Pivotal和Google在六月份開源了Kubo專案。Childer說，Pivotal Container Service是Cloud Foundry Container Runtime專案裡的第一個商業化產品。但是，它同時也被IBM和VMWare商業化了。
Kubo也被稱為是Cloud Foundry用來複制整個Kubernetes環境，以確保在主節點故障時的高可用性的替代方案。它利用了一些Cloud Foundry已有的平衡虛擬機器負載的功能來在虛擬機器內部平衡多個併發的Kubernetes例項之間的流量。
Childer說，這兩種抽象有不同的應用場景。如果你寫了很多自定義程式碼，那就理應使用PaaS，它能處理諸如對軟體容器化、拉取依賴包等的類似任務。而Container Runtime則更加側重運營商。Container Runtime是對Kubernetes的封裝，由BOSH來管理和部署。BOSH負責將公有云或是不同的本地基礎設施（如OpenStack或者VMware vSphere）進行抽象化。抽象化之後它能創造一個健壯的分散式系統的管理方案。
Container Runtime和Application Runtime都有負責維護已被部署的容器或應用的健康狀況的元件。這樣如果一個節點不能工作了，那任務就會被重新排程給叢集中的其他節點。
Childers又說道：“問題現在變成了：什麼在維護叢集自己的健康？Cloud Foundry社群已用BOSH來維護叢集的健康很長時間了。BOSH可以為運營商平臺提供更好的彈性。幫助他們在執行Kubernetes時也有相同的體驗。”
“Kubernetes有很強的解決問題的能力，但是不能自我修復。你需要自己找一個方法來完成修復。”
Childer解釋說：“Google在內部使用了Borg（https://www.thenewstack.io/tag/Borg）平臺來實現自我修復，這個平臺包含了所有應用的負載。”
“BOSH的開發有Brog的團隊的參與，並在設計上借鑑了Brog。對於沒有在Google工作的人而言，BOSH提供了一個類似Brog的方案以供選擇。”
Application Runtime和Container Runtime都能在任何雲資源上執行任意語言的應用。這種靈活性可以通過Open Service Broker API擴充套件到服務上。
Childer說，你會一直看到Container Runtime與BOSH一同協作來給Kubernetes編排工具提供持久資料儲存這一領域上不斷髮展。這對資料服務而言是至關重要的。Container Runtime專案現在對Google Cloud Platform（https://cloud.google.com/kubernetes-engine/），Amazon Web Services和vSphere也提供永久性的支援。
下一個目標領域是和Itsio（https://www.thenewstack.io/tag/Itsio）網狀網路服務專案合作，確保它也能與Kubernetes一同協作。
原文連結：https://thenewstack.io/kubo-becomes-cloud-foundrys-container-runtime-default-kubernetes-deployment/ 基於Kubernetes的DevOps實踐培訓本次培訓內容包含：Kubernetes架構、安裝、深入瞭解Kubernetes、Kubernetes高階——設計與實現、Kubernetes落地實踐、微服務、Cloud Native等，點選識別下方二維碼加微信好友瞭解具體培訓內容。