Richard Bucker

Getting Started with Kubernetes

Posted at — Feb 7, 2015

I’m trying to go through the Kubernetes Getting Started and I’m not getting started. The team has provided a number of ways to get started but none of them are working… let’s get started:GCE - Google’s Compute Engine would be a great choice but I’m trying to develop some ideas about how useful Kubernetes is. In that case I’m just hacking so I’m not interested in having to setup accounts and payments just for the sake of experimentation. I will probably come back to this as I will explain…CoreOS was the first strategy I tried. I have had tremendous success with CoreOS and CoreOS clusters. I’ve distributed fleet clusters, docker and rocket containers. I’ve also deployed CoreOS clusters using the CoreOS-vagrant tool. So this seemed like a no-brainer. However, it failed. The prerequisites included vagrant, virtualbox, net-tools, and either build or install the kubernetes binary. (a) they were not clear about the source or target of the net tools. I assume I should already know what that is and it’s probably from virtualbox or vagrant… oh well. Building Kubernetes from source is supposed to be simple, however, since I already use boot2docker for other tasks the network addressing does not match the expectation. It’s interesting that they are also mapping boot2docker but that it’s not mentioned.Fedora/Ansible is not an option. I suppose this could be one of those defining moments when I discover Ansible but not for the moment.Fedora/Manual is even less of an option.Local was meant for someone running Linux as a host; it is not an option for my MacBook.Microsoft Azure could be an option. MS has been doing a lot to capture some of the market. Even their *nix mission seems to have changed. In the meantime it’s still a service which is going to require some work and possibly some money. If I were to go the cloud route I’d defiantly go with the GCE since I already have an account there.Rackspace appears to be more of the idempotent structure I was looking for. And even though I have an account at Rackspace the tool is based on OpenStack and so it requires installing Python, virtualenv, Nova and swiftly. It’s just not the way I envision the tools to work.The CoreOS option is interesting because there are 6 different strategies. The SingleNode and ClusterNode models seem to be the most idempotent. Any changes would require taking a snapshot and then sharing on a repo someplace. One of the multinode methods required installing fleet and etc on the local host. This is not bad but can get wonky. Another option includes weave which is an open source network framework which I think the CoreOS will trump with their Flannel project. But again there are requirements made upon the host.I have the unreasonably strong opinion that the host should be pristine and nothing beyond the base operating system and the tools for which version is unimportant. For example one’s choice of editor, git, mercurial, boot2docker, virtualization and so on. Using boot2docker does have a host component, however, upgrading has not had any effect on the overall system. Sadly tools like rvm and virtualenv can be a serious headache to maintain although development before them was extremely painful. But until someone tells you the stories of development on DOS with a single toolchain you’ll never truly appreciate this approach. Just consider the amount of productivity lost just maintaining all of these versions.So coming full circle… GCE is looking like the right choice again. The trick is going to be managing the cost by destroying non-functioning clusters. Once the cluster has been compiled, tested and the results captured. Dump it. The actual cost for the smallest node is about $.02 per hour. Granted it’s severely limited in RAM, Disk and CPU; however; even at a $.50 per hour for a bigger cluster/node you’re not paying for downtime and at that pace it’s probably very cost effective. (just don’t leaving them running over night.)