Kubo Enables Kubernetes Environments Managed by Cloud Foundry’s BOSH

by Roger Strukhoff and Sophie TurolMarch 20, 2017

A joint effort of Pivotal and Google, Kubo is a new tool that eases Kubernetes deployments managed by BOSH.

Table of Contents

Cloud Foundry–Kubernetes collaboration

We reported last year that there’d been talk for several months about members of the respective Cloud Foundry and Kubernetes communities working on a joint initiative. That bore some fruit in December with the announcement of the Cloud Foundry Service Broker API, which also includes representatives from Google, Fujitsu, IBM, SAP, and Red Hat.

Now another new initiative has emerged, this time between Pivotal and Google: Kubo, which lets users launch a Kubernetes environment managed by BOSH.

BOSH has been enabling enterprise IT teams to provision and manage large Cloud Foundry deployments for some time. With Kubo, it is possible to extend its reach into the world of Kubernetes and its navigation of the Google Cloud Platform.

What’s under the hood

As Kubo’s deployment docs go, the tool relies on Cloud Foundry to perform routing to a Kubernetes cluster. The Kubo deployment is responsible for establishing these routes through the Cloud Foundry Routing API. A specialized BOSH director manages virtual machines (VMs) for a Kubo instance, which handles a VM creation, health checking, and resurrection of missing or unhealthy VMs. The BOSH director includes CredHub—which is used to store the autogenerated passwords, too—and PowerDNS to handle certificate generation within Kubo clusters.

Kubo’s components (Source)

Currently, Kubernetes applications deployed to a Kubo instance can’t be exposed to the outside world, but may follow the same pattern of utilizing the Cloud Foundry routing infrastructure in the future.

Kubo’s networking topology

The nodes that run the Kubernetes API (master) register themselves with the Cloud Foundry TCP router. In its turn, the router acts as both public and internal endpoint for the Kubernetes API to route traffic to the master nodes of a Kubo instance. All the traffic goes to the API through the router and then to a healthy node.

The Cloud Foundry subnet must be able to route traffic directly to the Kubo subnet. If possible, it’s better to keep them in separate subnets to avoid the BOSH directors from trying to provision the same addresses. The diagram below specifies the CIDR ranges for demonstration purposes, as well as a public router in front of the Cloud Foundry gorouter and tcp-router.

Kubo’s networking (Source)

Kubo works with many clouds

Richard Seroter

Currently in alpha release, Kubo can provision dedicated clusters through a Cloud Foundry service broker, according to Pivotal Senior Director of Product Richard Seroter, who wrote about the announcement on his blog.

“Developers will simply type ‘cf create-service kubernetes’ in the CLI and get a dedicated cluster. And this works wherever Pivotal Cloud Foundry (PCF) is installed: on-premises in OpenStack or vSphere, or in public IaaS like the Google Cloud Platform, Microsoft Azure, or AWS.” —Richard Seroter, Pivotal

One initial industry report on Kubo noted how the announcement will let Google Cloud Platform “catapult over” Microsoft Azure. Yet, as Richard states, the joint Kubo PCF tool will work with the three major public clouds.

We contacted Richard, who told us, “we didn’t create Kubo with Google as a way to get apps into Google Cloud. That’s definitely a cool side benefit, but this was customer-driven work. Pivotal customers deploy functions, apps, and containers, and we believe that BOSH can be the common management plane for all those developer abstractions.”

Further, he told us that “whether customers run those abstractions on premises or in a public IaaS, we want them to have a common, automation-centric way to manage their infrastructure. Pivotal Cloud Foundry is fantastic atop Google Cloud, so customers that do choose that for their infrastructure can be sure that the Elastic Runtime and Kubo will run great there.“

Repos are available

Although still in its early stages, Kubo is open-sourced under an Apache 2.0 license, and therefore available to the wider Cloud Foundry community.

Kubo has its own GitHub release and a deployment repo, for anyone interested in digging into it. Richard told us that the team doesn’t have a public date for Kubo’s general availability “just yet,” but we’ll stay close to this story as it evolves.