Rather than having GetNodeAddresses() return a special magic value
indicating that it matches all IPs, add a separate method to check
that. (And have GetNodeAddresses() just return the IPs as expected
instead.)
k/k doesn't use much code from docker/distribution so this doesn't
change anything that's actually relevant, but 2.8.1 is identified as
affected by CVE-2022-28391 and CVE-2023-2253; bumping to 2.8.2 avoids
k/k triggering scanners on those CVEs.
Signed-off-by: Stephen Kitt <skitt@redhat.com>
The nightly containerd binary no longer works in the current kind base images:
May 15 16:32:31 kind-worker containerd[222]: /usr/local/bin/containerd:
/lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by
/usr/local/bin/containerd)
kind now builds containerd directly with the base images. The official base
images still use containerd 1.6, so we have to use a special base image that
was prepared for this purpose.
Because the containerd config can be patched through kind, we don't need to
modify the generated node image anymore.
If scheduler fails to be active (elected if leader election is enabled),
setting this option will not start informers so that to avoid memory
overhead.
Signed-off-by: Eric Lin <exlin@google.com>
This feature gates were GAed in Kubernetes v1.24 and supposed to be
removed in kubernetes >=v1.26. This commit remove the same.
Signed-off-by: Humble Chirammal <humble.devassy@gmail.com>
Both proxies handle IPv4 and IPv6 nodeport addresses separately, but
GetNodeAddresses went out of its way to make that difficult. Fix that.
This commit does not change any externally-visible semantics, but it
makes the existing weird semantics more obvious. Specifically, if you
say "--nodeport-addresses 10.0.0.0/8,192.168.0.0/16", then the
dual-stack proxy code would have split that into a list of IPv4 CIDRs
(["10.0.0.0/8", "192.168.0.0/16"]) to pass to the IPv4 proxier, and a
list of IPv6 CIDRs ([]) to pass to the IPv6 proxier, and then the IPv6
proxier would say "well since the list of nodeport addresses is empty,
I'll listen on all IPv6 addresses", which probably isn't what you
meant, but that's what it did.
The goal is to only label workloads as "performance" which actually run long
enough to provide useful metrics. The throughput collector samples once per
second, so a workload should run at least 5, better 10 seconds to get at least
a minimal amount of samples for the percentile calculation.
For benchstat analysis of runs with sufficient repetitions to get statistically
meaningful results, each workload shouldn't run more than one minute, otherwise
before/after analysis becomes too slow.
The labels were chosen based on benchmark runs on a reasonably fast desktop. To
know how long each workload takes, a new "runtime_seconds" benchmark result
gets added.
Right now container runtimes have no way to provide additional context
to the pull errors. We now loosen the constraints and check for
additional messages after the actual CRI errors, which allows to enrich
the verbosity of the warning events, for example:
```
Warning Failed 2s (x3 over 43s) kubelet Failed to pull image "localhost:5000/foo": RegistryUnavailable: pinging container registry localhost:5000: Get "http://localhost:5000/v2/": dial tcp [::1]:5000: connect: connection refused
```
Signed-off-by: Sascha Grunert <sgrunert@redhat.com>
