One case useful i can think of for now is for tcp headless service, we build one listener per pod instance. With the new version, we can build only one listener.

One case useful i can think of for now is for tcp headless service, we build one listener per pod instance. With the new version, we can build only one listener.

Hi @hzxuzhonghu, yeah, that's a good use case. However, we have to consider how to implement traffic route if the network session is stateful.

@hzxuzhonghu Are you sure the listener update is in-place? Otherwise, you're draining connections any time another endpoint stands up for a headless service.

I am not sure, i donot have a chance to look at that yet

It'd be strictly worse without support for delta updates for additional addresses. I haven't checked either. This is for headless sets, dual stack is a good idea.

For dual stack - clearly good idea.

I think for stateful sets it is also strictly better than what we have today.

For headless the XDS size is strictly better but there would be draining anytime any endpoint changes. Ive tested in #40409 (didn't test the drain though, just assumed)

Maybe Envoy can be optimized to not drain on multiple addresses if the only thing changing is removing/adding an address?

This should also be used for service VIPs for multi-cluster, to allow use of external dns servers. Right now we rely on DNS interception and there are limitations. Instead we should send the VIPs from all clusters.

Maybe I'm lost, but I think he's referring to

with the idea that dual stack Kubernetes clusters have 2 VIPs, one for IPv4 and IPv6 if a Service has both ipFamilies defined.

Thoughts @costinm and @howardjohn ? In the meeting it was suggested he could use

In-place listener update could handle multiple addresses, but the problem is that these listeners are using a poorly supported (and previously deprecated) option for non-binding addresses. It might be better to switch to using matchers for headless services, which will avoid any drain.

I generally agree, the only issue is we cannot just migrate headless services, we need to migrate everything, I think. Which we should/will do, just not a small effort

Hi all, thank you for all your comments, and thanks for John's PR#40409, I think it's a great example of using multi-addresses per listener for headless service. I understand that all these changes are not a small effort, however, let's brainstorm to make it happen. BTW, I drafted an initialized PR#40539, any idea?

headless and service entry support

Any other area that is lacking dual stack support in Istio sidecars?

One thing I could think of is integrate dual stack with ambient mesh?

headless and service entry support

Any other area that is lacking dual stack support in Istio sidecars?

One thing I could think of is integrate dual stack with ambient mesh?

Hi @linsun, headless and service entry are the 2 major areas need to be handled. And for Dual Stack support with ambient mesh, I think the single stack should be the first, especially IPv6 support should be okay, then Dual Stack. Does it make sense?

Hi @zhlsunshine yes, that makes sense, we'll need to support each single stack before dual stack. :)