DNSPolicy targeting HTTPRoutes

[guicassolato]

By allowing DNSPolicies to target only Gateway objects, it's currently not possible to set Load Balancing rules for more specific hostnames specified only at the level of HTTPRoutes.

Sample use case

Given:

spoke cluster X:
  gw-a:
    listeners: [{hostname: *.a.com}]
  route-all:
    parentRefs: [gw-a]
    hostnames: [*.a.com]
  route-foo:
    parentRefs: [gw-a]
    hostnames: [foo.a.com]

spoke cluster Y:
  gw-a:
    listeners: [{hostname: *.a.com}]
  gw-b:
    listeners: [{hostname: *.b.com}]
  route-foo:
    parentRefs: [gw-a, gw-b]
    hosts: [foo.a.com, foo.b.com]

dns records:
  *.a.com → cluster IP X
  *.a.com, *.b.com → cluster IP Y

How can I declare load balance rules to split traffic between the two spoke clusters of requests sent to foo.a.com (other than the default 50%-50% round-robin one)? I want LB rules that are independent from any other LB rules I may have set for the complement in *.a.com.

Workaround

Current known workaround requires defining a new listener in the Gateway objects for the more specific hostname foo.a.com. I see 2 problem with this approach:

1. it doesn't scale well for a large number of routes
2. it may be perceived as a leakage of details of the routes to the more abstract level, partially defeating the purpose of the wildcard domain IMO

[maleck13]

I wonder is there a gap in policy attachment around hosts? So a targetRef can only target a single network resource, but a host can be shared across many network resources. For example 2 HTTPRoutes. If a policy does something at the host level (DNS for example) this becomes pretty complex.
Currently I think the safest place to define a policy against a host is the gateway as there would be no real advantage to having two gateways with the same set of hosts defined on a given cluster (at least none I can think of).
I wonder do we need an addition to policy attachment to say a policy can attach to a host and not just a resource containing the definition of the host. Perhaps sectionName could be extended to include hosts?

[guicassolato]

@maleck13,

I wonder do we need an addition to policy attachment to say a policy can attach to a host and not just a resource containing the definition of the host. Perhaps sectionName could be extended to include hosts?

We've added targeting a host (as another subsection of a HTTPRoute or Gateway resource one can target) to Kuadrant's route selectors.

E.g.: Say we have:

• route-foo(hosts: foo.io, foo.com, parentRefs: gw-io, gw-com)
• gw-io(host: *.io)
• gw-com(host: *.com)

One that targets route-foo(foo.io) sets a policy for all traffic to route-foo incoming through gw-io – not for traffic incoming through gw-com, nor for traffic through gw-io other than foo.io (e.g. not for bar.io.)

First conclusion I take from this is that hosts seems to be a section of the network topology – particularly of the part defined in the HTTPRoute – and therefore under sectionName if it becomes a thing.

Currently I think the safest place to define a policy against a host is the gateway

I don't see how the exemplified policy above should be defined at the gateway. We'd be asking the policy owner to go one level up (where required privileges are most likely not the same), to set a policy that only affects a subset of the network.

Placing it at the route is the right thing to do IMO. You are defining rules for a subset of the traffic that is directed to a particular service.

Maybe for the DNSPolicy the way to think this is not exactly the same as it only cares about hosts and not about other subsections that can be declared in a HTTPRoute, but I'll refer back to the description of this issue here, because I think targeting the route still makes sense.

One thing that these examples have in common is that the hosts to target are declared at the HTTPRoutes, not in the Gateways.

If a policy does something at the host level (DNS for example) this becomes pretty complex.

This is true and we've been dealing (or not dealing) with it at other kinds of policies as well, like auth. Today, we have to make assumptions about who "owns" the host whenever there's a conflict.

[maleck13]

First conclusion I take from this is that hosts seems to be a section of the network topology – particularly of the part defined in the HTTPRoute – and therefore under sectionName if it becomes a thing.

Right so that could be something we suggest to GWAPI. "A host is considered a "section" of the network and as such forms a natural boundary for policy. So a sectionName can be a host or named listener / route

[maleck13]

on conflict resolution. If we consider the host to be a section that can be targeted specifically or generically (regular target ref with no sectionName specified). It would seem like we could follow the rules but adjust them:

• directly targeting a host overrides any less specific policy for direct attachment
• policy targeting a host must form a single policy across all resouces at the same level. Example: two policies targeting foo.bar.com in HTTPRoutes (A and B) are targeting the host and not the resource and so are considered in conflict and so normal confict resolution happens (hierarchy, then oldest).

[philbrookes]

This issue is stale because it has been open for 60 days with no activity.

[philbrookes]

This issue is stale because it has been open for 60 days with no activity.

[philbrookes]

This issue was closed because it has been inactive for 30 days since being marked as stale.

[philbrookes]

This issue is stale because it has been open for 60 days with no activity.