Kubernetes clusters allow to define an IPv6 range of /108 for IPv6
despite the old allocators will only use the first /112 of that range.
The new allocators does not have this limitation, so they can allocate
IPs on the whole space, the problem happens on upgrades from clusters
that were already using this size, since the new allocators by default
will try to allocate addresses that works for both new and old allocatos
to allow safe upgrades.
The new allocators, when configured to keep compatibility with the old
allocators, must try first to allocate an IP that is compatible with the
old allocators and only fall back to the new behavior if it is not
possible.
- update internal ReplicaSet and Deployment type documentation to match with
versioned API
- made Replicaset and Deployment type documentation more consistent
* `client-go`: transform `watchErrorStream` to wrap the underlying error
This PR transforms the `client-go`'s `watchErrorStream` to wrap the error instead of transforming it into a single string. This enables clients to use `errors.Is/As/Unwrap` with the errors that come out of `StreamWithContext`
Fixes https://github.com/kubernetes/kubernetes/issues/129763
* adjust unit tests
The test is super hacky and we'll not be needed once the corresponding
KEP is implemented, better to remove it that trying to fix it
perpetuating the hacky solution.
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.
