Skip to content

Conversation

@puretension
Copy link

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_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 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 = limits for auto-instrumentation init containers, leading to:

  • Over-provisioned init containers: Bad for scheduling, especially with large/complex pods
  • Under-provisioned init containers: Risking OOM or throttling during library initialization

Related issues:

Describe how you validated your changes

  1. Unit Tests: Added TestSeparateRequestsAndLimits to verify configuration parsing and validation logic
  2. Integration Tests: Added TestSeparateRequestsAndLimitsIntegration to test actual pod injection scenarios
  3. Backward Compatibility: All existing tests pass, confirming legacy environment variables still work
  4. Validation Logic: Implemented and tested limits ≥ requests validation with clear error messages

Test coverage includes:

  • Separate requests/limits configuration
  • Legacy configuration (requests = limits)
  • Auto-calculation fallback
  • Validation error cases

Additional Notes

  • Backward Compatible: Existing configurations continue to work unchanged
  • Priority Logic: New variables → Legacy variables → Auto-calculation
  • Kubernetes Best Practices: Aligns with standard requests ≠ limits pattern
  • Release Note: Added comprehensive reno release note explaining the new feature

…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
@puretension puretension force-pushed the feat/separate-init-container-requests-limits-38831 branch from 30be358 to b66f82c Compare September 18, 2025 14:36
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 <[email protected]>
@puretension puretension changed the title feat(admission-controller): separate CPU/Memory requests and limits f… feat(admission-controller): separate CPU/Memory requests and limits for Auto-Instrumentation Init Containers Oct 28, 2025
@puretension
Copy link
Author

Hi @hush-hush! Thank you for approving the PR 🙏

There's a conflict in pkg/config/setup/config.go that needs to be resolved.
Would it be okay if I resolve the conflict?


// If neither requests nor limits are configured, use auto-calculation
if _, hasReq := conf.requests[k]; !hasReq {
if _, hasLim := conf.limits[k]; !hasLim {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 <[email protected]>
@puretension
Copy link
Author

puretension commented Oct 28, 2025

Thank you for the sharp feedback @zhuminyi.
I've updated the logic to handle requests and limits independently:

  • Previously the nested conditions only auto-calculated when BOTH were missing, but now each resource is handled separately. If a user sets only requests, limits will be auto-calculated, and vice versa.
  • I also moved the requests processing outside of the !hasLim condition as you suggested, so they're now processed in completely independent blocks.

This makes the behavior much clearer and more flexible for users who want to configure only one of the two values.
Please let me know if you spot any other issues or edge cases I should consider.

@wdhif wdhif removed the team/container-platform The Container Platform Team label Nov 24, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Separate CPU/Memory Requests and Limits for Auto-Instrumentation Init Containers

6 participants