Purpose built Runtimes

Cloud Foundry is a highly opinionated optimised runtime platform for rapid development and deployment. It gives consistent seamless experience in development using multiple language runtimes. It is opinionated in the right sense that it is battle tested for running The Twelve-Factor App at scale with inbuilt auto-scaling, self-healing, resiliency, secure-by-default and so on. At the same time, it is not just limited to 12f apps, but it is known to get the best out of 12f standard apps.

Kubernetes on the other side is not really opinionated. It is by design meant to handle containers at scale. It can literally run anything that can be packaged into a container. Though it doesn’t offer a much sophisticated developer user experience as a simple cf push but it interests customers that want to push legacy and not so 12f complaint apps to the cloud.

As much as multi-cloud is gaining popularity, multi-platform is also gaining momentum and popularity in various ways. This is very visible between both CF and CNCF foundation as there are so many interesting projects that are happening around these two runtimes.

Where these runtimes stand today, it is really not an argument between either CF or K8s, but more of an AND reality that is been addressed by these runtimes as far as enterprises and their use cases are concerned. Enterprises are really built of varying nature of workloads ranging from heritage, batch, microservices all the way to lately buzzy event driven functions. These runtimes co-exist to address these different set of use cases in a highly efficient opinionated as well as user controlled flexible ways.

In this blog, will explore the eco system and options built around CF and K8s to simplify the multi runtime adoption. We shall look at running a stateless app on CF that consumes a stateful service on K8s in a standard platform controlled service broker interface. I will be using the runtimes of Pivotal (PAS and PKS) to walkthrough the aforementioned use case.

Purpose built Runtimes

Running an app/service on K8s involves quite a lot of work. You need to write code, package it in a container, create needed K8s manifests and then deploy it on K8s. Helm is a K8s package manager that helps you define, install, and upgrade even the most complex K8s application. Helm Chart repo has plenty of pre-packaged services that you can deploy on K8s through a simple helm install command.

Kibosh is an open source project from CF platform engineering team that bridges the gap between K8s services and CF marketplace. It leverages standard driven open service broker to turn literally any Helm chart into a CF marketplace service. Service catalog for CF marketplace is defined through a plans.yml manifest that is the only component that you have to define on top of any existing Helm charts. When deployed with a Helm chart and added to the marketplace,

• cf create-service calls to Kibosh will create the collection of K8s resources described by the chart.
• cf bind-service calls to Kibosh will expose back any services and secrets created by the chart

Bazaar is a Kibosh experimental tile that can be configured through Pivotal’s Operations Manager interface to point to a K8s cluster. This repo has got some sample charts from the upstream with pre-populated catalog info that can be deployed through Kibosh/bazaar-cli to make them available as CF marketplace services. After installing the chart,bazaar -t <endpoint> -u <user_name> -p <password> save mysql.tgz and enabling the service, you should be able to find the service in the CF marketplace.

cf marketplace

• cf marketplace -s mysql

cf marketplace -s mysql

• cf create-service mysql small mysql-ds -c '{"mysqlUser": "admin", "mysqlDatabase": "kibosh"}'

cf create-service mysql small mysql-ds -c '{"mysqlUser": "admin", "mysqlDatabase": "kibosh"}'

Parameters (-c )to the above service are the helm chart values that you specify/customise through values.yml. These are optional anyway.

If you look at the K8s cluster,

• kubectl get ns

kubectl get ns

Kibosh OSB broker implementation has automatically provisioned a namespace in K8s dynamically. If you look into the ns kibosh-b19c135d-2310–4f20-a2d8-b3310de41232, then you would see all the provisioned K8s objects. This is all standard helm stuff done through standard broker implementation.

kubectl get all -n kibosh-b19c135d-2310–4f20-a2d8-b3310de41232

We shall create a service-key to verify the binding credentials being returned to CF apps.

cf service-key mysql-ds mysql-ds-key

It has almost most of the needed credential info that is required to construct the jdbc url. The downside of this by the time of writing this is, it is not in a format that Spring Cloud Service connectors can understand. With the Open for Extension model that Spring Cloud supports, you can write your own ServiceInfoCreator implementation to parse the key in order to construct the binding objects. I have created a custom implementation for bazaar provisioned services to construct and autowire service info to a cf app. The basic implementation is available in the repo,

srinivasa-vasu/spring-cloud-cloudfoundry-bazaar-connector

Next is to deploy a stateless app to CF and bind it to this service mysql-ds

Disable JBP auto-configuration as this will try to bind this service to the CF app using the service tags. As the service tag is mysql which is one of the matching tags to bind a spring cloud patterned service, turning it on would make the binding fail. In this case, since we want our custom implementation to skim through the binding to create the connector info, JBP auto-configuration should be turned off.

• Clone the most popular spring-music repo
• Add the custom ServiceInfoCreator implementation to the build system dependency

• All that’s needed now is a little cf push of spring-music to witness the functioning of CF and K8s in tandem.

I would recommend to read through the content published in Pivotal’s blog on Kibosh service broker to simplify the co-existence of CF and K8s. This space looks promising and can expect a lot more interesting things in the coming days.

Links

https://github.com/cf-platform-eng/kibosh
https://github.com/cf-platform-eng/kibosh-sample/tree/master/sample-charts
https://github.com/helm/charts
https://github.com/cf-platform-eng/kibosh-sample/tree/master/bazaar-tile
https://github.com/cloudfoundry-samples/spring-music
https://github.com/srinivasa-vasu/spring-cloud-cloudfoundry-bazaar-connector