When eventRecordQPS is set to 0, the actual QPS is 5

[alex-matei]

What happened?

When setting eventRecordQPS or eventBurst to 0 in KubeletConfiguration the documentation states that no limit is enforced. What happens instead is that eventRecordQPS has the same meaning as "event-qps" kubelet flag. The value is used directly: https://github.com/kubernetes/kubernetes/blob/330b5a2b8dbd681811cb8235947557c99dd8e593/cmd/kubelet/app/server.go#L597

The kubernetes client-go API interprets the value of 0 as DefaultQPS which is 5. The same thing applies to eventBurst as well.

What did you expect to happen?

There should be no limit when the values are set to 0.

How can we reproduce it (as minimally and precisely as possible)?

Set eventRecordQPS/eventBurst to 0 in KubeletConfiguration.

Anything else we need to know?

No response

Kubernetes version

```console $ kubectl version # paste output here ```

Cloud provider

OS version

```console # On Linux: $ cat /etc/os-release # paste output here $ uname -a # paste output here # On Windows: C:\> wmic os get Caption, Version, BuildNumber, OSArchitecture # paste output here ```

Install tools

Container runtime (CRI) and version (if applicable)

Related plugins (CNI, CSI, ...) and versions (if applicable)

[HirazawaUi]

/sig node /assign

[HirazawaUi]

/sig api-machinery

[HirazawaUi]

It is worth mentioning that eventBurst is only used when eventRecordQPS > 0, and it should not exceed eventRecordQPS, so it cannot be set to 0

[pacoxu]

I tested eventRecordQPS with 0 like below.

[root@paco-centos-9 ~]# curl -k --key /etc/kubernetes/pki/apiserver-kubelet-client.key --cert /etc/kubernetes/pki/apiserver-kubelet-client.crt https://127.0.0.1:10250/configz | jq .kubeletconfig | grep event
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  2886  100  2886    0     0  28019      0 --:--:-- --:--:-- --:--:-- 28019
  "eventRecordQPS": 0,
  "eventBurst": 100,
[root@paco-centos-9 ~]# cat /var/lib/kubelet/config.yaml | grep event
eventRecordQPS: 0

https://github.com/kubernetes/kubernetes/blob/20fc8a939c3394bd31edd06a893b75d1c312e27c/staging/src/k8s.io/kubelet/config/v1beta1/types.go#L206-L218

*int32 type configuration can set to 0 and the default value will be applied only if it is nil. But for int32 type, the defaulting behavior will be weird to replace 0 with the default value. This is why the eventBurst is 100 even we set it to 0.

https://github.com/kubernetes/kubernetes/blob/20fc8a939c3394bd31edd06a893b75d1c312e27c/pkg/kubelet/apis/config/v1beta1/defaults.go#L98-L103

[root@paco-centos-9 ~]# cat /var/lib/kubelet/config.yaml | grep event
eventRecordQPS: 0
eventBurst: 0
[root@paco-centos-9 ~]# curl -k --key /etc/kubernetes/pki/apiserver-kubelet-client.key --cert /etc/kubernetes/pki/apiserver-kubelet-client.crt https://127.0.0.1:10250/configz | jq .kubeletconfig | grep event
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  2886  100  2886    0     0  31714      0 --:--:-- --:--:-- --:--:-- 32066
  "eventRecordQPS": 0,
  "eventBurst": 100,

[alex-matei]

Ok, got it, so the behavior for eventBurst is to be expected. The problem still remains with eventRecordQPS, even when set to 0 it's meaning is completely different because 0 in client-go is treated as "use default value": https://github.com/kubernetes/kubernetes/blob/f28e9f6f45974909968216cf4cc8872b72170335/staging/src/k8s.io/client-go/rest/config.go#L114-L116

This behavior matches what is documented when passing 0 for "--event-qps" command line flag, but doesn't respect the "no limit enforced" for eventRecordQPS config in KubeletConfiguration. Both cases write in the same variable which is passed that to the rest client in client-go.

[cici37]

/remove-sig api-machinery

[pacoxu]

@alex-matei should we close it as this is expected?

[alex-matei]

I think we should first merge the PR from @HirazawaUi, before closing the issue. As it is right now there is a mismatch between what is written in documentation for eventRecordQPS in KubeletConfiguration and the actual behavior. (I thought that eventRecordQPS set to 0 means unlimited and when looking through the kubelet logs I saw throttling messages related to events.)

[mmiranda96]

/triage accepted

[k8s-triage-robot]

This issue has not been updated in over 1 year, and should be re-triaged.

You can:

• Confirm that this issue is still relevant with /triage accepted (org members only)
• Close this issue with /close

For more details on the triage process, see https://www.kubernetes.dev/docs/guide/issue-triage/

/remove-triage accepted

[HirazawaUi]

/triage accepted