fix: reject --kube-api-qps without --kube-api-burst at startup

[DsThakurRawat]

Description

cmd/main.go copied --kube-api-qps and --kube-api-burst into the rest config as given. Both default to -1, which disables client-side throttling, but a positive QPS with the burst left at -1 is a pair client-go refuses: kubernetes.NewForConfig fails with "burst is required to be greater than 0 when RateLimiter is not set and QPS is set to greater than 0", and a controller-runtime client built from the same config fails every request with "rate: Wait(n=1) exceeds limiter's burst -1". The controller exited with the clientset message, which names neither flag, and the Helm chart renders that pair whenever only controller.kubeAPIQPS is set.

This validates the pair right after flag.Parse and exits with a message that names both flags:

ERROR	setup	invalid flags	{"error": "--kube-api-burst must be greater than 0 when --kube-api-qps is set (got --kube-api-qps=50 --kube-api-burst=-1)"}

The defaults and any pair with a positive burst are unchanged. A burst on its own is still accepted and ignored, as before.

Related Issue

Fixes #465

Type of Change

/kind bug

Testing

• New TestValidateKubeAPIFlags in cmd/main_test.go covers the disabled defaults, both flags set, QPS with the default burst, QPS with a zero burst, burst on its own, and a zero QPS.
• Built the binary from this branch and ran it against a fake API server: --kube-api-qps=50 alone exits 1 with the message above; --kube-api-qps=50 --kube-api-burst=100 and the plain defaults start the manager as before.
• make test and make lint pass locally.

This PR was written in part with the assistance of generative AI; the failure was reproduced against the real binary and the change was reviewed and tested by hand.

Checklist

• make test passes
• make lint passes

Does this PR introduce a user-facing change?

The controller now exits at startup with a clear message when --kube-api-qps is set without a positive --kube-api-burst, instead of failing later with a client-go error that names neither flag.

[netlify]

✅ Deploy Preview for node-readiness-controller canceled.

Name	Link
🔨 Latest commit	805187a
🔍 Latest deploy log	https://app.netlify.com/projects/node-readiness-controller/deploys/6aa60e9511a40100088b4886

[kubernetes-prow]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: DsThakurRawat
Once this PR has been reviewed and has the lgtm label, please assign mrunalp for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[kubernetes-prow]

Hi @DsThakurRawat. Thanks for your PR.

I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work.

Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.