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等，点击识别下方二维码加微信好友了解具体培训内容。

点击阅读原文链接即可报名。