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.
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>
Add v1beta4.ClusterConfiguration.EncryptionAlgorithm field (string)
and allow the user to configure the cluster asymetric encryption
algorithm to be either "RSA" (default, 2048 pkey size) or "ECDSA" (P-256).
Add validation and fuzzing. Conversion from v1beta3 is not required
because an empty field value is accepted and defaulted to RSA if needed.
Leverage the existing configuration option (feature gate) PublicKeysECDSA
but rename the backend fields, arguments, function names to be more
generic - EncryptionAlgorithm instead of PublicKeyAlgorithm.
That is because once the feature gate is enabled the algorithm
configuration also applies to private keys. It also uses the kubeadm API
type (string) instead of the x509.PublicKeyAlgorithm enum (int).
Deprecate the PublicKeysECDSA feature gate with a message.
It should be removed with the release of v1beta4 or maximum one release
later (it is an alpha FG).
