client perfermance

[stevenhong127]

Operators often encounter issues with client rate limiting during runtime, but currently, the operator's startup parameters do not support the standard Kubernetes client rate limit configuration.

` {"level":"info","ts":"2024-08-08T05:46:51Z","msg":"Waited for 3.048082224s due to client-side throttling, not priority and fairness, request: GET:https://$ip443/apis/storage.alibabacloud.com/v1beta1"}

{"level":"info","ts":"2024-08-08T05:47:01Z","msg":"Waited for 12.848947521s due to client-side throttling, not priority and fairness, request: GET:https://$ip:443/apis/policy/v1"}

{"level":"info","ts":"2024-08-08T05:47:11Z","msg":"Waited for 3.848626518s due to client-side throttling, not priority and fairness, request: GET:https://$ip:443/apis/snapshot.storage.k8s.io/v1beta1"}

{"level":"info","ts":"2024-08-08T05:47:21Z","msg":"Waited for 13.69793034s due to client-side throttling, not priority and fairness, request: GET:https://$ip:443/apis/snapshot.storage.k8s.io/v1"}`

[f41gh7]

Hello, which operator version is it?

According to https://github.com/VictoriaMetrics/operator/pull/965 operator must use discovery API only for needed groups (prometheus montiroing).

[AndrewChubatiuk]

hey @stevenhong127 --client.qps and --client.burst args were added in v0.47.0 release

[f41gh7]

Overall client performance should be improved since next release.

General changes: 1) enable cache for resource Get requests 2) make less Update calls.

You still may see such log message at operator start-up. It's expected behavior for clusters with large amount of CRD objects.