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

[dgokcin]

Problem

The current auto-instrumentation for init containers in the admission controller always sets requests = limits, either via fixed env vars or by auto-calculating based on the pod’s total resources.

This often leads to:

• Over-provisioned init containers (bad for scheduling, especially with large/complex pods)
• Under-provisioned init containers if you try to set lower env vars (risking OOM or throttling during library initialization)

Proposal

Add support for separate requests and limits for auto-instrumentation init containers using new env vars:

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

Behavior:

• If new vars are set, use them for requests/limits
• If only legacy vars are set, keep current behavior (requests = limits)
• If nothing is set, use the current auto-calc logic
• Validate: limits must be ≥ requests, with clear errors if not

Example

For a pod with high total resources, you could set:

DD_ADMISSION_CONTROLLER_AUTO_INSTRUMENTATION_INIT_REQUESTS_CPU=25m
DD_ADMISSION_CONTROLLER_AUTO_INSTRUMENTATION_INIT_REQUESTS_MEMORY=50Mi
DD_ADMISSION_CONTROLLER_AUTO_INSTRUMENTATION_INIT_LIMITS_CPU=500m
DD_ADMISSION_CONTROLLER_AUTO_INSTRUMENTATION_INIT_LIMITS_MEMORY=1Gi

This keeps requests low for scheduling, but allows higher limits for initialization spikes.

Compatibility

• Existing configs stay valid
• New vars are optional and only used if set

Related Issues in Other Datadog Repositories

• datadog-lib-java-init container dies with OOMKilled  helm-charts#1519
• Init container container resource limitation datadog-operator#1832

---

This would align with Kubernetes best practices and give more flexibility for real-world workloads, especially monoliths and multi-container pods.