Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Whereabouts IPAM CNI Sticky IP Addresses Enhancement #458

Closed
wants to merge 1 commit into from
Closed

Whereabouts IPAM CNI Sticky IP Addresses Enhancement #458

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
84 changes: 84 additions & 0 deletions enhancements/network/whereabouts-sticky-ips.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,84 @@
---
title: whereabouts-sticky-ips
authors:
- "@dougbtv"
reviewers:
- "@s1061123"
- "@zshi-redhat"
approvers:
- "@s1061123"
- "@zshi-redhat"
creation-date: 2020-08-05
last-updated: 2020-08-05
status: provisional
---


# Whereabouts "Sticky IP addresses"

## Release Signoff Checklist

- [ ] Enhancement is `implementable`
- [ ] Design details are appropriately documented from clear requirements
- [ ] Test plan is defined
- [ ] Graduation criteria for dev preview, tech preview, GA
- [ ] User-facing documentation is created in [openshift-docs](https://github.com/openshift/openshift-docs/)

## 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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What does "advertise their IP address in a method other than Kubernetes services" mean?


This has a benefit for workloads for OpenShift Container Storage (which could utilize this functionality to better provide network isolation by using Whereabouts in tandem with Multus CNI)

### Goals

This should be considered complete if a given workload can be assigned an IP address, be restarted, and still be assigned the same IP address.

### Non-Goals

(No relevant non-goals)

## Proposal

### Implementation Details/Notes/Constraints

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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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


Each of these CR's would be labeled with a given subnet/range in order to query for a given subnet/range to determine allocations within that range.

For example:

```
kubectl get ip -l subnet_31=127.0.0.0
```

It is proposed that the method by which a IP address is determined for a given workload is by having a specific MAC address, in a fashion that mimics DHCP.

It is proposed that a pod may have its mac address assigned in a deterministic fashion by using [kubemacpool](https://github.com/k8snetworkplumbingwg/kubemacpool).

### Risks and Mitigations

* This may require additional logic in order to upgrade a refactored CRD and existing data as this will require refactoring the CRD(s) used for Whereabouts.

## Design Details

### Open Questions

> 1. Decide on new CRD.
> 2. Is kubemacpool available in OCP without OpenShift Virtualization (KubeVirt)?

### Test Plan

(TBD.)

#### Examples

### Upgrade / Downgrade Strategy

This may require that additional logic is added during an upgrade/downgrade to convert data due to a refactored CRD.