Kubo Becomes Cloud Foundry’s Container Runtime, Default for Kubernetes Deployment
The updated Kubo deployment mechanism, renamed Cloud Foundry Container Runtime (CFCR), has become the default Cloud Foundry approach to deploying containers using Kubernetes and BOSH lifecycle management tool.
The Cloud Foundry Foundation has added the container runtime to its Application Runtime, previously called Elastic Runtime, renaming both to better explain it to developers and so that the industry as a whole can understand that there are two valid abstractions, according to foundation Chief Technology Officer Chip Childers. The Foundation announced the changes at its Cloud Foundry Summit Europe 2017, held this week in Switzerland.
Application Runtime is an app-centric platform that simplifies the entire development lifecycle. Container Runtime uses components unique to Cloud Foundry, such as BOSH, to create a uniform way to create, deploy and manage highly available Kubernetes clusters on any cloud.
“The project is so driven by large enterprises that are adopting Cloud Foundry, adopting BOSH, application runtime. They saw the need for this additional abstraction to be part of their experience,” he said. “By our community providing this, they can have this blended experience in a portable way across public clouds and private infrastructure.”
BOSH is an open source project that offers a toolchain for release engineering, deployment and lifecycle management of large-scale distributed services.
In a contributed post for The New Stack, Childers explained the need in a cloud-native world, for multiple platforms to work together. He cited Kubo and the Open Service Broker API (OSBAPI) as two projects making this happen.
He described BOSH as an abstraction layer that lets you talk to virtually any infrastructure type, whether it’s a public cloud like Amazon or Azure, a private cloud, or virtualization infrastructure — an OpenStack deployment, a vSphere cluster, or bare metal. Most importantly, BOSH is designed to support the deployment’s “day two” needs, he said.
Despite its popularity, lifecycle management of Kubernetes clusters is emerging as a pain point, Childers said.
And the idea that as long as you package your application in containers, you are portable across different cloud-native platforms with minimal effort is wrong, Bilgin Ibryam, architect at Red Hat and open source committer to the Apache Camel, OFBiz and Isis projects argued in another post.
“Whether you start with Mesos, Cloud Foundry, Kubernetes, Docker Swarm, ECS, you have to make a significant investment to learn the platform and the supporting tools, understand the culture and the ways of working, and interact with this still fast-changing ecosystem of technologies and companies,” he said.
This is one of the ways the Cloud Foundry Foundation is addressing that.
Providing Resilience
Pivotal and Google open sourced Kubo in June. Pivotal Container Service is the first commercialization of the Cloud Foundry Container Runtime, Childers said, but it’s also being commercialized by IBM and VMware.
It’s been called Cloud Foundry’s alternative to replicating the entire Kubernetes environment to ensure high availability should the main master fail. It’s a way of leveraging Cloud Foundry’s existing features for load balancing virtual machines, for effectively balancing traffic to multiple concurrent Kubernetes instances inside VMs.
What Kubo Brings To Cloud Foundry And Kubernetes
There are different use cases for the two abstractions, Childers said. If you’re writing a lot of custom code, that makes sense use the main PaaS experience, which handles things like containerizing the software, pulling in dependencies, etc.
The container runtime is more operator-focused. The container runtime is the packaging of Kubernetes, deployed and managed by the BOSH layer. BOSH takes responsibility for abstracting the infrastructure, whether the in public cloud or different on-premises infrastructure systems such as OpenStack or VMware vSphere. It abstracts that away and creates robust distributed system management, Childers said.
Both the container runtime and the application runtime have components that take responsibility for maintaining the health of the application or container that’s being deployed. So if a node goes offline, they will reschedule the work to other nodes in the cluster.
“The question became: What is maintaining the health of the clusters themselves?” Childers said. “The Cloud Foundry community has been doing this for a long time with BOSH. It provides a great level of resilience for the platform itself for operators. They wanted to see that same experience when running Kubernetes.
“Kubernetes has a great capacity to work around problems, but it doesn’t self-heal. You need a way to do that.”
Google does this internally with a platform called The Borg that includes all its application workloads, Childers explained.
“BOSH has its origins in the design and some of the team members of Borg. It’s the Borg option for those of us who don’t work for Google.”
Both the application runtime and container runtime provide flexibility to run apps in any language or framework on any cloud. This flexibility extends to services as well through the Open Service Broker API, which applies to both Application Runtime and Container Runtime.
One of the areas where you’ll continue to see Container Runtime evolve is in working with the BOSH layer to provide persistent data volumes that can be used by the Kubernetes orchestrator, Childers said. This is especially important for data services. Default support for persistence on Google Cloud Platform (GCP), Amazon Web Services (AWS) and Vsphere are now available for the Container Runtime project.
The next area in progress is working with the Itsio service mesh network project, making sure it works well with Kubernetes.
The Cloud Foundry Foundation, Google, OpenStack Foundation and VMware are sponsors of The New Stack.
Feature image by Alex Williams.
