fix: create IPv4 Service with ipFamily IPv4 on dual-stack, IPv6-first cluster

[michaelbeaumont]

What type of PR is this?
fix: create IPv4 Service with ipFamily IPv4 on dual-stack, IPv6-first cluster

What this PR does / why we need it:
The deleted comment isn't accurate. From Kubernetes docs:

The address family of a Service defaults to the address family of the first service cluster IP range (configured via the --service-cluster-ip-range flag to the kube-apiserver).

Which issue(s) this PR fixes:
Fixes #6389

Release Notes: Yes

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 70.70%. Comparing base (970cee1) to head (bff3ba8).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #6390      +/-   ##
==========================================
- Coverage   70.74%   70.70%   -0.04%     
==========================================
  Files         220      220              
  Lines       37096    37098       +2     
==========================================
- Hits        26243    26231      -12     
- Misses       9315     9325      +10     
- Partials     1538     1542       +4     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[arkodg]

thanks @michaelbeaumont, can you confirm if the fix and the configuration (ipFamily: IPv4) works in a IPv6 first cluster i.e. can the kubelet communicate successfully with the envoy pod, and set Ready=True ?

[michaelbeaumont]

Hmm, @arkodg no unfortunately. There's an issue with the health check not being accessible on IPv6 afaict. It seems like

gateway/internal/gatewayapi/listener.go

Lines 447 to 452 in 72c9065

	xdsIR.ReadyListener = &ir.ReadyListener{
	Address: address,
	Port: uint32(bootstrap.EnvoyReadinessPort),
	Path: bootstrap.EnvoyReadinessPath,
	IPFamily: ipFamily,
	}

needs to be tweaked in this case. Maybe it should always listen on all ip families allocated to the Pod, not just the ip family set in the EnvoyProxy