RomanNum3ral
/
k3s-ansible
mirror of https://github.com/timothystewart6/k3s-ansible.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
k3s-ansible/molecule/ipv6
History
Timothy Stewart 6d49ad6977 fix(dependencies): address PR review findings 
- Read the MetalLB speaker tag check from the managed host with slurp
  instead of a controller-side file lookup, and match the full image
  reference
- Restore the tigera-operator namespace on the Calico operator Deployment
  wait while keeping the managed CRD waits cluster-scoped
- Make Molecule verify inputs durable and scenario-specific via a
  per-scenario verify-vars.yml, driven by explicit verify_cni/verify_lb
  values instead of non-persisted converge facts
- Rename the kube-vip multi-peer BGP env var from bgppeers to bgp_peers
  and vip_cidr to vip_subnet so v1.2.2 actually reads them
- Map the legacy Cilium routed mode to tunnel and stop passing the alias
  directly to the chart
- Use return-code based failed_when on apply and preflight commands so
  non-error failures are no longer treated as success
- Clarify the sequential K3s upgrade path and backups in the README
- Add kube-vip and MetalLB regression tests and a Cilium mode mapping unit
 		2026-08-01 22:36:14 -05:00
..
host_vars Fix dual-stack clusters with multiple master nodes (#237) 2023-02-20 05:24:19 +00:00
templates Add support for API servers on IPv6 addresses (#48) 2022-09-10 12:57:38 -05:00
README.md Add support for API servers on IPv6 addresses (#48) 2022-09-10 12:57:38 -05:00
molecule.yml test(molecule): update Vagrant boxes to current releases 2026-08-01 19:13:48 -05:00
overrides.yml fix(molecule): serialize guest fact gathering 2026-08-01 19:13:48 -05:00
prepare.yml Change to FQCN with ansible-lint fixer (#553) 2024-08-12 22:59:59 -05:00
verify-vars.yml fix(dependencies): address PR review findings 2026-08-01 22:36:14 -05:00

README.md

Sample IPv6 configuration for k3s-ansible

This scenario contains a cluster configuration which is IPv6 first, but still supports dual-stack networking with IPv4 for most things. This means:

  • The API server VIP is an IPv6 address.
  • The MetalLB pool consists of both IPv4 and IPv4 addresses.
  • Nodes as well as cluster-internal resources (pods and services) are accessible via IPv4 as well as IPv6.

Network design

All IPv6 addresses used in this scenario share a single /48 prefix: fdad:bad:ba55. The following subnets are used:

  • fdad:bad:ba55:0::/64 is the subnet which contains the cluster components meant for external access. That includes:

    • The VIP for the Kubernetes API server: fdad:bad:ba55::333
    • Services load-balanced by MetalLB: fdad:bad:ba55::1b:0/112
    • Cluster nodes: fdad:bad:ba55::de:0/112
    • The host executing Vagrant: fdad:bad:ba55::1

    In a home lab setup, this might be your LAN.

  • fdad:bad:ba55:4200::/56 is used internally by the cluster for pods.

  • fdad:bad:ba55:4300::/108 is used internally by the cluster for services.

IPv4 networking is also available:

  • The nodes have addresses inside 192.168.123.0/24. MetalLB also has a bit of address space in this range: 192.168.123.80-192.168.123.90
  • For pods and services, the k3s defaults (10.42.0.0/16 and 10.43.0.0/16) are used.

Note that the host running Vagrant is not part any of these IPv4 networks.