Closed jchauncey closed 7 years ago
Would it be reasonable to run a single telegraf pod specifically configured to poll and API server? My rationale behind this alternative strategy is that setting up and maintaining leader election to poll the API server adds a lot of complexity for a single feature, and it would be a win if we can get away with not doing it for now.
Potentially but taht means we have a completely different telegraf manifest for polling the api server
IMO that'll still be a lot less overall complexity. That'd mean there was a RC for just the kube API telegraf (deis-monitor-telegraf-kube-api
) and then the already existing daemonset
Ok after some spiking this ended up not being worth it (using k8s leader election). Basically the problem we had was that we could determine a leader but if that leader ever went away we were not polling to find a new leader.
Going to keep investigating a better way to handle this
When we implement the solution in #139 this will not be an issue
If we can determine a leader within the telegraf pod it will allow us to only poll the api server from 1 pod which cuts down on traffic and memory stress for the api server.
Thoughts are to use something like this - http://blog.kubernetes.io/2016/01/simple-leader-election-with-Kubernetes.html