Initializing the scheduler Features struct will be needed in different places,
therefore NewSchedulerFeaturesFromGates gets introduced. Besides, having it
next to the struct makes it easier to add new features.
The DRASchedulerFilterTimeout feature gate simplifies disabling the timeout
because setting a feature gate is often easier than modifying the scheduler
configuration with a zero timeout value.
The timeout and feature gate are new. The gate starts as beta and enabled by
default, which is consistent with the "smaller changes with low enough risk
that still may need to be disabled..." guideline.
This change adds the StructuredAuthenticationConfigurationEgressSelector
beta feature (default on). When enabled, each JWT authenticator
specified via the AuthenticationConfiguration.jwt array can
optionally specify either the controlplane or cluster egress
selector by setting the issuer.egressSelectorType field. When
unset, the prior behavior of using no egress selector is retained.
Egress selection is valuable when the persona configuring the JWT
authenticator and the persona managing the control plane are
different individuals. This change allows the latter to protect
control plane network services from unexpected connections.
Signed-off-by: Monis Khan <mok@microsoft.com>
This change introduces the TokenRequestServiceAccountUIDValidation feature
gate and implements feature-gated service account UID validation for the
TokenRequest API. When enabled, the API validates that the service account
UID in token requests matches the actual service account UID, preventing
token requests for recreated service accounts with the same name but
different UIDs.
Signed-off-by: Anish Ramasekar <anish.ramasekar@gmail.com>
The podresources API List implementation uses the internal data of the
resource managers as source of truth.
Looking at the implementation here:
https://github.com/kubernetes/kubernetes/blob/v1.34.0-alpha.0/pkg/kubelet/apis/podresources/server_v1.go#L60
we take care of syncing the device allocation data before querying the
device manager to return its pod->devices assignment.
This is needed because otherwise the device manager (and all the other
resource managers) would do the cleanup asynchronously, so the `List` call
will return incorrect data.
But we don't do this syncing neither for CPUs or for memory,
so when we report these we will get stale data as the issue #132020 demonstrates.
For CPU manager, we however have the reconcile loop which cleans the stale data periodically.
Turns out this timing interplay was actually the reason the existing issue #119423 seemed fixed
(see: https://github.com/kubernetes/kubernetes/issues/119423#issuecomment-2786891218).
But it's actually timing. If in the reproducer we set the `cpuManagerReconcilePeriod` to a time
very high (>= 5 minutes), then the issue still reproduces against current master branch
(https://github.com/kubernetes/kubernetes/blob/v1.34.0-alpha.0/test/e2e_node/podresources_test.go#L983).
Taking a step back, we can see multiple problems:
1. not syncing the resource managers internal data before to query for
pod assignment (no removeStaleState calls) but most importantly
2. the List call iterate overs all the pod known to the kubelet. But the
resource managers do NOT hold resources for non-running pod, so it is
better, actually it's correct to iterate only over the active pods.
This will also avoid issue 1 above.
Furthermore, the resource managers all iterate over the active pods
anyway:
`List` is using all the pods known about:
1. https://github.com/kubernetes/kubernetes/blob/v1.34.0-alpha.0/pkg/kubelet/kubelet.go#L3135 goes in
2. https://github.com/kubernetes/kubernetes/blob/v1.34.0-alpha.0/pkg/kubelet/pod/pod_manager.go#L215
But all the resource managers are using the list of active pods:
1. https://github.com/kubernetes/kubernetes/blob/v1.34.0-alpha.0/pkg/kubelet/kubelet.go#L1666 goes in
2. https://github.com/kubernetes/kubernetes/blob/v1.34.0-alpha.0/pkg/kubelet/kubelet_pods.go#L198
So this change will also make the `List` view consistent with the
resource managers view, which is also a promise of the API currently
broken.
We also need to acknowledge the the warning in the docstring of GetActivePods.
Arguably, having the endpoint using a different podset wrt the resource managers with the
related desync causes way more harm than good.
And arguably, it's better to fix this issue in just one place instead of
having the `List` use a different pod set for unclear reason.
For these reasons, while important, I don't think the warning per se
invalidated this change.
We need to further acknowledge the `List` endpoint used the full pod
list since its inception. So, we will add a Feature Gate to disable this
fix and restore the old behavior. We plan to keep this Feature Gate for
quite a long time (at least 4 more releases) considering how stable this
change was. Should a consumer of the API being broken by this change,
we have the option to restore the old behavior and to craft a more
elaborate fix.
The old `v1alpha1` endpoint will be not modified intentionally.
Signed-off-by: Francesco Romani <fromani@redhat.com>
