This avoids the overhead for the more complex conversion to v1beta1 and might
make it a bit more realistic to get rid of the v1beta1 eventually.
The expected GVK must be set explicitly because when emulating 1.33,
v1beta1 is the default although the fixed storage version is v1beta2.
test/integration/apiserver/apply covers the behavior of server-side-apply (SSA)
for official APIs. But there seem to be no integration tests which cover the
semantic of SSA like adding/removing/updating entries in a list map. This adds
such a test.
It needs an API which is under control of the test and uses
k8s.io/apimachinery/pkg/apis/testapigroup for that purpose, with some issues
fixed (OpenAPI code generation complained) and a new list map added.
Registering that API group in the apiserver needs a REST storage and
strategy. The API group only gets added in the test. However, the production
code has to know about it. In particular,
pkg/generated/openapi/zz_generated.openapi.go has to describe it.
If the external jwt signer is enabled, publishing
OIDC discovery docs and keys fails because the PublicKeysGetter
is not wired correctly.
Set the public keys getter on startup so public key
discovery works in that case as well.
This change modifies the validation logic for ServiceCIDR updates
(`ValidateServiceCIDRUpdate`) to specifically permit upgrading a
single-stack ServiceCIDR (either IPv4 or IPv6) to a dual-stack
configuration.
This reconfiguration path is considered safe because it only involves adding
a new CIDR range without altering the existing primary CIDR. This
ensures that existing Service IP allocations are not disrupted.
Other modifications, such as:
- Downgrading from dual-stack to single-stack
- Reordering CIDRs in a dual-stack configuration
- Changing the primary CIDR during a single-to-dual-stack
reconfiguration
remain disallowed by the validation. These operations carry a higher
risk of breaking existing Services or cluster networking
configurations. Preventing these updates automatically encourages
administrators to perform such changes manually after carefully
assessing the potential impact on their specific cluster environment.
The validation errors and controller logs provide guidance when such
disallowed changes are attempted.
Change-Id: I41dc09dfddb05f277925da2262f8114d6accbd1d
- Add new version fields to version.Info struct:
* EmulationMajor and EmulationMinor to track emulated version
* MinCompatibilityMajor and MinCompatibilityMinor for compatibility tracking
- Update related code to populate and use these new fields
- Improve version information documentation and OpenAPI generation
- Modify version routes and documentation to reflect new version information structure
If kube-apiservers run at a different version (during upgrades) and
each has different opinion on what the `extension-apiserver-authentication`
config map should look like, they would start dueling with config map
writes.
This commit removes handling of the update events of the target CM
in order to reduce the amount of such dueling to once a minute, as
the controller is guaranteed to run at least once a minute anyway.
The idea is that a cluster state with two different versions of
kube-apiserver should never be permanent, and so a reduced amount of
dueling for that period is tolerable.
