TODO.md

Update

Author: https://github.com/jon-stumpf

I came across k3s-ansible looking for an easy why to create a highly-available cluster on my Turing Pi 1. I saw k3s-ansible could easily configure my hosts but was missing the HA component. Further research led me to the k3s-ha branch but found that it still was incomplete for my needs. In developing the needed additions, I discovered issues in the master branch and spent a month reviewing the yaml files of k3s-ansible and the shell scripts from https://get.k3s.io. In the end, I brought k3s-ansible to be at near parity with https://get.k3s.io and I believe I have addressed some open issues as referenced in my pull requests.

Once I completed my changes to the master branch, I got back to work on k3s-ha. Building on the work of St0rmingBr4in, I implemented the HA embedded database using etcd and three cluster VIP methods:

1. external: uses an externally provided cluster VIP
2. kube-vip: uses kube-vip with arp arbitration
3. keepalived: uses keepalived to implement VRRP

I have reached out to itwars and St0rmingBr4in to get their feedback on this work and to collaborate on closing the open issues and pull requests. In the meantime, I would like others to provide feedback on my k3s-ha branch. This is now stable and incorporates all my previous work on k3s-ansible except for a few commits. Please, try it out.

TODO

1. Make all roles idempotent and not report changes when none, in fact, are needed or material.
2. Add keepalived' label to servers when using keepalived; Add the following annotations:
   • keepalived/vrrp_instance=<name>
   • keepalived/master=[true|false]
   • keepalived/version=<version>
   • keepalived/vip=<ipaddr>/<cidr>
3. Add the ability to download the latest version of kube-vip
   • Currently, uses a static version (v0.4.0) that can be manually changed
4. Make sure all roles have defaults defined
5. Make HA not require k3s_token to be defined
   • i.e., use the node-token from the first server
6. Replace command and shell tasks with ansible equivalents (where appropriate)
   • ip
   • kubectl
   • etc.
7. Is the raspberrypi role a NO-OP?
   • It does not appear to execute any tasks that induce change
   • Should it be deleted?
8. From where does k3s-selinux get installed?
   • The reset/download role deletes it.
9. Document lesser switches to control behavior of roles (e.g., remove_packages)
10. Create playbooks for other common operations beyond install/uninstall

Progress Report

Role	Role Type	Idempotent	Only Real Changes	Defaults	commands	TODOs	BUGs
cluster-config	install	✔️	✔️		-	-	-
config-check	install	✔️	✔️	under review	-	-	-
prereq	install	✔️	✔️	n/a	-	-	-
download	install	✔️	✔️	under review	-	-	-
raspberrypi	install	✔️	✔️	n/a	2	1	-
ha/etcd	HA-only		unknown	under review	3	1	-
ha/keepalived	HA-only	✔️	✔️	under review	1	1	-
ha/kube-vip	HA-only	✔️	✔️	under review	2	3	-
k3s/server	install	✔️	✔️	under review	-	-	-
k3s/agent	install	✔️	✔️		-	-	-
reset/download	uninstall	✔️	✔️	under review	2	1	-
reset/ha/keepalived	uninstall	✔️	✔️	by reference	-	-	-
reset/ha/kube-vip	uninstall	✔️	✔️	by reference	3	1	-
reset/k3s	uninstall	✔️	✔️	under review	9	1	2