And update most of the comments to refer to "nftables" rather than
"iptables" (even though it doesn't actually do any nftables updating
at this point).
For now the proxy also internally creates a
utiliptablestesting.FakeIPTables to keep the existing sync code
compiling.
(It is confusing, but allowed, to have distinct "KUBE-SERVICES" chains
in "nat" and "filter" in iptables, but in nftables the "type nat" and
"type filter" chains end up in the same table, so we'll need different
names for the two.)
Change the svcPortInfo and endpointInfo fields to string rather than
utiliptables.Chain, and various fixups from there.
Also use a proper set for activeNATChains, and fix the capitalization
of endpointInfo.chainName.
When a ServiceCIDR is deleted, the service CIDR controller on the
controller manager verifies that is safe to be deleted before removing
the finalizer, howerver, since the information of deletion takes time to
propragate, there can be a race where the apiserver allocators didn't
receive the information of deletion and assign an IP address that will
be orphan.
To avoid this race, the service cidr controller waits a grace period
before removing the finalizer to ensure the allocators do not assign any
new IP Address from that range before is completely deleted.
Change-Id: Ib34d32c0bdde91c6e84f1d056db9374589b25c0b
Since ServiceCIDR and IPAddresses are mostly API driven integration
test will give us a good coverage, exercising real use cases like
the migration from one ServiceCIDR range to a new range.
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
