- Use netutils.IsIPv6(ip) instead of manual nil/To4 check
- Remove unnecessary ip.To16() call since IPv6 is already 16 bytes
- Remove ipFamily from grep pattern since IP format ensures correctness
Signed-off-by: Davanum Srinivas <davanum@gmail.com>
The /proc/net/nf_conntrack file uses fully expanded IPv6 addresses
with leading zeros in each 16-bit group. For example:
fc00:f853:ccd:e793::3 -> fc00:f853:0ccd:e793:0000:0000:0000:0003
Add expandIPv6ForConntrack() helper function to expand IPv6 addresses
to the format used by /proc/net/nf_conntrack before using them in
the grep pattern.
Signed-off-by: Davanum Srinivas <davanum@gmail.com>
The distroless-iptables image no longer includes the conntrack binary
as of v0.8.7 (removed in kubernetes/release#4223 since kube-proxy no
longer needs it after kubernetes#126847).
Update the KubeProxy CLOSE_WAIT timeout test to read /proc/net/nf_conntrack
directly instead of using the conntrack command. The file contains the
same connection tracking data and is accessible from the privileged
host-network pod.
Signed-off-by: Davanum Srinivas <davanum@gmail.com>
Presumably
https://github.com/kubernetes/kubernetes/pull/127260/files#r2405215911
was meant to continue polling after a watch was closed by the apiserver.
This is something that can happen under load.
However, returning the error has the effect that polling stops.
This can be seen as test failures when testing with race
detection enabled:
persistent_volumes_test.go:1101: Failed to wait for all claims to be bound: watch closed
Fixes a bug where startup probe workers terminate incorrectly for sidecar
containers with restartPolicy=Always when the pod has restartPolicy=Never,
causing main containers to remain stuck in Initializing state.
Changes:
- Add container-level restart policy check for init containers only
- Extract complex boolean logic to named variable for readability
- Refactor test helper to use existing newWorker() function
- Add comprehensive unit and e2e tests for both scenarios
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.
