This moves the enabled/disabled test into the common test/integration/dra which
simplifies the code a bit and amortizes the cost of starting the apiserver
because several different tests can use the same instance, running in parallel.
While at it, setting the status via SSA also gets tested.
As soon as we have more than one test using the scheduler, we need some
coordination between tests. This is handled by a singleton which starts the
scheduler for the first user and stops it after the last one is gone.
To avoid having to pass around an additional parameter, the context is used to
access the singleton under the hood.
This enables proper scheduling tests. Most of them are probably better done in
scheduler_perf where the same test then can also be used for benchmarking and
creating objects is a bit better supported (from YAML, for example), but some
special cases (in particular, anything involving error injection) are better
done here.
DRA drivers must provide ResourceSlices using the v1beta2 API types.
The controller then converts under the hood to v1beta1 if needed, i.e.
drivers are compatible with Kubernetes 1.32 and Kubernetes 1.33, as
long as at least one beta API group is enabled.
Testing pivots from using v1beta1 as the main API to v1beta2, with only one
test case exercising v1beta1.
A user of the controller can register an error handler via the controller
options. For a kubelet plugin, the error handler is method in the interface
which must be implemented. This is a conscious choice to make DRA driver
developer aware that they should react intelligently to errors.
The controller will invoke that handler with all errors that it encounters
while syncing the desired set of slices. This includes validation errors from
the apiserver if the driver's slices are invalid. Dropped fields get reported
with a special DroppedFieldsError.
If the external jwt signer is enabled, publishing
OIDC discovery docs and keys fails because the PublicKeysGetter
is not wired correctly.
Set the public keys getter on startup so public key
discovery works in that case as well.
Choosing a port in advance is racy. A better solution is to use a Unix Domain
socket in the per-etcd-instance data directory. Then the name can be determined
in advance and there's no risk of conflicts with other etcd instances.
With unix:// for the endpoint, we have to be a bit more careful about
passing a TLS config to the etcd client library because for unix://, in
contrast to http://, it tries to use an incomplete config which
then fails to establish the connection.
The main goroutine always waited for the background goroutine, which itself
only proceeded after the 5 second timeout. To tell the goroutine that it is
okay to stop immediately, the main goroutine must cancel the context as soon
as etcd has quit.
When preemption finds no candidates, it currently makes an explicit API
call to clear the pod's nominatedNodeName in findCandidates(). However,
this is redundant because:
1. When no candidates are found, Preempt() returns a PostFilterResult with
an empty nominatedNodeName via NewPostFilterResultWithNominatedNode("")
2. This empty nominatedNodeName is propagated through the scheduling
cycle to handleSchedulingFailure()
3. handleSchedulingFailure() then properly clears the nominatedNodeName
through updatePod()
Remove the explicit ClearNominatedNodeName call in findCandidates() to
reduce unnecessary API calls while maintaining the same behavior.
This change improves performance by eliminating a duplicate API call
without changing the functional behavior of preemption.
This change modifies the validation logic for ServiceCIDR updates
(`ValidateServiceCIDRUpdate`) to specifically permit upgrading a
single-stack ServiceCIDR (either IPv4 or IPv6) to a dual-stack
configuration.
This reconfiguration path is considered safe because it only involves adding
a new CIDR range without altering the existing primary CIDR. This
ensures that existing Service IP allocations are not disrupted.
Other modifications, such as:
- Downgrading from dual-stack to single-stack
- Reordering CIDRs in a dual-stack configuration
- Changing the primary CIDR during a single-to-dual-stack
reconfiguration
remain disallowed by the validation. These operations carry a higher
risk of breaking existing Services or cluster networking
configurations. Preventing these updates automatically encourages
administrators to perform such changes manually after carefully
assessing the potential impact on their specific cluster environment.
The validation errors and controller logs provide guidance when such
disallowed changes are attempted.
Change-Id: I41dc09dfddb05f277925da2262f8114d6accbd1d
