Currently, the populator container created during the DiskAllocation phase is spun up without any Kubernetes resource requests or limits.

This poses two main problems:

Cluster Instability (Noisy Neighbor): An unbounded populator container can consume an excessive amount of CPU or memory, potentially starving other critical workloads on the same node and leading to instability.

No Quality of Service (QoS): Without requests, the populator pod gets a BestEffort QoS class, making it the first to be evicted under resource pressure. This can interrupt and delay disk operations (like VM migrations) unexpectedly.

Proposed Solution
Modify the populator container specification to include configurable resources definitions. This involves adding:

resources.requests (e.g., CPU, memory): To guarantee a minimum amount of resources for the populator to function reliably. This will likely move its QoS class to Burstable.

resources.limits (e.g., CPU, memory): To cap the maximum resources the populator can consume, preventing it from impacting other services.

These values should be made configurable to allow cluster administrators to tune them based on their specific node sizes and workloads.