The goal is to make the test apiserver behave as much as kube-apiserver as
possible. This ensures that tests are as realistic as possible out-of-the-box.
If a test needs a special setup, then that should be visible in the test
because it passes additional flags or options.
One historic deviation from that goal was enabling all API groups. That
change (from 7185624688) gets reverted and tests
which happened to rely on this get updated.
DRA had integration tests as part of test/integration/scheduler_perf (for the
scheduler plugin) and some others scattered in different
places (e.g. test/integration/resourceclaim for device status).
The new test/integration/dra is meant to become the common location for all
DRA-related integration tests. This makes it simpler to share common setup
code.
Replace DefaultComponentGlobalsRegistry with new instance of componentGlobalsRegistry in test api server.
Signed-off-by: Siyuan Zhang <sizhang@google.com>
move kube effective version validation out of component base.
Signed-off-by: Siyuan Zhang <sizhang@google.com>
move DefaultComponentGlobalsRegistry out of component base.
Signed-off-by: Siyuan Zhang <sizhang@google.com>
move ComponentGlobalsRegistry out of featuregate pkg.
Signed-off-by: Siyuan Zhang <sizhang@google.com>
remove usage of DefaultComponentGlobalsRegistry in test files.
Signed-off-by: Siyuan Zhang <sizhang@google.com>
change non-test DefaultKubeEffectiveVersion to use DefaultBuildEffectiveVersion.
Signed-off-by: Siyuan Zhang <sizhang@google.com>
Restore useDefaultBuildBinaryVersion in effective version.
Signed-off-by: Siyuan Zhang <sizhang@google.com>
rename DefaultKubeEffectiveVersion to DefaultKubeEffectiveVersionForTest.
Signed-off-by: Siyuan Zhang <sizhang@google.com>
pass options.ComponentGlobalsRegistry into config for controller manager and scheduler.
Signed-off-by: Siyuan Zhang <sizhang@google.com>
Pass apiserver effective version to DefaultResourceEncodingConfig.
Signed-off-by: Siyuan Zhang <sizhang@google.com>
change statusz registry to take effective version from the components.
Signed-off-by: Siyuan Zhang <sizhang@google.com>
Address review comments
Signed-off-by: Siyuan Zhang <sizhang@google.com>
update vendor
Signed-off-by: Siyuan Zhang <sizhang@google.com>
They were enabled yesterday and executed seven times, with results that (so
far) seem to be fairly stable with just one run that was slower across the
board.
The links in the YAML can be used to navigate to each test case quickly. The
thresholds were chose with a 20% security margin below what seems to be a
common result.
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.
