[valleedelisle]

Problem

The k8s_locker uses the default Kubernetes client rate limits inherited from rest.InClusterConfig():

• QPS: 5 requests/s
• Burst: 10 requests

In multi-replica gNMIc deployments, the lease-renewal goroutine and the peer-discovery watch (via EndpointSlices, added in #980) share the same rate-limited client. Under high-churn conditions or larger clusters, this causes API requests to be queued and delayed, which manifests as intermittent k8s_locker watch ended with error log spam — even when the API server itself is healthy.

Solution

Add two optional config fields to k8s_locker:

locker:
  type: k8s
  qps: 100    # max sustained requests/s to the Kubernetes API (default: unchanged)
  burst: 100  # max burst above QPS (default: unchanged)

When either field is zero or absent the in-cluster default is preserved, so the change is fully backward-compatible.

Changes

• pkg/lockers/k8s_locker/k8s_locker.go: two new optional fields (QPS float32, Burst int) in the config struct; conditionally applied to the rest.Config before the clientset is created.

Testing

Verified with go build and go vet against the current main. The existing locker tests continue to pass unchanged since zero values leave the defaults in place.

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[karimra]

Thanks for the contribution, clear and simple!