how can i control the number of events a namespace can save?

I want to control the number of events my tenants can create.

My ttl is 1 our, and that ok, but sometimes we have spikes in several namespaces and i am worry about etcd getting flouted if it happens in several namespaces.

I have tried to use resource quotas like this:

apiVersion: v1
kind: ResourceQuota
metadata:
  creationTimestamp: "2024-09-16T04:54:44Z"
  name: compute-resources
  namespace: test-dev
  resourceVersion: "35872662"
  uid: 78d46d9b-9b1d-435d-88c2-0cfd6f61c64c
spec:
  hard:
    count/events: 1k
status:
  hard:
    count/events: 1k
  used: 
  # i dont see it here

But it doesn't seem to work.

Is there any way to make it work with a Resource Quota? or i need to create web hook?

Thanks,

Solution

There is no direct way to limit event resources using Resource Quotas because events are not considered as quota managed resources.

A resource quota, defined by a ResourceQuota object, provides constraints that limit aggregate resource consumption per namespace. It can limit the quantity of objects that can be created in a namespace by type, as well as the total amount of compute resources that may be consumed by resources in that namespace.

See this Medium blog by Anvesh Muppeda and kodekloud blog about Hands-On Guide to Kubernetes Resource Quotas ,Limit Ranges and how to collect kubernetes events.

Resource Quotas in Kubernetes allow administrators to set constraints on the total resource usage per namespace. By using Resource Quotas, you can limit the number of resources such as Pods, CPU, and memory that can be consumed within a namespace.

You can use an admission webhook to capture event creation requests. You can also check the number of events already present in a namespace.

Admission webhooks are HTTP callbacks that receive admission requests and do something with them. You can define two types of admission webhooks, validating admission webhook and mutating admission webhook. Mutating admission webhooks are invoked first, and can modify objects sent to the API server to enforce custom defaults. After all object modifications are complete, and after the incoming object is validated by the API server, validating admission webhooks are invoked and can reject requests to enforce custom policies.