Suse systems prereqs + HA/etcd installs support

[gnuninu]

This work started as part of the openSUSE hackweek 21 project: https://hackweek.opensuse.org/21/projects/extend-k3s-ansible-support-with-new-functionalities-or-fork-slash-create-new-one

This commit includes the work done in these 2 branches:

• multiserver-HA-etcd
• SUSE_systems_prereqs

HA multiserver deployments with etcd are now supported by specifying the hosts under [multiserver] in the hosts.ini and the arguments can be passed in the dedicated variable extra_multiserver_args independently from the master node. Example of a multiserver HA etcd installation is:

[master]

192.168.122.156

[multiserver]

192.168.122.174

192.168.122.120

and

extra_server_args: "--cluster-init"

In inventory/sample/group_vars/all.yml

The prerequisites for *SUSE systems has been added, now the installation of k3s is supported without disabling firewalld which makes it more suitable for production environment. Thanks to the k3s-on-prem https://github.com/digitalis-io/k3s-on-prem-production/tree/main/roles/k3s-dependencies for the inspiration some pieces of code have been reused here.

Firewalld config and rules are removed when reset.yml is run. The config will be fully rolled back to its original state.

[mallardduck]

I've been looking over examples that use kube-vip to get a VIP for the cluster itself. I found techno-tim's repo that seems largely based on this one, however it takes a different approach to the inventory which might be nicer to follow.

To be clear, I'm only suggesting this PR take inspiration on the inventory and scripting parts that techno-tim uses. I am not suggesting that this repo add kube-vip features in this PR.

Instead of adding an additional group in the hosts file, they simple use the master list to enumerate multiple masters. Then whatever IP is the first one in the list is treated as the "bootstrap master".

Overall I think the benefit there are:

• Keeps all master servers in a single group,
• Does not introduce a new host group with unique set of scripts,
• Lowers duplicate code between the master/tasks and multiserver/tasks file.

I think with some basic refactoring this PR could be massaged to use this method. Beyond the listed benefits that may make it easier for end-users, a side effect would be less new files being added by this PR.

[gnuninu]

thanks a lot for the feedback @mallardduck ! I did not know about techno-tim fork i will take a look at that. I actually thought that having a [multiserver] dedicated group would have been beneficial when it comes to passing different parameters than the master like let's say in the case you wanted to install etcd on standalone server. However i don't think i have tested all the possible scenario. I am going to do some more digging and i'll come back with a feedback!

[dereknola]

Closing in favor of https://github.com/k3s-io/k3s-ansible/pull/210