Writes to policy resources don't instantaneously take effect in admission. ValidatingAdmissionPolicy
integration tests determine that the policies under test have taken effect by adding a sentinel
policy rule and polling until that rule is applied to a request.
If the marker resource names are the same for each test case in a series of test cases, then
observing a policy's effect on a marker request only indicates that _any_ test policy is in effect,
but it's not necessarily the policy the current test case is waiting for. For example:
1. Test 1 creates a policy and binding.
2. The policy and binding are observed by the admission plugin and take effect.
3. Test 1 observes that a policy is in effect via marker requests.
4. Test 1 exercises the behavior under test and successfully deletes the policy and binding it
created.
5. Test 2 creates a policy and binding.
6. Test 2 observes that a policy is in effect via marker requests, but the policy in effect is still
the one created by Test 1.
7. Test 2 exercises the behavior under test, which fails because it was evaluated against Test 1's
policy.
Generating a per-policy name for the marker resource in each test resolves the timing issue. In the
example, step (6) will not proceed until the admission plugin has observed the policy and binding
created in (5).
Once received job deletion event, it cleans the backoff records for that
job before enqueueing this job so that we can avoid a race condition
that the syncJob() may incorrect use stale backoff records for a newly created
job with same key.
Co-authored-by: Michal Wozniak <michalwozniak@google.com>
Automated cherry pick of #131742: [sig-scheduling] SchedulerPreemption [Serial] validates various priority Pods preempt expectedly with the async preemption: replace finalizers with preStop hook and TerminationGracePeriodSeconds
Finalizers do not work as expected when an informer with a field
selector is used. Any time a pod changing its state gets excluded by the
field selector a synthetic delete event is issues even though the pod
with a finalizer set is still present. Thus, making the scheduler
schedule the high and medium priority pods before any of the low
priority pod finalizers is removed. Instead, rely on preStop hook and
TerminationGracePeriodSeconds to keep all low priority pods long enough
included by the field selector so all high priority pods can set their
.status.nominatedNodeName field.
Also, update the check for how many medium priority pods are expected to
be scheduled. Each node can accept 10 pods of the given extended
resources. Given there's 5 high priority created per node, there's
always 5 times number of nodes spots left for the medium priority pods.
With StreamingCollectionEncodingToJSON and
StreamingCollectionEncodingToProtobuf, the WatchList must re-justify its
necessity. To prevent an ecosystem from building around a feature that
may not be promoted, we will stop serving list-via-watch until
performance numbers can justify its inclusion.
This also stops the kube-controller-manager from using the
list-via-watch by default. The fallback is a regular list, so during
the skew during an upgrade the "right" thing will happen and the new
StreamingCollectionEncoding will be used.
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
The controller is available only with SELinuxChangePolicy FG enabled.
Kubernetes e2e jobs do the right --focus & --skip explicitly in the SELinux
jobs, this just helps other test runners to figure out what FGs are needed
to run the tests.
When at it, I noticed SELinuxMountReadWriteOncePod tag is always required, so
add it on the common level and not in each test.
The existing TrafficDistribution test didn't really distinguish "same
zone" from "same node". Add another test that makes sure there are at
least 2 nodes in each zone so it can do that.
(Keep the original test as well to avoid losing coverage in CI systems
with single-schedulable-node-per-zone clusters.)
