是否可以使用新的 https://gateway-api.sigs.k8s.io/ 通过多个后端链接请求？
这个想法是根据每个服务的响应标头建立一个流程，即：
请求 -> 网关 -> [第一个后端服务“自定义转发标头” -> 第二个后端服务 -> “自定义转发标头” -> x 服务 ] -> 响应
在 Kubernetes Gateway API 的上下文中，它通常设计为通过各种网关（例如 HTTPRoute、TCPRoute 等）有效管理inbound 请求流量。
这个问题更多的是关于管理东/西流量——即同一 Kubernetes 集群内的服务之间流动的流量。
这应该可以通过服务网格实现：利用Istio或Linkerd等服务网格可以提供更复杂的路由功能，包括基于标头的条件路由。
这是 GAMMA 计划 的一部分，该计划仍在进行中。
与此同时，Pubedu Gunatilaka（WSO2 高级技术主管）的“Kubernetes 上 API 网关的未来”（2023 年 8 月）指出：
2022 年，Envoy 的创建者Matt Klein推出了一个名为 Envoy Gateway 的新项目，专门针对 API 网关。
Envoy 已经拥有构建 API 网关所需的组件，包括代理层；用于网络流量过滤、路由和处理的可配置过滤器架构；以及用于将数据传输到 Envoy 代理的 xDS API。
开源 Envoy Gateway 项目添加了一个管理层来将 Envoy 代理作为独立网关或 Kubernetes 管理的 API 网关进行处理。
您不需要 Envoy 网关，但是，正如 Debasree Panda 在“什么是 Envoy 网关，为什么 Kubernetes 需要它？”中所证实的那样：
Envoy 代理，Istio 服务网格的数据平面，用于处理东西向流量（数据中心内的服务到服务通信）
因此，您应该能够实现您的用例，例如使用 LUA 过滤器 /
headers()