Improve port handling in Istio SetMirrorRoute

[RunlinXiao]

Summary

Currently SetMirrorRoute does not support port matching. When the service have multiple routes defined in trafficRouting. istio. virtualService. routes, it will implicitly pick the first route's port as the port for the mirror route, which might not be the port that the mirror route is serving on. (also see: #4159)

Proposed solution:

• Add optional port field to RouteMatch: Extend the RouteMatch struct to include an optional Port field, enabling users to configure mirror routes that match traffic based on destination port. This aligns SetMirrorRoute capabilities with the existing TLS and TCP route matching features, and leverages Istio's native HTTP match port support.
• Add validation for heterogeneous port configurations: Update the createMirrorRoute function to detect and fail when multiple route destinations use different ports, rather than silently using the first destination's port. The current behavior (code below) assumes port homogeneity across all destinations and implicitly selects route[0].Destination.Port without validation, which can lead to misconfiguration and difficult-to-diagnose routing failures in multi-port scenarios.

	if len(route) >= 0 && route[0].Destination.Port != nil {
		// We try to pull the port from any of the routes destinations that are supposed to be updated via SetWeight
		mirrorDestinations.Port = &Port{Number: route[0].Destination.Port.Number}
	}

Use Cases

Port-based route matching:

• Protocol separation: In microservices architectures where different ports serve different protocols or API versions, operators may want to mirror traffic selectively by port (e.g., mirror only gRPC traffic on port 9090, not REST API traffic on port 8080).

Port validation and error prevention:

• Complex routing topologies: In environments with heterogeneous destination configurations where routes target services on different ports, the current silent port selection can cause mirror traffic to be sent to incorrect ports, resulting in connection failures or routing to unintended endpoints.
• Operational safety: By failing fast with a clear error message when port conflicts are detected, operators receive immediate feedback during rollout configuration, rather than discovering routing issues during production deployments through monitoring alerts or user reports.

Note: I encountered this issue where mirror traffic was silently routed to the wrong port, resulting in connection failures that were very difficult to debug and reproduce without reading the code due to the implicit behavior. I'm interested in contributing a fix if this enhancement is approved.

---

Message from the maintainers:

Need this enhancement? Give it a 👍. We prioritize the issues with the most 👍.