I just came across this Little Guide to Kubernetes Install Options, which covers a few options I’ve heard of, and a few options I haven’t heard of. It doesn’t mention the main way that I deploy Kubernetes, which is through the Ansible scripts from the kubernetes/contrib repository. The post does point to another Ansible-based option, though, and I wondered whether this one, called Kubespray (nee Kargo) would work with Atomic Hosts.

I installed kubespray:

$ sudo pip2 install kubespray

I generated an inventory for a baremetal (actually VMs) cluster with one etcd host / kube master and two nodes:

$ kubespray prepare --nodes node2[ansible_ssh_host=cah-2.osas.lab] node3[ansible_ssh_host=cah-3.osas.lab] --etcds node1[ansible_ssh_host=cah-1.osas.lab] --masters node1[ansible_ssh_host=cah-1.osas.lab]

I deployed the cluster, providing the argument -u root because my ansible host was already set up to access my test VMs as root via ssh key:

$ kubespray deploy -u root

The ansible zoomed by, eventually ending with:

PLAY RECAP *********************************************************************
localhost : ok=3 changed=1 unreachable=0 failed=0
node1 : ok=393 changed=95 unreachable=0 failed=0
node2 : ok=333 changed=76 unreachable=0 failed=0
node3 : ok=303 changed=65 unreachable=0 failed=0

Kubernetes deployed successfuly

I tested the cluster by deploying the guestbook go sample app, as is my custom, and sure enough, everything seemed to be working.

The biggest difference between this installation route and the one I usually take is the source of the containers. Where I typically run CentOS Atomic with Kubernetes rpms from the CentOS project or with containers based on those rpms, and the same with Fedora Atomic and Fedora-based content, the Kubespray installer set me up with container images mostly from CoreOS:

[root@cah-1 ~]# atomic containers list
CONTAINER ID IMAGE COMMAND CREATED STATE BACKEND RUNTIME
19d6514ceb1a quay.io/coreos/hyper /hyperkube controlle 2017-08-11 18:54 running docker docker
47bb6f63af38 gcr.io/google_contai /pause 2017-08-11 18:54 running docker docker
2102af0a5915 quay.io/coreos/hyper /hyperkube scheduler 2017-08-11 18:54 running docker docker
8af0c87bcfbd gcr.io/google_contai /pause 2017-08-11 18:54 running docker docker
c91bf4d9c687 quay.io/coreos/hyper /hyperkube apiserver 2017-08-11 18:54 running docker docker
96bc198022ac gcr.io/google_contai /pause 2017-08-11 18:54 running docker docker
e5cedfe5145e calico/node:v1.1.3 start_runit 2017-08-11 18:53 running docker docker
a31b6a04be23 quay.io/coreos/hyper /hyperkube proxy --v 2017-08-11 18:52 running docker docker
877aa10ab6a4 gcr.io/google_contai /pause 2017-08-11 18:52 running docker docker
b9f64835b7e5 quay.io/coreos/hyper ./hyperkube kubelet 2017-08-11 18:52 running docker docker
1bab52292b2d quay.io/coreos/etcd: /usr/local/bin/etcd 2017-08-11 18:48 running docker docker

It’s not a big deal swapping out one container source for another, however. Fedora and CentOS aren’t providing a hyperkube container, which is what kubespray (and kubeadm, for that matter) look to use, but we could create one for Fedora and CentOS based on the upstream Dockerfile.