Feature Request: Support multiple ClusterCIDRs

[aojea]

Kubernetes is going to implement a feature to support Multiple ClusterCIDRs https://github.com/kubernetes/enhancements/tree/master/keps/sig-network/2593-multiple-cluster-cidrs

The feature doesn't consider PodIP renumbering, is always about assigning PodIP ranges to nodes.

Flannel can use the pod.Status.PodCIDR field for the Node IPAM, that will work great with this new feature, because that field is going to be populated by the new IPAM controllers.

However, it seems flannel depends on its own configuration field, Network, to define the pod subnet on the node (it seems it install some iptables rules, ...)

From the top of my head, in order to support this new feature, there are different options:

• this Network field should be able to allow multiple subnets
• add a new Networks field that allows multiple subnets
• consume the new API ClusterCIDRConfig directly, so no need to use the Network field
• remove the need of configuring the Network parameter at all, as we did with kube-proxy https://github.com/kubernetes/enhancements/tree/master/keps/sig-network/2450-Remove-knowledge-of-pod-cluster-CIDR-from-iptables-rules , using other heuristics to detect the pod network
• ...

[aojea]

cc @manuelbuil @szuecs

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[rbrtbnfgl]

I left this open. multicluster CIDR should be implemented on v0.21.0

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[thomasferrandiz]

Implemented already

[aojea]

@thomasferrandiz I have to apologize in advance but the SIG Network has decided to remove this ClusterCIDR feature from the kubernetes core, that means that this feature will not be available in Kubernetes core https://groups.google.com/g/kubernetes-sig-network/c/nts1xEZ--gQ/m/2aTOUNFFAAAJ , however, do we plan to provide the same functionality using a CRD.

Please let us know if is ok to completely remove the feature in 1.29, it has to be enable explicitly right now as it is alpha and featuregated, so we may assume is not widely used, but we don't want to create much disruption on the projects.

[rbrtbnfgl]

Hi @aojea no issue on our side it's only a flag that has to be explicitly enabled. If the plan is to remove it we'll follow the same plan on the next releases.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.