Open mganter opened 2 years ago
How do you model Google's IPv6 deployment plan where each Node gets assigned a /96 from which the PODs running of these nodes need to be assigned?
Well that's a good catch and I honestly have no clear vision of how this could be handled. We might need something in the configuration that allows to express that the IPv6 address range might require some web-hook and additional calculation to get the sub-net but without being overly complicated.
Could be something like:
networking:
type: calico
pods: 100.128.0.0/11, <PROVIDER-NODES/96>:ffff:1100::/108
nodes: 10.255.0.0/16, <PROVIDER/96>::/96
services: 100.72.0.0/13, <PROVIDER-NODES/96>:ffff:3300::/108
If this makes sense?
@philsbln to supports google method, we need to extend the pod CIDRs (i don't know if that's possible) as it is used to configure the
@AndreBorrmann is there a <PROVIDER/96>
required as it is replaced with CIDRs by a Webhook anyway? Maybe it makes sense to configurable this is something like the cloud profile or do you want to make it configurable on shoot level?
So what I could image looks something like
networking:
type: calico
nodes: 10.255.0.0/16, <PROVIDER_NODES>::/64
pods: 100.128.0.0/11, <PROVIDER_NODES_SUBASSIGN>
services: 100.72.0.0/13, <PROVIDER_SERVICE_RESERVATION>:ffff:3300::/108
In the end, this results in nodes==pods
and let the kube-controller-manager provide the actual values
@mganter I'm mainly referring to the shoot config. However, I'd rather like to be explicit in the configuration that would also enable the validation to verify whether there is a mismatch between hardcoded
cidrs and the provided
cidrs. Otherwise you may configure a cidr which is "surprisingly" overwritten by the cloud provider or you omit the configuration at all which is also kind of miss-leading I'd say.
How do you model Google's IPv6 deployment plan where each Node gets assigned a /96 from which the PODs running of these nodes need to be assigned?