A New Kubernetes Sandbox

If you want to get started with kubernetes on your local machine, minikube has been the way to go for some time now. Prior to minikube however, we could already run k8s on a single machine using containers and we could also use kmachine, one of the first projects that we started at Skippbox.

Today Bitnami has released the Kubernetes Sandbox available on Google cloud launcher. It is the next iteration of a development environment for kubernetes. It is based on kubeadm and hence is more representative of a production environment than minikube, plus being in the cloud it does not bogg down your local machine. We hope you try it and like it :)

With the Sandbox out, I thought it was time for a little recap about these sandboxes. Especially considering the newly announced availability of Kubernetes in Docker (which I have to admit I don’t know yet what it exactly means).

Running Kubernetes with docker containers

Back in May 2015, I had written about running Kubernetes with a docker-compose manifest.

This was inspired by the early work to get Kubernetes running via containers either all in one node or as a multi-node setup.

Interestingly that is what you find these days with kubeadm albeit in a much better, more robust way. The kubelet runs as a systemd unit and looks in /etc/kubernetes/manifests directory for the defintion of static pods to run the API server, scheduler etc. It is powerful as if any of the components go down, the kubelet will restart them automatically. Also if you update the manifests the kubelet will restart them as well.

kmachine

kmachine is still available but not maintained. It should not take much to get back on track and running the latest version of Kubernetes. Basically it is docker-machine with embedded in the code the provisioning of a single node k8s instance using docker containers. It worked great.

kmachine create -d virtualbox or kmachine create -d digitalocean and you add a k8s endpoint plus your kubectl context was all set.

To show my ignorance with Golang circa 2015, I decided to literally fork docker-machine when I should really have vendored docker/machine/libmachine . Had I done so, kmachine would have become minikube. Hey, you learn from your silly mistakes.

Minikube

Minikube on the other end (or hand, I never know..), uses a binary called localkube which provides a all-in-one k8s/etcd “endpoint”. That is very handy, but if you want to figure out how to configure each Kubernetes components individually, you are well…screwed !

I tried early on in the minikube development to warn about the fact that people would want to mess with individual settings and that minikube should be cloud aware like docker-machine. But this was deemed out of scope.

The Bitnami Kubernetes Sandbox

Minikube has been very useful and I use it all the time in trainings and basic testing. But I have also reached a state where I need more a production setup with direct access to each Kubernetes components, but a beefier machine that what I have locally.

So I wanted a single node Kubernetes cluster in the cloud with all batteries included

GKE is great, but defaults to 3 nodes and I don’t have access to the master node for tinkering. What I was looking for was a single node GKE for dev , and we decided to create the Sandbox. It has Helm, Kubeless, Ingress controller, Heapster Prometheus etc…all the good add ons that you are looking for.

Keep an eye on the Bitnami guides for great how-to content.