Whether this is accomplished via the newer cert services, some buried part of kubeadm, puppet + packages, etc. Ensure that we are ideally not manually slinging around a join token. If we actually are doing that, find a way to distribute that or run it via puppet or similar.
|Open||• bd808||T232536 Toolforge Kubernetes internal API down, causing `webservice` and other tooling to fail|
|Open||None||T236565 "tools" Cloud VPS project jessie deprecation|
|Open||None||T214513 Upgrade Toolforge Kubernetes|
|Resolved||aborrero||T142862 Setup Kubernetes Masters in a HA setup|
|Resolved||aborrero||T215530 Sort out the best method of spinning up multiple toolforge kubernetes masters|
|Resolved||aborrero||T215679 Sort out and test deploying the worker nodes in a sane fashion|
According to the last status updates on T215531: Deploy upgraded Kubernetes to toolsbeta, we are bootstrapping worker nodes by using kubeadm with a pre-shared token. This token is stored in hiera (private repo).
When a new cluster is being built, kubeadm generates a cmdline that we should copy-paste into the joining worker node.
Or alternatively, we can just use our pre-configured config file which contains also the required bits to join the cluster.
root@newworker:~# kubeadm join --config /etc/kubernetes/kubeadm-join.cfg` <--- this file is maintained by puppet -o- root@newworker:~# kubeadm join <FQDN>:6443 --token <token> --discovery-token-ca-cert-hash sha256:<hash> <--- this is generated by kubeadm init