Setup:
Istio with setup based on https://istio.io/latest/blog/2023/egress-sni/ to support routing egress traffic to wildcard destinations
 

•  Original (leaky) egress gateway pod:
  • Image: registry.redhat.io/openshift-service-mesh/istio-proxyv2-rhel9@sha256:40be785b9abecd641f3121855a066c0ea01aba66e1350f33d175f2351c54e371
  • Envoy: a778f0d451768a9e0935ad81ed31d993d834383a / 1.35.7-dev / 3.2.0 / RELEASE / OpenSSL
• Reference (non-leaky) egress gateway pod:
  • Image: docker.io/istio/proxyv2:1.27.3-debug
  • Envoy: e87e0a25e2b62557bb6af418a67078f525f1711e / 1.35.6-dev / Clean / RELEASE / BoringSSL

 
At the beginning of the test session, test pods were created to produce constant-rate egress traffic towards various *.wikipedia.com destinations.
 
On the image, you can see memory consumption (container_memory_rss) for egress gateways.
At 1. a single egress gateway pod was created/configured to route the test traffic using the "Original (leaky)" image. It was leaking memory at a constant rate, as can be seen on the image. At 2., the test-pods producing the traffic were terminated. Memory consumption growth stopped, and remained constant at ~800MB.
At 3., the original leaky egress gateway was replaced with a gw using the "Reference (non-leaky)" upstream istio image, and the same test-pods were brought back up to produce the same egress traffic at the same rate as before. As can be seen on the image, this egress gateway had no memory leakage, with a constant memory use of about 7
The issue seem to be present on all ossm/istio versions. Other teams reported the same problem even with istio 1.20 (ossm 2.x).

Initial discussion on slack: https://redhat-internal.slack.com/archives/C01R9E3SFEV/p1763405471007339