Runtime config can be set via the kind config, which is simpler than setting
the apiserver parameter.
DynamicResourceAllocation is enabled by default nowadays, but still needs to be
set for the current n-3 skew testing which picks 1.33 (1.37 still in alpha).
Similar for NodeLogQuery (GA in 1.36).
When MutableSchedulingDirectivesForSuspendedJobs feature gate is
enabled, it overwrites the notStarted check with a stricter condition
requiring the JobSuspended=True condition. This rejects mutations on
suspended Jobs that have never started but whose JobSuspended condition
has not yet been set by the job controller, breaking external
controllers like MultiKueue that inject scheduling directives
immediately after creating a suspended Job.
Preserve the notStarted path as an OR condition alongside the
JobSuspended condition check, restoring pre-1.36 behavior for
not-yet-started Jobs while maintaining the new relaxation for
previously-started Jobs.
Kubernetes-issue: https://github.com/kubernetes/kubernetes/issues/139281
Accessing svc.Spec.IPFamilies[0] without a bounds check panics when a
service reaches the controller with an empty IPFamilies field. This can
happen via watch events: the apiserver's defaultOnRead decorator populates
IPFamilies on GET/LIST but not on watch (cachingObject wrapping bypasses
the type assertion).
Restore the inference logic removed in #130101: fall back to ClusterIP
for headful services and pod IP for headless services.
Signed-off-by: Rahul <rahulbabu95@gmail.com>
On a remount (e.g. CSIDriver.spec.requiresRepublish=true), the volume is
already published and the pod is observing the existing bind mount.
Removing the mount dir on a NodePublish error left the pod with stale
contents that subsequent successful republishes could not repair.
Thread the reconciler's existing isRemount signal into MounterArgs so
volume plugins can distinguish an initial publish from a republish
(e.g. CSIDriver.spec.requiresRepublish=true). No behavior change.
When DRAConsumableCapacity is enabled, multi-allocatable device
allocations are tracked via AllocatedSharedDeviceIDs and
AggregatedCapacity instead of AllocatedDevices. The incubating and
experimental allocators only checked AllocatedDevices when rebuilding
available SharedCounters, so committed shared allocations could be
missed across scheduling cycles.
Add an internal IsDeviceAllocated helper that checks all committed
allocation-state sources, and use it when reconstructing consumed
counters. Add a regression test for a fresh allocator seeing committed
shared-device counter consumption.
When collecting all matching devices for AllocationModeAll, the allocator did not record the source pool on the candidate device. Devices with consumed counters use that pool when checking shared counter availability, which caused kube-scheduler to panic.
Set the pool on all-devices candidates in the stable, incubating, and experimental allocators, and add a shared regression test for AllocationModeAll with consumed counters.
