The HPA controller keeps a flat history of recommendations for
stabilization. However when both up and down scale stabilization are
configured, the interpretation of the history changes depending on the
direction of movement. What we want is to keep the stabilized
recommendation within the envelope of the minimum and maximum over
configured stabilization windows. We should only move when the
envelope forces a move.
I noticed rsc.io/sampler was in here, which didn't make any sense.
It appears to have been mistakenly included in a transitive dependency
at some point.
This PR attempts to fix that by updating the intermediate deps far enough
to stop requiring the rsc.io packages.
in pkg/scheduler/eventhandlers.go
* add event for unscheduled pod
* delete event for unscheduled pod
* add event for scheduled pod
* delete event for scheduled pod
in pkg/scheduler/framework/plugins/defaultbinder/default_binder.go
* Attempting to bind pod to node
in pkg/scheduler/scheduler.go
* Updating pod condition
* Attempting to schedule pod
* Skip schedule deleting pod
fakeVolumeHost previously implemented both the KubeletVolumeHost and
AttachDetachVolumeHost interfaces. This design makes it difficult to test the
CSIAttacher since it behaves differently depending on what type of
VolumeHost is supplied.
We are planing to test and support 20H2 release of Windows, thus,
we need to build test images for it as well. The busybox image already
has a BASEIMAGE entry for it, but we also need to add it to the image-util.sh's
windows_os_versions, so the OS Version can be properly included in the
manifest list.
e2e test validates the following 3 extra endpoints
- readApiregistrationV1APIServiceStatus
- patchApiregistrationV1APIService
- listApiregistrationV1APIService
The test create a pod with a hostPort to expose an SCTP port, then
it checks if the iptables rules were installed correctly in the host.
The iptables rules MUST be checked in the same host where the pod
is running :)
When the maxsurge daemonset gate is disabled, the registry and validation
must properly handle stripping the field. In the special case where that
would leave the MaxUnavailable field set to 0, we must set it to 1 which
is the default value.
The MaxSurge field on DaemonSet rolling updates allows a daemonset
workload to have two pods running simultaneously on a node during
an update in order to perform zero-disruption handoffs of client
traffic.
