Pluralize backendRefs for non xRoute BackendRef

[arkodg]

non xRoute backendRef may need to be pluralized in case we want to handle Active / Standby cases. These are

• OpenTelemetry refactor telemetry backendRefs #3293
• ext auth ext_auth support backendRefs #3469
• ext proc feat(translator): Envoy Extension Policy and ExtProc #2991

Originally posted by @arkodg in #3055 (comment)

[arkodg]

ptal @envoyproxy/gateway-maintainers

[guydc]

+1

[arkodg]

some more thoughts

• if we care only about the active and passive use case, another backupBackendRef will suffice
• If we also want traffic splitting, we'll have to pluralize backendRef

[arkodg]

+1 for this

[zhaohuabing]

I think it's valid for non-k8s deployments, but not necessarily for k8s environment because you normally won't deploy two services for ext auth/ext proc/Telemetry.

[arkodg]

@zhaohuabing even for the K8s there could be a Service local in the cluster and another Service ( on standby ) in another cluster represented as a ServiceImport

[zhaohuabing]

Yah, falling back to a remote cluster is a very persuasive case for me. +1 for this!

[zirain]

for OpenTelemetry,

1. accesslog and metric support multi sinks
2. tracing only support one backend

[arkodg]

@zirain this is more about endpoint routing for a single request - traffic spitting and priority, rather than sending multiple requests to multiple sinks

[Alice-Lilith]

+1

[kflynn]

This seems like a good idea, let's do it. 👍

[github-actions]

This issue has been automatically marked as stale because it has not had activity in the last 30 days.

[shawnh2]

@zirain is this finished?

[arkodg]

@zirain afaik we havent yet implemented backendRefs for extAuth, so reopening this issue

[zirain]

@zirain afaik we havent yet implemented backendRefs for extAuth, so reopening this issue

It's done in #3469 or you want to remove the limitation of maxItems=1?

[zirain]

I think we can close it now, and create another one to track multi backends for ext_auth.