When handling a PodSchedulingContext object, the code first checked for
unsuitable nodes and then tried to allocate if (and only if) the selected node
hadn't been found to be unsuitable.
If for whatever reason the selected node wasn't listed as potential node, then
scheduling got stuck because the allocation would fail and cause a return with
an error instead of updating the list of unsuitable nodes. This would be
retried with the same result.
To avoid this scenario, the selected node now also gets checked. This is better
than assuming a certain kube-scheduler behavior.
This problem occurred when experimenting with cluster autoscaling:
spec:
potentialNodes:
- gke-cluster-pohly-pool-dra-69b88e1e-bz6c
- gke-cluster-pohly-pool-dra-69b88e1e-fpvh
selectedNode: gke-cluster-pohly-default-pool-c9f60a43-6kxh
Why the scheduler wrote a spec like this is unclear. This was with Kubernetes
1.27 and the code has been updated since then, so perhaps it's resolved.
Kubernetes 1.28 introduced generated resource claim names, with the actual name
recorded in the pod status. As part of that change, the helper library for DRA
drivers was updated to match that behavior. Since then, driver deployments were
either compatible with Kubernetes 1.27 when using
k8s.io/dynamic-resource-allocation 0.27 or Kubernetes 1.28 when using 0.28,
but never both.
This was okay because this is an alpha feature, but it makes testing of DRA
drivers harder (in particular because cloud providers have not all updated to
1.28 yet) and can be fixed fairly easily. Therefore adding support for 1.27 is
worthwhile and reasonable.
The function generates bytes in the x={0-252} range and then
applies an y=(x mod 36) to obtain allowed token characters
from validBootstrapTokenChars[y].
Instead of using crypto/rand.Reader, use crypto/rand.Int()
that operates in the val={0-len(validBootstrapTokenChars))}.
Once a random index is generated, use simple operations
to obtain a random character in the a-z,0-9 character range.
This makes the character generation in constant-time.
Previously this was used to assert "something changed since the last
sync", but we already have packet flow tests in all of those cases now
to assert that the *specific* something we care about changed.
Rename TestOverallIPTablesRulesWithMultipleServices to just
TestOverallIPTablesRules, and add one rule type we weren't previously
testing (session affinity).
dir field has been deprecated in favour of dirs field, so that
multiple directories can be specified in the rules in future
when publishing-bot moves from filter-branch to filter-repo
Signed-off-by: Akhil Mohan <makhil@vmware.com>
The SetStatusCondition and RemoveStatusCondition currently do not
indicate if they changed anything. In most cases that information is
necessary to determine if an Update of the object is needed. This change
adds a boolean return to them that indicate if they changed anything.
As the two functions had no return at all prior to this, this shouldn't
break anything.
This change switches to using isCgroup2UnifiedMode locally to ensure
that any mocked function is also used when checking the swap controller
availability.
Signed-off-by: Evan Lezar <elezar@nvidia.com>
