Building on our experience with Cloud Foundry and Kubernetes

A number of us from the HPE Helion team joined SUSE back in March and have been working hard on SUSE’s new cloud application and container platforms. Our team is building a Cloud Foundry distribution based on SUSE Linux that runs on Kubernetes.

We’ve had a bit of practice at this. Helion Stackato 4 actually ran on Kubernetes under the hood, but with a control plane abstraction layer which was intended to simplify management and eventually allow for different container schedulers underneath (e.g. Mesos, Swarm).

When we joined SUSE, work was well underway on SUSE CaaS Platform which is based on Kubernetes. It made sense to double down on Kubernetes as the container orchestration technology to support our Cloud Foundry work. Removing the intermediary layer allowed for a cleaner architecture and let us take advantage of more (and newer) Kubernetes features.

We got to show off an early version of this at the Cloud Foundry Summit Silicon Valley this spring. The reaction we got from CF developers, customers, and partners was overwhelmingly positive, but we had a lot of people asking us if this had anything to do with the Kubo project or the recently launched PKE.

Kind of. We’ve taken a different approach to solving the “Give me Kubernetes to run my containerized apps” request that we keep hearing from users.

Kubo orchestrates Kubernetes using BOSH. Our platform orchestrates Cloud Foundry using Kubernetes.

The latter approach allows Kubernetes to do something that it already does exceptionally well — manage the configuration and health of fleets of containers — to provide a high-availability fabric for running Cloud Foundry. The removal of the BOSH learning curve for operators is an attractive component of this for a lot of people.

Both our platform and the Kubo project are driven by the same user requirement, which can best be summed up as “Give me Kubernetes.”