Updating the CNI plugins to the latest release and switch over to use
GitHub releases instead of the `k8s-artifacts-cni` bucket.
Follow-up on https://github.com/kubernetes/kubernetes/pull/129095
Signed-off-by: Sascha Grunert <sgrunert@redhat.com>
Compiling a CEL expression used to do the cost estimation, whether the caller
needed the result or not. Now callers can skip it. The scheduler does that,
through the CEL cache.
The main advantage is that failures in the estimator (like panics) are limited
to the apiserver. Performance in the scheduler is not expected to benefit much
because compilation results are cached.
Storing a context and making sure that it never gets canceled also has
overhead. We might as well just do the klog.FromContext when constructing
the Result and store the logger for later use.
The BackoffManager interface sleeps without considering the caller's context,
i.e. cancellation is not supported. This alone is reason enough to deprecate it
and to replace it with an interface that supports a context parameter.
The other reason is that contextual logging needs that parameter.
The default handler now uses contextual logging. Instead of
warnings.go:106] warning 1
it now logs the caller of client-go and uses structured, contextual
logging
main.go:100] "Warning" message="warning 1"
Users of client-go have the choice whether the handler that they provide uses
the traditional API (no API break!) or contextual logging.
kube-proxy does not look at Endpoints ever, so it is incorrect for a
test to assume that there is any correlation between whether Endpoints
exist and whether a Service is working. Tests should only be using the
v1.Endpoints API if they are explicitly testing the behavior of
v1.Endpoints, the Endpoints controller, or the EndpointSlice mirroring
controller. There is no reason for any non SIG Network tests to be
testing any of those things, so there should be no references to
v1.Endpoints in test/e2e outside of test/e2e/network.
Also, simplify some pointlessly complicated e2eservice code.
This was previously used by some autoscaling tests that have since
been removed. It is somewhat sketchy (and inherently [Disruptive]),
and depends on iptables (so would need to be updated to use nftables
at some point if we were keeping it). Given that it's now unused, just
remove it (as well as some helper functions that are no longer used by
anyone else as well).
cache.ErrRequeue advertised itself as a way to requeue failures on a
FIFO, but it suffers the same problems as AddIfNotPresent. If we do
requeue an item at the end, we'll move the informer back in time. If we
requeue at the beginning we'll simply wedge FIFO.
We didn't find examples in the wild, but by removing the error type
those impacted will get a compile error and get to decide what action is
most appropriate for their failure. Most of the time, proceeding to the
next item is best.
Logically a cache.Queue.AddIfNotPresent means that the informer can move
back in time since an older item is placed after newer items. The
alternative of placing errors at the head of the queue leads to
indefinite memory growth and repeated failures on retry.
Luckily this behavior was behind RetryOnError, which was always set to
false and impossible for normal users to set to true. By removing the
function and setting, impacted users (none found in a github search)
will get a compile failure.
