feat(admission-controller): separate CPU/Memory requests and limits for Auto-Instrumentation Init Containers#41048
Conversation
…or auto-instrumentation init containers Add support for separate CPU/Memory requests and limits for auto-instrumentation init containers using new environment variables: - DD_ADMISSION_CONTROLLER_AUTO_INSTRUMENTATION_INIT_REQUESTS_CPU - DD_ADMISSION_CONTROLLER_AUTO_INSTRUMENTATION_INIT_REQUESTS_MEMORY - DD_ADMISSION_CONTROLLER_AUTO_INSTRUMENTATION_INIT_LIMITS_CPU - DD_ADMISSION_CONTROLLER_AUTO_INSTRUMENTATION_INIT_LIMITS_MEMORY This resolves OOMKilled issues while maintaining scheduling efficiency by allowing low requests for scheduling and higher limits for initialization spikes. Fixes DataDog#38831
30be358 to
b66f82c
Compare
Replace BindEnv with BindEnvAndSetDefault for admission controller auto-instrumentation init container resource configurations to provide explicit types and default values as requested in code review. Signed-off-by: puretension <rlrlfhtm5@gmail.com>
|
Hi @hush-hush! Thank you for approving the PR 🙏 There's a conflict in |
|
|
||
| // If neither requests nor limits are configured, use auto-calculation | ||
| if _, hasReq := conf.requests[k]; !hasReq { | ||
| if _, hasLim := conf.limits[k]; !hasLim { |
There was a problem hiding this comment.
This only auto-calculates when BOTH requests AND limits are missing. What if user only sets one value? Can you clarify in the comment or doc for this case.
| // We don't support other resources | ||
| requirements.Limits[k] = maxPodLim | ||
| } | ||
| if maxPodReq, ok := podRequirements.Requests[k]; ok { |
There was a problem hiding this comment.
Should we move this part outsides of current !hasLim condition?
Address zhuminyi's review feedback: - Remove nested conditions that only auto-calculated when BOTH requests AND limits were missing - Move requests processing outside of !hasLim condition to handle them independently - Now each resource (requests/limits) is auto-calculated independently when not configured This allows users to set only requests OR only limits, with the other being auto-calculated. Signed-off-by: puretension <rlrlfhtm5@gmail.com>
|
Thank you for the sharp feedback @zhuminyi.
This makes the behavior much clearer and more flexible for users who want to configure only one of the two values. |
What does this PR do?
Adds support for separate CPU/Memory requests and limits for auto-instrumentation init containers by introducing 4 new environment variables:
DD_ADMISSION_CONTROLLER_AUTO_INSTRUMENTATION_INIT_REQUESTS_CPUDD_ADMISSION_CONTROLLER_AUTO_INSTRUMENTATION_INIT_REQUESTS_MEMORYDD_ADMISSION_CONTROLLER_AUTO_INSTRUMENTATION_INIT_LIMITS_CPUDD_ADMISSION_CONTROLLER_AUTO_INSTRUMENTATION_INIT_LIMITS_MEMORYThis allows independent configuration of requests (for scheduling) and limits (for initialization spikes), while maintaining backward compatibility with existing
DD_ADMISSION_CONTROLLER_AUTO_INSTRUMENTATION_INIT_RESOURCES_*variables.Motivation
Fixes #38831
The current implementation forces
requests = limitsfor auto-instrumentation init containers, leading to:Related issues:
Describe how you validated your changes
TestSeparateRequestsAndLimitsto verify configuration parsing and validation logicTestSeparateRequestsAndLimitsIntegrationto test actual pod injection scenarioslimits ≥ requestsvalidation with clear error messagesTest coverage includes:
Additional Notes