rke: event_rate_limit option does not work as expected.

RKE version: 1.1.0 Docker version: (docker version,docker info preferred)

Operating system and kernel: (cat /etc/os-release, uname -r preferred) RancheOS Type/provider of hosts: (VirtualBox/Bare-metal/AWS/GCE/DO) VMware cluster.yml file:

    event_rate_limit:
      enabled: true
      configuration:
        apiVersion: eventratelimit.admission.k8s.io/v1alpha1
        kind: Configuration
        limits:
        - type: Server
          qps: 6000
          burst: 30000

Steps to Reproduce: Create an rke config file including the excerpt above and then create a cluster Results: Th kube-apiserver don’t start with the following error message :

W0403 09:53:24.972851 1 helpers.go:98] ignoring invalid key policy/v1beta1/podsecuritypolicy, individual resource enablement/disablement is not supported in policy/v1beta1, and will prevent starting in future releases Error: failed to initialize admission: couldn’t init admission plugin “EventRateLimit”: Object ‘Kind’ is missing in ‘{“limits”:[{“burst”:30000,“qps”:6000,“type”:“Server”}]}’ Usage: kube-apiserver [flags]

gz#16845

About this issue

  • Original URL
  • State: closed
  • Created 4 years ago
  • Reactions: 3
  • Comments: 15 (5 by maintainers)

Most upvoted comments

I have the same issue here, with RKE 1.1.0 and RancherOS 1.5.5.

As far as I can see, the problem is that RKE creates the file /etc/kubernetes/admission.yaml with the wrong configuration. When you set a custom configuration in rkeConfig file like this:

 event_rate_limit:
      enabled: true
      configuration:
        apiVersion: eventratelimit.admission.k8s.io/v1alpha1
        kind: Configuration
        limits:
        - type: Server
          qps: 6000
          burst: 30000

RKE creates this admission.yaml:

apiVersion: apiserver.k8s.io/v1alpha1
kind: AdmissionConfiguration
plugins:
- configuration:
    limits:
    - burst: 30000
      qps: 6000
      type: Server
  name: EventRateLimit
  path: ""

As you can see, it misses the Kind and ApiVersion parameters. But if you do not set a custom configuration

 event_rate_limit:
      enabled: true

then RKE creates a default admission.yaml, with the correct configuration:

apiVersion: apiserver.k8s.io/v1alpha1
kind: AdmissionConfiguration
plugins:
- configuration:
    apiVersion: eventratelimit.admission.k8s.io/v1alpha1
    kind: Configuration
    limits:
    - burst: 20000
      qps: 5000
      type: Server
  name: EventRateLimit
  path: ""

For now this can be a workaround, so that kube-apiserver can work properly without the need to disable EventRateLimit. If you need to change burst or qps parameters, you could do it manually in the admission.yaml of each master node, but RKE will change it everytime you do an upgrade.

Strange, this seems to be the case for Secrets Encryption too…

Using something like:

services:
  kube-api:
    secrets_encryption_config:
      enabled: true
      custom_config:
        apiVersion: apiserver.config.k8s.io/v1
        kind: EncryptionConfiguration
        resources:
        - resources:
          - secrets
          providers:
          - aescbc:
              keys:
              - name: k-fw5hn
                secret: RTczRjFDODMwQzAyMDVBREU4NDJBMUZFNDhCNzM5N0I=
          - identity: {}

In cluster.yaml and running with RKE through terraform outputs:

Failed to parse cluster config: error decoding data: Object 'Kind' is missing in '{"resources":[{"providers":[{"aescbc":{"keys":[{"name":"key","secret":"

Root cause

In the backend, the parsing for EventRateLimit is missing, so the applied configuration for EventRateLimit does not take effect.

What was fixed, or what changes have occurred

add the missing logic for parsing and applying the EventRateLimit

Areas or cases that should be tested

When the configuration is in the cluster.yaml, RKE should apply it to the cluster.

When setting the following configuration, the cluster is provisioned successfully, and the error reported in the issue doesn’t happen anymore.

  kube-api:
    event_rate_limit:
      enabled: true
      configuration:
        apiVersion: eventratelimit.admission.k8s.io/v1alpha1
        kind: Configuration
        limits:
          - type: Server
            qps: 6999
            burst: 29999

What areas could experience regressions?

no

Are the repro steps accurate/minimal?

yes