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,
1
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.