Report single IP address for the node

[sharath-srikanth-chellappa]

Is your feature request related to a problem? Please describe:

cloud-provider-kubevirt, goes through all the interfaces and checks if the interface name is default and then gets the IP addresses and assigns this to the node.

However this is not favored in the case of IPV6, where all IPV6 addresses for the interface are reported including the EUI-64 interface. This is causing calico to flip-flop IPv6 node addresses in the internal BGP mesh leading to sporadic failures.

What we are proposing is as follows -

• For each IP version on the default interface we want to report a single IP address for each version.
• For the IPV4 address, we want to choose primary over secondary IP address (system assigned CIDR over ip addr a assigned secondary address)
• For the IPV6 address, we want a system assigned CIDR over a EUI-64 generated address, only falling back to IPv6 EUI-64 addresses when no other address is assigned
• Avoid reporting the fe80:.... IPv6 address ensuring there is only one IPv4, and IPv6 address.

Describe the solution you'd like:

Example on what happens today -
The kubernetes node returns the following:

Addresses:
  InternalIP:  10.145.189.14
  InternalIP:  2001:1b77:a00b:482:a8bb:ccff:fe91:9e27 <-- this is wrong
  InternalIP:  2001:1b77:a00b:482::c <-- this is right
  InternalIP:  fe80::a8bb:ccff:fe91:9e27 <-- we dont want this
  Hostname:    ccrc-vnf2-57a6efd3-agentpool1-md-v7k28

Also, as a tangent issue in the same boat, on VMs with kube-vip running, we see the secondary address for IPv4 as well.

Addresses:
  InternalIP:  10.145.189.10
  InternalIP:  10.145.189.9 <-- two IPv is not good
  InternalIP:  2001:1b77:a00b:482:a8bb:ccff:fe62:161a <-- this is wrong
  InternalIP:  2001:1b77:a00b:482::8 <--this is right
  InternalIP:  fe80::a8bb:ccff:fe62:161a <-- we dont want this
  Hostname:    ccrc-vnf2-57a6efd3-control-plane-zhgr5

Describe alternatives you've considered:

We haven't really considered any alternatives and are open to suggestions.

Additional context:

None

[kubevirt-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

/lifecycle stale