-
Notifications
You must be signed in to change notification settings - Fork 38.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
IPAddress allocator #115075
IPAddress allocator #115075
Conversation
/remove-sig api-machinery |
Change-Id: I19e12ca05d977dca63043cb07ecf8a90e0e525c5
rebased @thockin we need
|
known flake /test pull-kubernetes-e2e-kind |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On behalf of the review done by others and the fact that it is alpha
/lgtm
/approve
// LabelIPAddressFamily is used to indicate the IP family of a Kubernetes IPAddress. | ||
// This label simplify dual-stack client operations allowing to obtain the list of | ||
// IP addresses filtered by family. | ||
LabelIPAddressFamily = "ipaddress.kubernetes.io/ip-family" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can field selectors be used in watch? I have never done that...
We can revisit this and either make it a field selector or a "magic" label or something. I agree we need to make some guarantees
// objects to be managed by different controllers or entities within the | ||
// same cluster. It is highly recommended to configure this label for all | ||
// IPAddress objects. | ||
LabelManagedBy = "ipaddress.kubernetes.io/managed-by" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We need to fix owner ref. Grr....
LGTM label has been added. Git tree hash: 6bd9bd2d25dd4855c9f7941cc91f3746c1f94c08
|
/retest |
Changelog suggestion - Added a new IPAddress object kind
- Added a new ClusterIP allocator. The new allocator removes previous Service CIDR block size limitations for IPv4, and limits IPv6 size to a /64 something like that? |
// LabelManagedBy is used to indicate the controller or entity that manages | ||
// an IPAddress. This label aims to enable different IPAddress | ||
// objects to be managed by different controllers or entities within the | ||
// same cluster. It is highly recommended to configure this label for all | ||
// IPAddress objects. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should register this - see https://kubernetes.io/docs/reference/labels-annotations-taints/
// objects to be managed by different controllers or entities within the | ||
// same cluster. It is highly recommended to configure this label for all | ||
// IPAddress objects. | ||
LabelManagedBy = "ipaddress.kubernetes.io/managed-by" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we can't fix owner reference, or find an equivalent mechanism that doesn't use labels, could the label key be kubernetes.io/managed-by
? I'd like to just have one notion of things managing things rather than n of them.
// TODO: Use IPFamily as field with a field selector,And the value is set based on | ||
// the name at create time and immutable. | ||
// LabelIPAddressFamily is used to indicate the IP family of a Kubernetes IPAddress. | ||
// This label simplify dual-stack client operations allowing to obtain the list of | ||
// IP addresses filtered by family. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we need a label, we should register this - see https://kubernetes.io/docs/reference/labels-annotations-taints/
I'd go for network.kubernetes.io/ip-address-family
. Network is a nice general concept whereas IP address feels very specific. And, as a project, we control the namespace fairly effectively.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, there is also a comment to move it to a field, once we settle we should update all the docs accordingly
/milestone v1.27 approved before code freeze |
@thockin it seems it didn't pick the approve label correctly, can you retag? |
/approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: aojea, khenidak, thockin The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Congrats @aojea :-) |
Summarizing issues from this PR to not forget, please add the things you find missing, so I can start incorporating them to the follow up in #116516
|
/triage accepted |
/kind bug
/kind feature
What this PR does / why we need it:
This is the first step towards the implementation of KEP 1880, it introduces a new API object
IPAddress
and a feature gateMultiCIDRServiceAllocator
The feature gate enables a new ClusterIP Allocator that uses the IPAddress object instead of the the actual bitmap allocator, removing the current service cidr size limitations (ipv4 is a /12 and ipv6 /108) and setting the maximum size of a service CIDR in /64
The new IPAllocator uses IPAddress objects that reference the Service to store the ClusterIP, creating a 1-to-1 relation.
This relation is maintained by a repair controller that runs in the apiserver.
Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.:
Please use the following format for linking documentation: