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
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.
27a68aee3a introduced context support for events. Creating an event
broadcaster with context makes tests more resilient against leaking goroutines
when that context gets canceled at the end of a test and enables per-test
output via ktesting.
The context could get passed to the constructor. A cleaner solution is to
enhance context support for the apiserver and then pass the context into the
controller's run method. This ripples up the call stack to all places which
start an apiserver.
The default service-cidr controller blocks the apiserver because it
needs to create the default ServiceCIDR so Services can be allocated.
If the apiserver is started without the default ServiceCIDR any attempt
to createa new Service will fail, and this is a breaking change for
users and installers that does not retry on this operation.
Instead of using a channel to signal the controller is ready, just
implement two loops, a first one that verifies that is ready and that
polls with a shorted interval, and leave the second loop with the
existing interval.
Change-Id: I54303af9faeaa9c5cce2a840b6b7b0320cd2f4ad
The bootstrap controller for ServiceCIDR ensures that the default
ServiceCIDR is created from the existing flags.
It follows the same behavior than the kubernetes.default Service,
it only creates the default ServiceCIDR if it doesn't exist, but
does not modify it despite the parameters doesn't match.
review: bootstrap controller for default ServiceCIDR
