3 ms·
This is great feedback. I'm still on the fence about a watch mode for the following reasons: 1. The template configmap will not change as often as the secrets
by kelseyhightower 10y ago
This is great feedback. I'm still on the fence about a watch mode for the following reasons:
1. The template configmap will not change as often as the secrets and configmap key/value pairs they reference. This means you'll always need a sync loop to regenerate the template and compare it with the current generated version. This is how most configuration management systems work. Maybe we can watch the data and uses changes as triggers?
2. Watch is a bit racy when a template references multiple secrets and configmaps. It's really hard to prevent a partial config. One idea is to scale the konfd replicaset to 0 before making changing a bunch of secrets and configmaps, then scaling konfd back to 1 to trigger the processing of the templates to pick up the new values. The other option is to wait the "sync-interval", but you'll run the risk of partial configs or needing multiple runs to generate the complete config.
One possible solution to prevent 1 and 2 is to only reference one external configmap or secret for each template resource. I'm still testing these patterns in real life and will update the docs on which patterns work best for each situation. With that said, I think I'll still add a watch mode so others can test and provide feedback.
- andrewstuart2 10y agoThe second one has plagued me with a couple kubernetes clients I've written, but something about your restatement of the problem struck me with (IMO, of course) a nice idiomatic solution: a "debounce" fan-in (ish) channel between the ResultChan() and consumer that bundles up watch notifications after some configurable wait period. And actually, it's a common enough use case (I'd definitely use it too) that I'll bet it would be useful to have in client-go itself. And secondly, I would love to see this kind of concept upgraded to a first-class citizen in kubernetes. Essentially, I think an equivalent of `/etc/environment` for your cluster would be a powerful way of generalizing app components. It would be great if just placing resources in your cluster allows them to pick up at least some of their required configuration, much like customizing `/etc/environment` does for *nix machines.