Kong plugin to expose upstream health as an endpoint.
The status of Kong health-checks is exposed through the status-api. But this is only for internal users to consume. This plugin can be used to expose the health of a loadbalancer (upstream entity) on an endpoint to Kong clients.
Why not expose the admin-api endpoint through Kong?
- it requires the admin-status api to be enabled
- forwarding an external route to the admin-api endpoint would increase the attack surface, since it opens an internal port for external traffic
- it would require the development team (creating the Kong config) to know infrastructure details (port on which the api is available), and those details to be the same for each Kong node in the cluster. Using this plugin enables the full functionality to be enabled by the development team without any knowledge of the infrastructure
To enable the plugin, create a route, for example on path "/healthcheck". Then configure the plugin on this path.
When invoked the plugin will;
- collect the currently active
serviceentity - from the
serviceit will collect thehost - it will lookup the
upstreamentity that matches thehostname - it will check the health status of the selected
upstream - it will return "200 Ok" if the upstream is healthy, or "503 Service Unavailable" if the upstream is unhealthy.
Good to know:
- it has a single configuration property;
upstream_name, if set, it will report the health of that specificupstreamentity, instead of the currently active one - it can only be configured on a
route(no service, nor consumer) - it will return a 500 (and log an error) if the
routedoesn't have aservice - it will return a 500 (and log an error) if the
hostdoesn't refer to anupstream
- change priority to 2400, to run right after
bot-detection, before any auth plugins. Such that health checks can be done unauthenticated.