beeme1mr
commented
2 years ago Hey @AlexsJones, thanks for putting this together! I'm very interested in this because near real-time updates are important for a number of use cases including using feature flagging as a circuit breaker or for problem remediation.
Do you know how much stress this will put on the API server? I would expect a watcher to be computationally inexpensive but that just an assumption. If necessary, it may be possible to use a proxy to reduce the load on the API server itself. It would also be possible to run FlagD as a daemon or service if we need to reduce the number of active connections to the API server.
Do you know what architectures would no longer be supported if we used the Kubernetes Golang bindings?
AlexsJones
FlagD is often used in the context of Kubernetes.
It is typically deployed by OFO as a companion sidecar and uses a volume injected via configmap as the source of its flags to evaluate.
I propose there may be a more optimal way to enable faster refreshing on flag changes by subscribing to a notifier against the Kubernetes API. This is inspired by this discussion with @therealmitchconnors and also the regression in being able to trigger configmap volume reloads through updating annotations within a deployment.
This is not a silverbullet and I think for academic purposes alone it is worth exploring if we would want to move in this direction. The only real benefit here is speed of flag updates.
Design
FlagD would start with the typical arguments of
flagd start --sync-service kubernetes-apior something similar. This would use the token mounted from/var/run/secrets/kubernetes.io/serviceaccountto request to watch events for the FeatureFlagConfiguration. The FeatureFlagConfiguration could be determined by the pod getting its own annotations on start through the API and performing a look-up.Benefits
Caveats