forked from tim/k3s-ansible
Techno Tim
f5483cdabe
* fix(flannel): default the interface to each host's default IPv4 interface - Replace the hardcoded flannel_iface: eth0 with a per-host default derived from ansible_facts.default_ipv4.interface - KVM/cloud hosts that are not named eth0 (e.g. enp1s0, ens3) now resolve the interface automatically instead of failing the k3s_node_ip lookup - Update the commented calico_iface / cilium_iface examples to match - Co-authored-by: Fritz Dunkel <677609+FinalDoom@users.noreply.github.com> - Fixes #621 * test(flannel): add regression test for per-host interface default - Add a focused test that renders the sample inventory's flannel_iface expression against fake ansible facts - Assert a non-eth0 host (enp1s0, ens3) resolves its own interface and that the expression defaults from ansible_facts.default_ipv4.interface - Wire it as a local pre-commit hook (default-interface-test) * test(molecule): assert nodes register a non-loopback InternalIP - Add a flannel-scenario verify assertion that every node reports an InternalIP derived from its configured flannel_iface - Guards against k3s binding to 127.0.0.1 instead of the cluster interface - Complements the pre-commit default-interface test with an end-to-end check
Test suites for k3s-ansible
This folder contains the molecule-based test setup for this playbook.
Scenarios
We have these scenarios:
- default: A 3 control + 2 worker node cluster based very closely on the sample inventory.
- ipv6: A cluster that is externally accessible via IPv6 (more information) To save a bit of test time, this cluster is not highly available, it consists of only one control and one worker node.
- single_node: Very similar to the default scenario, but uses only a single node for all cluster functionality.
- calico: The same as single node, but uses calico cni instead of flannel.
- cilium: The same as single node, but uses cilium cni instead of flannel.
- kube-vip The same as single node, but uses kube-vip as service loadbalancer instead of MetalLB
How to execute
To test on your local machine, follow these steps:
System requirements
Make sure that the following software packages are available on your system:
Set up VirtualBox networking on Linux and macOS
You can safely skip this if you are working on Windows.
Furthermore, the test cluster uses the 192.168.30.0/24 subnet which is not set up by VirtualBox automatically.
To set the subnet up for use with VirtualBox, please make sure that /etc/vbox/networks.conf exists and that it contains this line:
* 192.168.30.0/24
* fdad:bad:ba55::/64
Install Python dependencies
You will get Molecule, Ansible and a few extra dependencies via pip. Usually, it is advisable to work in a virtual environment for this:
cd /path/to/k3s-ansible
# Create a virtualenv at ".env". You only need to do this once.
python3 -m venv .env
# Activate the virtualenv for your current shell session.
# If you start a new session, you will have to repeat this.
source .env/bin/activate
# Install the required packages into the virtualenv.
# These remain installed across shell sessions.
python3 -m pip install -r requirements.txt
Run molecule
With the virtual environment from the previous step active in your shell session, you can now use molecule to test the playbook. Interesting commands are:
molecule create: Create virtual machines for the test cluster nodes.molecule destroy: Delete the virtual machines for the test cluster nodes.molecule converge: Run thesiteplaybook on the nodes of the test cluster.molecule side_effect: Run theresetplaybook on the nodes of the test cluster.molecule verify: Verify that the cluster works correctly.molecule test: The "all-in-one" sequence of steps that is executed in CI. This includes thecreate,converge,verify,side_effectanddestroysteps. Seemolecule.ymlfor more details.