Whereabouts IPAM CNI Sticky IP Addresses Enhancement #458
Conversation
This proposes a general design for how Whereabouts can handle sticky (persistent) IP addresses.
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: dougbtv The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
There is another aspect around IPAM for providing same IP which came up when discussing KubeVirt and live migration for Pod networks. Could be very different/not in scope, but might be wroth considering when looking at this. |
|
|
||
| ## Summary | ||
|
|
||
| This feature implements functionality for Whereabouts where workloads are assigned an IP address, and when those workloads are terminated and restarted, are assigned the same IP address. |
There was a problem hiding this comment.
Is this an enhancement to something we already ship and support, or proposing Whereabouts in general?
If it's something we already ship, where could I read more about its inclusion in OpenShift and what use cases it solves today?
If it's introducing Whereabouts as a new thing, can you update this to do two things: first introduce the problem without mention of the solution (whereabouts). Then can you summarize what wherabouts is, where it comes from, and how people can learn more?
There was a problem hiding this comment.
whereabouts is something we already ship, but that was pre-enhancements, and I have no idea what it does (although I'm sure Doug explained it to me at some point) so yeah, it would be good to have this enhancement as both an explanation of whereabouts and an explanation of the new 4.7 feature on top of that.
There was a problem hiding this comment.
+1 to explaining both, thanks :)
|
|
||
| ## Motivation | ||
|
|
||
| This functionality has been requested to provide reliable IP addresses for workloads that advertise their IP address in a method other than Kubernetes services, and where external components require that those same IP addresses be reachable regardless if the workload has been restarted. |
There was a problem hiding this comment.
What does "advertise their IP address in a method other than Kubernetes services" mean?
|
|
||
| Some upstream discussion regarding the design has already occured in [this upstream issue](https://github.com/dougbtv/whereabouts/issues/51). | ||
|
|
||
| Generally the proposed design is to create a new CRD that is specific to an individual IP address. This can be used with, or as an extension to data that exists for storing IP addresses individually in order to determine if they are used in overlapping ranges. |
There was a problem hiding this comment.
CRD or CR?
It would be interesting to see how closely that matches https://github.com/metal3-io/metal3-docs/blob/master/design/ip-address-manager/ip-address-management-for-networkdata.md
|
Issues go stale after 90d of inactivity. Mark the issue as fresh by commenting If this issue is safe to close now please do so with /lifecycle stale |
openshift-ci-robot
added
the
lifecycle/stale
|
Stale issues rot after 30d of inactivity. Mark the issue as fresh by commenting If this issue is safe to close now please do so with /lifecycle rotten |
openshift-ci-robot
added
lifecycle/rotten
|
Rotten issues close after 30d of inactivity. Reopen the issue by commenting /close |
|
@openshift-bot: Closed this PR. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
This proposes a general design for how Whereabouts can handle sticky (persistent) IP addresses.