Sizing
Limit Number of Groups for Performance Reasons:
Limit Number of Groups
The number of groups should be configured to what is necessary. Performance will degrade when there are many groups. This is especially true for translation API which is used by search. Ideally less than 25 groups should be used. However more groups will work, but you may have performance problems as this number of groups grows. At some point the number of groups will break the request payload size however and policy service will return a 413 or 400 error for translate API requests. This configuration error may break search. This can be seen when the number of groups is 1000+.
Policy Service Sizing
Info
Smaller CPU and memory requests sizes should work, however under load you may experience performance issues.
Memory
By default caching of OPA responses is turned on. With this feature on, recommended sizes : - minimum memory request for Policy Service should be 600Mi. - recommended memory request size for Policy Service is 1000Mi (or larger). It has been reported that 1200M and a minimum of 3+ pods works well under load. Some environments could require more memory.
CPU and Autoscaling
Horizontal Pod Autoscaling (HPA) is recommended and a cpu request size of at least 1000m is recommended. minReplicas should always be 3 or more in production environments or preship environments.
OPA Sizing
Info
Smaller CPU and memory requests sizes should work, however under load you may experience slow downs and other performance issues.
- For OPA minimum sizing cpu requests 500M, memory 256Mi and 2 pods.
- Recommended is 1000M CPU and 1000Mi RAM.
- Horizontal Pod Autoscaling (HPA) is recommended and minReplicas should always be 2 or more in production environments and pre-ship environments. It has been reported that 1000M CPU, 1000Mi Memory requests and a minimum of 3 pods works well under load.
- The number of OPA pods should be at least half the number of policy service pods. i.e. if you have 6 policy pods, you should have 3 OPA pods.