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
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.
The latest pause version is 3.10.2 but due to the introduction
of the PATCH level version to the pause image (previously was
only MAJOR.MINOR), various files have remained on an older
version. Either 3.10 or 3.10.1. Our validation with
build/dependencies.yaml ./hack/verify-external-dependencies.sh
did not account for that.
The Memory Manager Metrics BeforeEach asserts that zero pods are
running on the node after a kubelet config update. This hard assertion
flakes when a preceding serial test's namespace deletion hasn't
completed yet — framework namespace cleanup is async and the kubelet
restart in updateKubeletConfig can delay in-flight pod termination.
CI logs show leftover pods from MemoryQoS tests (memqos-burstable,
memqos-no-limit, etc.), Probe Stress tests (50-container pods), and
Summary API PSI tests (memory-pressure-pod), all still Running when
the assertion fires 4-7ms after the previous test finishes.
Replace the immediate Expect(count).To(BeZero()) with an Eventually
poll (2 minute timeout, 5 second interval) that gives pods time to
drain after the kubelet restart. The existing printAllPodsOnNode
diagnostic output is preserved inside the poll for debugging.
Signed-off-by: Davanum Srinivas <davanum@gmail.com>
This commit introduces the DRAResourceClaimGranularStatusAuthorization
feature gate (Beta in 1.36) to enforce fine-grained authorization checks
on ResourceClaim status updates.
Previously, 'update' permission on 'resourceclaims/status' allowed modifying
the entire status. To enforce the principle of least privilege for DRA
drivers and the scheduler, this change introduces synthetic subresources and
verb prefixes:
- 'resourceclaims/binding': Required to update 'status.allocation' and
'status.reservedFor'.
- 'resourceclaims/driver': Required to update 'status.devices'. Evaluated
on a per-driver basis using 'associated-node:<verb>' (for node-local
ServiceAccounts) or 'arbitrary-node:<verb>' (for cluster-wide controllers).
