Hacker News Reader

Comment by gabrtv | Hacker News Reader

More great stuff from Kelsey...

My tldr; konfd writes out k8s configmaps based on other k8s resources like secrets, configmaps, etc. Really useful for writing out complete config files into a pod namespace without relying on external config backends.

Question: While looping on a syncInterval is certainly clean and understandable, it feels suboptimal when all the templates sources are themselves watchable with a k8s client. Benefits of switching to a watch model:

1. Speed: It'd be nice to have the template rendering fire immediately after a source secret changed versus waiting for syncInterval.

2. Resource Utilization: Switching from syncInterval to a watch should save significant cycles by avoiding reprocessing templates when config hasn't changed.

View on HN

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.

The 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.

Reply on news.ycombinator.com