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.
When multiple driver metadata files contain the same request name, keep a
single request entry and merge devices into it. This avoids duplicate request
objects when count>1 allocations are split across drivers.
Assisted-by: Cursor (codex-5.3)
Signed-off-by: Or Shoval <oshoval@redhat.com>
FetchInitConfigurationFromCluster always called SetAPIEndpointDynamicDefaults,
which invokes ChooseAPIServerBindAddress and requires a default route on the
host. Worker nodes joining the cluster don't need a LocalAPIEndpoint and may
legitimately have no default route, causing kubeadm join to fail with:
```
unable to fetch the kubeadm-config ConfigMap: unable to select an IP from
default routes.
```
Add a skipAPIEndpoint parameter to SetInitDynamicDefaults and pass
`!getAPIEndpoint` from FetchInitConfigurationFromCluster, so the endpoint
defaulter is bypassed when the caller did not request the endpoint (worker
join, non-control-plane reset/certs/upgrade paths).
Signed-off-by: Seena Fallah <seenafallah@gmail.com>
Historicaly the kubeadm clients have used the 'admin.conf'
and 'super-admin.conf' directly, which makes all API calls
go trough the CPE (control plane endpoint). This can create
problems for scenarios when the LB is provisioned only after
'init' starts the kube-apiserver.
Instead of using the '.conf' as they are, modify them
in memory to point to the LAE (localAPIEndpoint).
This was already done by the WaitControlPlaneClient for
the WaitControlPlane phase, which required it. This separate
client is no longer needed.
However, do use a unmodified kubeconfig to the init phase
bootstrap-token since this is the phase that creates
the cluster-info CM and for that we need the original CPE
server address.
Periodic full-syncs are just reconcile loops just in case somehow
the dataplane has drifted, however, they have an important cost on large
clusters.
We can avoid to perform full-sync if kube-proxy is in the "largecluster"
mode, we are already doing some optimization, so it is reasonable to
avoid the penalty of a full sync for a "just in case" operation.
Signed-off-by: Antonio Ojea <aojea@google.com>
Modify() was replacing components one at a time: stop X, start X, stop Y,
start Y, ... in version-skew order (apiserver last on downgrade). This
caused a crash during downgrade: KCM-1.35 started against the still-
running apiserver-1.36, passed its /healthz, and then immediately lose
its connection when apiserver-1.36 was killed by the localupcluster.
KCM-1.35 would reconnect to the not-yet-ready apiserver-1.35, hit a
403 RBAC error during controller initialization, and exit — because that
initialization phase does not retry on RBAC errors.
Fix by splitting Modify() into two phases:
Phase 1 — stop all components to be replaced, in reverse startup order
(kube-proxy down to apiserver), so dependent components release their
connections before the apiserver is stopped.
Phase 2 — start all replacement components in standard startup order
(apiserver first), so each component connects to a fully-ready apiserver.
Without an explicit interval, Gomega's default polling is very frequent,
generating a large volume of /readyz and /healthz requests in the component
logs. Set an explicit 1-second interval to reduce noise while still
detecting readiness promptly.
Despite being called checkReadiness, the function was only performing
a liveness check: /healthz was polled over HTTPS without verifying the
certificate or authenticating, and any HTTP response was accepted as a
signal that the component was up. The only exception was kubelet,
where a node readiness check was added on top.
Switched to /readyz for kube-apiserver and kube-scheduler,
kept /healthz for the rest and require HTTP 200 in all cases.
This ensures that the kube-apiserver is fully initialized before
dependent components are started.
