DC-aware plugin configuration

[subnetmarco]

Whenever a plugin allows a target host (tcp-log, udp-log, rate-limiting, etc) in its configuration, there is currently no way to make it DC-aware. And since the plugin configuration is global, there is no way to override it per Kong node.

Example:

In a multi-DC environment, I have a Kong node in each DC and I have a logging server in each DC as well.

I want Kong nodes to send logs to the TCP server in the same DC to reduce latency. For example the tcp-log plugin executed by a Kong node in DC1 should send the logs to log.dc1, and the Kong node in DC2 should send the logs to log.dc2.

Today this is not possible, and every Kong node will have to send all the data either to log.dc1 or log.dc2, but cannot split the traffic.

Same can happen for the Galileo plugins, for the Rate-Limiting plugins (with redis policy`) and any other plugin that supports a third-party host of any kind in the configuration.

[Tieske]

One of the things I still have on the radar for loadbalancing is extending the ring balancer with an algorithm that auto-adjusts the weights based on network latency.

Idea would be to have a kong cluster over multiple DCs, including services in multiple DCs and each Kong node would route traffic to the locations with the lowest latency (which would be the local DC under normal circumstances)

Maybe a setup like that could also be used for the plugins you mentioned.

[subnetmarco]

Potential solution:

• Supporting an optional datacenter property in the Kong configuration file.
• Supporting optional DC aware overrides in the plugin configuration schema:

# kong.conf

datacenter = us-east

I can configure a plugin as usual:

http :8001/plugins name=tcp-log config.host=1.1.1.1

but optionally I can configure it with DC awareness:

http :8001/plugins name=tcp-log config.us-east.host=1.1.1.1

When the plugin is being executed, at runtime if there is a plugin configuration whose datacenter matches the datacenter value in the configuration file, then it will be used.

[subnetmarco]

@Tieske that would be neat, although latency is not always the case for DC-aware configurations. For example, security policies in the network might be a factor and a Kong node in DC2 cannot send logs to a logging server in DC1 because firewall, even in the edge-case when the latency would be lower.

[subnetmarco]

Another way which can be recommended is to leverage on DNS lookups with different DNS resolvers. Example:

A logging plugin can be configured to always log to tcp.log. Kong in different DCs will have different DNS resolvers (or /etc/hosts file) that will resolve tcp.log into the right IP address in each datacenter.