Warning: This build has drifted.
The coverage report for this pull request build may be inaccurate because its base commit is no longer the HEAD of its target branch.
This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

    • Learn more: For more information on this, see Tracking coverage changes for pull request builds.
    • Fix now: For a quick fix, rebase this PR at GitHub. Your next report should be accurate.
    • Prevent going forward: To avoid this issue with future PRs, see these Recommended CI Configurations.

fix: correct eviction threshold memory units and hard/soft field reads

evictionThreshold() built its memory base as int64(gbs*1024*1024) and
passed it to resource.NewQuantity, which takes bytes. gbs is in GiB, so
the conversion needs 1024^3; every percentage-based memory threshold came
out 1024x too small.

Since the eviction threshold is part of InstanceTypeOverhead, and core
computes allocatable as capacity minus that overhead, this over-estimated
allocatable memory by nearly the whole intended threshold -- ~3.2 GiB on a
32 GiB node with memory.available: 10%. Karpenter then launches a node the
pending pod cannot fit on and, with no feedback loop, repeats indefinitely.

Separately, both the hard and soft blocks read EvictionHard for memory and
EvictionSoft for nodefs, so EvictionSoft[memory.available] and
EvictionHard[nodefs.available] were never consulted, and a KubeletConfig
setting only evictionSoft produced no threshold at all.

Only configs using percentage-valued memory signals are affected; absolute
values such as 500Mi are parsed directly and were always correct.

Two existing cases in TestEvictionThreshold asserted the buggy values (with
a comment reading '32Mi * 0.1' for a 32 GiB node) and are updated.