kinvolk/kube-spawn

using kube-spawn from a release instead of sources is awkward

Opened this issue · 3 comments

alban commented

There are 4 binaries in the release:

  • cni-noop
  • cnispawn
  • kube-spawn-runc
  • kube-spawn

There should be a way to install them in system directories (/bin etc.) to make it work without requiring $CNI_PATH and $GOPATH. But at the moment, kube-spawn-runc has to be installed in $GOPATH/src/github.com/kinvolk/kube-spawn/kube-spawn-runc and the CNI bridge has to be installed in $CNI_PATH.

My full steps to install kube-spawn on Fedora 27:

sudo setenforce 0
sudo dnf install -y btrfs-progs git go iptables libselinux-utils polkit qemu-img systemd-container
mkdir go
export GOPATH=$HOME/go
go get -u github.com/containernetworking/plugins/plugins/...
export CNI_PATH=$GOPATH/bin
mkdir -p $GOPATH/src/github.com/kinvolk/kube-spawn
cp kube-spawn-runc $GOPATH/src/github.com/kinvolk/kube-spawn/kube-spawn-runc
sudo -E ./kube-spawn create --nodes=3
sudo -E ./kube-spawn start
export KUBECONFIG=/var/lib/kube-spawn/default/kubeconfig
KUBERNETES_VERSION=$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)
sudo curl -Lo /usr/local/bin/kubectl https://storage.googleapis.com/kubernetes-release/release/${KUBERNETES_VERSION}/bin/linux/amd64/kubectl
sudo chmod +x /usr/local/bin/kubectl
kubectl get nodes # repeat until the nodes are "Ready"
alban commented

I think we should also add the CNI bridge in the release, to be installed in /usr/libexec/kube-spawn-$VER/. And kube-spawn-runc could be installed there too.

schu commented

The requirement for GOPATH and CNIPATH is gone now (after #256). The user is still required to provide the CNI plugins to kube-spawn, but a one time install to /opt/cni/bin is enough now. Doing that automatically for the user will come with a later change. From my point of view, we can close the issue. What do you think?

alban commented

I see that kube-spawn still vendors CNI (and two different versions of CNI, depending on the package, if I believe Gopkg.toml). I think we should use only one version of CNI. And for the bridge binary: either it is considered an external dependency (in this case, kube-spawn should not install it automatically but just documented), or it is consider internal to kube-spawn (in this case, it should be installed from the vendored version instead of the upstream repo, which could be a third different version. And it should be part of the kube-spawn release).

But that could be a different issue.