Bootkube and the path forward to Openstack.

I have been trying to figure out how to provision developer environments for Kubernetes / Openstack deployments.  I was hoping i could get kubernetes provisioned on Windows and then use Helm to provision Openstack, but i started running into issues with building the kubernetes helm charts on Windows.  So...i moved to CentOS, this time i had to work with a headless server and try to get VirtualBox and Vagrant to play nice under CentOS 7.  This combination appears promising.  After downgrading to Vagrant 1.8.6 ( the 1.9 versions do not play nice with CentOS 7 from what i can see) i was able to get a combination of Vagrant and VirtualBox 5.1 working.  Note, I also had to install the extensions package for Virtualbox to get headless working.  I plan to try to finish up the install next week as it could work.

All this switching from environment to environment, and from toolset to toolset has left me wondering if I actually have the right set of choices.  Enter Bootkube.  One of the major requirements for my new work is that i can deploy to CoreOS nodes in the future.  I had figured out to deploy Kubernetes one Core OS but.... Bootkube may actually be the better choice.  Its using kubernetes itself instead of Vagrant.

So...back to the drawing board.

Bootkube does support 3 options that I will be useful:

• CoreOS Baremetal
• Vagrant Single-Node
• Vagrant Multi-Node

The downside.  I have to give up the simplicity of Ansible deployment for CoreOS nodes and move back to Matchbox for CoreOS bareMetal.  This may not be all that bad... maybe i have to bite the bullet and finally learn PXE a little better.

At least this solution will have inroads to a CoreOS supported system if it turns out we do need professional support.  Tectonic uses matchbox and the Openstack product from CoreOS uses tectonic.  So...learning matchbox a little better might be a good play.

I did in fact get matchbox installed just before i opted for Ansible.  So maybe now that Bootkube is in the mix - there is another point in favor of Matchbox.  Ansible still fits into the big picture as we will need it to provision nodes, just the resilient part of bootKube seems compelling.

See: https://github.com/kubernetes/community/blob/master/contributors/design-proposals/self-hosted-kubernetes.md

But this is not the end of the story:

As per the docs,

Ideally bootkube disappears over time and is replaced by a Kubelet pod API. The write API would enable an external installation program to setup the control plane of a self-hosted Kubernetes cluster without requiring an existing API server.