IPv6 & CIDR, practical best practices and confusing documentation

[nilo85]

Hello, I am quite new on IPv6, but stuggling to see how to configure it for k3s.

As seen here, and seemingly used by people here.

As far as I understand it, 2001:cafe:42:: is actually a publicly routable address that some poor person in netherlands has according to https://ipinfo.io/..

So what i understand is that we should not use these CIDRs really, and for documentation I think it would be better to use the intended range for that? (2001:db8::/32)

So now to the main question, as I understand it, kubernetes does not really support native ipv6 (following the topology of an ipv6 network), and we dont actually strive to use public ips for pods etc? If so, what ranges should we use? link local? (fe80::)

Any real world best practices how to get started with a dual stack cluster anyone wants to share?

Thanks =)

[nilo85]

Also, the cidr settings, are they per node or per cluster? I guess what we would want it to have a few networka per node if we wanted to try to get proper network topology ?

EDIT: at least with flannel, it seems to be cluster global

[nilo85]

So what I now did was to use a local ipv6 prefix generated via https://unique-local-ipv6.com/#

i.e my install command was:

curl -sfL https://get.k3s.io | K3S_TOKEN='SECRET TOKEN' sh -s - server \
   --cluster-init \
   --flannel-ipv6-masq	\
   --cluster-cidr=10.42.0.0/16,fd08:b5dc:e392::/56 \
   --service-cidr=10.43.0.0/16,fd08:b5dc:e393::/112 \
   --tls-san #THE_HOSTNAME

And then adding nodes like this

 curl -sfL https://get.k3s.io | K3S_TOKEN='SECRET TOKEN' sh -s - server \
    --server https://FIRST-NODE:6443 \
    --flannel-ipv6-masq	\
    --cluster-cidr=10.42.0.0/16,fd08:b5dc:e392::/56 \
    --service-cidr=10.43.0.0/16,fd08:b5dc:e393::/112 \
    --tls-san #THE_HOSTNAME

Anyone knows if this is a good practice?

[brandond]

The CIDRS are cluster-wide. The service-cidr is used to assign service ClusterIPs, the cluster-cidr is subdivided and assigned to nodes to hand out to Pods.

IPv4 traffic leaving pods is usually NATed to come from the node's IP address, but with IPv6 this is less common. Folks will frequently assign clusters a section of their internal IPv6 range, and expect that to be routed within their internal network, and handled at the edge however they normally handle IPv6 traffic bound for the internet.

How you configure it is really up to you, there is no one "correct" way to do it.