Can the number of calls to the k8s API server used for drift detection be reduced?

[Unveraenderbar]

Hello,
our platform provider is concerned about the volume of calls to the k8s API server that are performed by Flux.
As far as I understand, this comes simply from all k8s resources managed by the kustomization controller being
checked with the frequency specified in the .spec.interval attribute of the Kustomization CRs.
I suppose the rationale behind simply querying the state of all managed resources is that API server calls
are expected to be cheap.

This means the only way to reduce the API server request volume caused by the Flux kustomization controller is
to increase the reconciliation intervals, at the cost of weaker configuration drift detection.

The provider team also mentioned that ArgoCD uses the k8s informer API for drift detection, i.e. is getting
notified on resource state changes so it doesn't have to poll the API server.

Are there any plans to change the drift detection mechanism in the Flux GOTK?
Or are there any other ways to reduce the number of requests to the API server issued by the kustomization
controller for drift detection besides increasing reconciliation intervals?

[stefanprodan]

We have no plans on changing how drfit detection works. The interval on Flux Kustomization should be long enough to avoid DDOS-ing the API server, see: https://fluxcd.io/flux/components/kustomize/kustomizations/#recommended-settings

Flux is mean to run at scale with minimal resource usage, so we can not use informers like Argo, this would result in GB of RAM and huge amount of traffic as we'll end up watching everything that's in etcd.