Controls the lifecycle of the ServiceCIDRs adding finalizers and
setting the Ready condition in status when they are created, and
removing the finalizers once it is safe to remove (no orphan IPAddresses)
An IPAddress is orphan if there are no ServiceCIDR containing it.
Change-Id: Icbe31e1ed8525fa04df3b741c8a817e5f2a49e80
The repair loop controller watches the ServiceCIDRs configured
and use them to handle the repair of the IPAddresses assigned
by the kube-apiserver.
Change-Id: I8cfe8fd6285ea91192fc4ec72eaeea1eb004a235
Change-Id: If4be12e2c67b340d86c4efa2f9fb3672f0661636
Create a new allocator that uses the ServiceCIDRs configured in the
system to create IPAllocators.
The CIDRAllocator will create IPAllocators per parent ServiceCIDRs,
since we allow overlapping, there is no need to have an allocator
per ServiceCIDR.
The benefit of the IPAllocator is that uses the informer cache as
storage, hence, it does not need to keep cache and as only as logical
abstraction. This allows to create and delete IPAllocators without
any penalty.
IPAllocators can allocate IP addresses only if they are ready (not
being deleted)
Change-Id: I3fdda69991907c39cca3120fe2d850f14dcccec2
A radix tree is required to optimize operations with subnets and
IP addresses.
Change-Id: I9fecc291efd39bdd7403c9675c047d6dee6018d2
Change-Id: I72c7bd5920a42bf35305443450c4ba97f857c492
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
It's possible that the watcher is already not in the structure (e.g. in case of
simultaneous Stop() and terminateAllWatchers(), but it is safe to call stopLocked()
on a watcher multiple times.
In EnsureAdminClusterRoleBindingImpl() there are a couple of
polls around CRB create calls. When testing the function
a short retry and a timeout are used. These introduce around
2x20 fake client "connections" / poll iterations under a couple
of test cases with 2 seconds overall test increase.
Given the polls in EnsureAdminClusterRoleBindingImpl()
are of type PollUntilContextTimeout() with "immediate" set to "true",
the short retry / time out can be removed when testing,
because one poll iteration is guaranteed and the tested function
is at 100% coverage with reactors and test cases.
