Document setting -1 for warm and minimum ip targets

[Niksko]

What would you like to be added:

Documentation on the fact that setting WARM_IP_TARGET or MINIMUM_IP_TARGET to -1 (or indeed, any non-positive value) is the same as not setting these values.

Why is this needed:

Through shortcomings in the configuration management tool we're using, it's much easier for us to set these env variables to -1 in some environments, and set to them positive values in other environments where we want them to be set.
I had to dig through the source code to figure out that setting them to -1 would work. Setting variables to -1 to effectively have them not be set is fairly standard, and given that negative numbers don't really have any possible meaning in these contexts, it seems like an ok implementation detail to expose a part of the public API.

[jayanthvn]

Sure, I can update the documentation on the default behavior.

[kishorj]

If prefix delegation is enabled, setting the env variables to -1 would interfere with the engtrypoint.sh validation.

amazon-vpc-cni-k8s/scripts/entrypoint.sh

Line 40 in 968ae01

if [ "${WARM_PREFIX_TARGET}" == "0" ] && [ "${WARM_IP_TARGET}" == "0" ] && [ "${MINIMUM_IP_TARGET}" == "0" ];then

We will have to fix the validation script as well for the PD feature.

[jayanthvn]

@kishorj yeah that's right but we won't be able to support that with prefix delegation. Since it is a cluster wide config I feel better to unset the variable for no-op.

[Niksko]

@kishorj @jayanthvn would it be possible to update those scripts to check for <= 0 instead of == 0? That would maintain the existing behavior.

Or is there another way to set those values to a value indicating that they are unset?

[jayanthvn]

@Niksko we will have to add the check (<=0) in entry point script to make it consistent with IPAMD. The only way is to unset the variables if they are not being used. The reason for not supporting 0 for these environment variables is they will impact pod launch times when IPs or ENIs are to be allocated. So if a pod is scheduled and IPs are not available then the pod will be stuck in container creating until the next reconciler allocates more IPs. This will be even more slow when new ENI has to be allocated since we need to create+attach an ENI and wait for it to be synced to IMDS.