Push based Kubernetes support for informers as CRDs

[macsux]

Currently, actuators are nearly useless outside of Cloud Foundry because they have "bring your own security" model, which few are willing to tackle. Also, some endpoints are very specific to container instances (/health) which makes it awkward to request this when running behind load balancer, as you need special tricks to target specific instance. They also require app to be exposed over HTTP and have a route to be useful, which is suboptimal for worker type apps.

Instead the proposal is to extend this functionality to instead PUBLISH the state of some actuators into Kubernetes as CRDs when app is running in Kubernetes. This would enable use of standard tools to query actuators, solve for security model (as it would inherit Kubernetes security), and not require routes. The following actuators can be converted to push their state into the Kubernetes cluster: /env /health /info /mappings /loggers maybe not needed? Additionally, with the use of Kubernetes config provider, the need for loggers endpoints may not be needed as it can just read logging configuration directly from ConfigMap of the cluster and refresh it in realtime when it changes due to ability to monitor changes to Kubernetes resources.

/refresh endpoint is only useful when dealing with spring cloud config server, since file and Kubernetes providers refresh themselves when changes are tected. It's also mostly broken because the request is directed against a single container instance - for it to be actually useful it needs the equivalent of /refresh-bus feature found in Spring which will make EVERY instance refresh itself. This can be solved easily if Kubernetes config provider is in use. In that case one can simply establish a watch on to the specific key that is used as refresh trigger (ex. spring:cloud:config:lastUpdateTimestamp) which can be incremented manually by user to trigger a refresh or automatically by Kubernetes controller when it detects that config provider changed (ex. git pull every minute, if new commits -> update timestamp in ConfigMap).

[TimHess]

One bit of functionality that I think is interesting about /loggers that seems like it would disappear here is the ability to list loggers and their current configuration. I'm not sure that's essential functionality, but it is nice to be able to confirm that a logger is running at the level I think it should be

[macsux]

You can totally report it back into CRD. It would have to be a custom object though instead of config map to support "status".

On Thu, May 21, 2020 at 2:23 PM Tim Hess [email protected] wrote:

One bit of functionality that I think is interesting about /loggers that seems like it would disappear here is the ability to list loggers and their current configuration. I'm not sure that's essential functionality, but it is nice to be able to confirm that a logger is running at the level I think it should be

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/SteeltoeOSS/Steeltoe/issues/333#issuecomment-632266440, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAINFWDZSQOOKO6HNSBFMADRSVWRJANCNFSM4NGGNZKQ .

[macsux]

I actually think it would make sense to merge that with /env, as logger configuration is very much related to the current state of configuration of the app.

On Thu, May 21, 2020 at 2:24 PM Andrew Stakhov [email protected] wrote:

You can totally report it back into CRD. It would have to be a custom object though instead of config map to support "status".

On Thu, May 21, 2020 at 2:23 PM Tim Hess [email protected] wrote:

One bit of functionality that I think is interesting about /loggers that seems like it would disappear here is the ability to list loggers and their current configuration. I'm not sure that's essential functionality, but it is nice to be able to confirm that a logger is running at the level I think it should be

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/SteeltoeOSS/Steeltoe/issues/333#issuecomment-632266440, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAINFWDZSQOOKO6HNSBFMADRSVWRJANCNFSM4NGGNZKQ .

[TimHess]

Closing due to lack of interest. If you would like to see this supported, please respond to this issue