proposal: TrafficPolicy

[arkodg]

Description:
Introduce a hierarchical policy attachment called TrafficPolicy that can be applied to the Gateway and HTTPRoute / xRoute resources to further configure the traffic ingressing in which can be applied either for the downstream connection or upstream connection.

kind: TrafficPolicy
spec:
  default:
    downstream:
      keepalive: .....
    upstream:
      keepalive: .....
      cors:
      loadBalancer:
      tls:
  targetRef:
    kind: Gateway
    name: example

Relates to

• proposal: LoadbalancingPolicy #1105
• KeepAlive support #1031
• Support Route timeout And Cluster connect timeout configure #877
• support upstream tls #837
• Support Authentication Overrides and Defaults #731
• Enabling CORS for a HTTPRoute  #567
• Add Support for WAF #671
• Introduce a CRD for backend details #492
• Support downstream and upstream Proxy Protocol #1328

[arkodg]

ptal @envoyproxy/gateway-maintainers

[kflynn]

@AliceProxy and I have done some preliminary work on how Gateway API compares to the extant Emissary configuration language here, which might be relevant to this discussion.

[kflynn]

GEP-1897 is also worth noting.

[github-actions]

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

[arkodg]

in the community meeting yesterday, @AliceProxy brought up a great way to split up this API

• A Direct DownstreamTrafficPolicy API which can be applied only to the Gateway resource and holds downstream specific information applicable for the downstream listener
• A UpstreamTrafficPolicy API which can be applied to the Gateway resource as well as the xRoute resource.

Im a big +1 on this approach, here are some open issues that need more debate

• how do we deal with defaults and overrides when an UpstreamTrafficPolicy is applied to a Gateway as well a HTTPRoute that is attached to the same Gateway, which policy field wins ? Making this policy type a hierarchical policy attachment should solve this issue
• An UpstreamTrafficPolicy applied to a xRoute will get applied for all backends attached to the route. So properties such as upstreamProxyProtocol, loadBalancing, circuitBreaker, outlierDetection, retry cannot be applied to a specific backend. This issue maybe circumvented by creating multiple HTTPRoute to split up intent or even create PolicyAttachment per HTTPRoute rule which might be possible soon once Update TargetREf in Policy GEP kubernetes-sigs/gateway-api#2147 is completed

[kflynn]

@AliceProxy and I talked about this a bit offline, and I think it makes sense as well, FTR.

[arkodg]

closing this for now since we have the completed this epic by introducing 3 new APIs -

• ClientTrafficPolicy
• BackendTrafficPolicy
• SecurityPolicy