mirror of
https://github.com/techno-tim/k3s-ansible.git
synced 2025-12-26 02:32:59 +01:00
e7ba494a00
Small tweak to reduce delta from head Set calico option to be disabled by default Add rescue blocks in case updating existing Refactor items and update comments Refactor and consolidate calico.yml into block Refactor to use template for Calico CRs Revert use_calico to false Template blockSize Align default cidr in template with all.yml sample Apply upstream version tags Revert to current ver tags. Upstream's don't work. Update template address detection Add Tigera Operator/Calico CNI option
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::/64is 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.
- The VIP for the Kubernetes API server:
-
fdad:bad:ba55:4200::/56is used internally by the cluster for pods. -
fdad:bad:ba55:4300::/108is 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/16and10.43.0.0/16)are used.
Note that the host running Vagrant is not part any of these IPv4 networks.