Add draft for KaaS LB standard

[joshmue]

Addresses https://github.com/SovereignCloudStack/issues/issues/227

Signed-off-by: Joshua Mühlfort [email protected]

[joshmue]

Per discussions in the latest container team meeting, for this decision record, we'll de-scope client IP preservation completely.

To sum up:

• enabling the health monitor at octavia by default will help ensuring that setting externalTrafficPolicy: Local will not result in frequent connectivity issues, which is the major point for this decision record anyway.
• externalTrafficPolicy: Local will not have the effect of that the actual client IP is visible to the application server. It will only cause Kubernetes to stop doing SNAT, which will only expose the direct TCP client IP - which is the Octavia HAProxy.

So currently, client IP preservation - at least on IP level - does not seem to be possible.

Comparing with other clouds, as far as I can tell: Google and Azure implement Load Balancers at at lower (router) level (aka DSR?), making preserving the actual source IP super easy. (Without understanding specifics, AWS also somehow implements client IP preservation). OpenStack Octavia makes use of higher (proxy) level, requiring an extra implementation at this high level.

TODO: Even though this will not trivial to implement, create a backlog item for this, as feature parity with major clouds is desired.

[joshmue]

I pretty much rewrote the record.

I know that the result of the container team call was to actively de-scope client IP preservation from this document, but there is too much pointing towards it to be able to just omit it.

I added a few considerations and three more detailed ways to go.

[joshmue]

This PR only requires the bare minimum (a working Service implementation of type=LoadBalancer), so I do not see any blocker for this PR.

Of course, this also means that the standard does not provide too much value other than showing off alternatives, being the basis for other standards, or kick starting implementation of e2e tests. So technically, it would not really matter whether this is merged or abandoned. I'd opt to do either, though.

@mbuechse @garloff @jschoone How to proceed?

[cah-hbaum]

This PR only requires the bare minimum (a working Service implementation of type=LoadBalancer), so I do not see any blocker for this PR.

Of course, this also means that the standard does not provide too much value other than showing off alternatives, being the basis for other standards, or kick starting implementation of e2e tests. So technically, it would not really matter whether this is merged or abandoned. I'd opt to do either, though.

@mbuechse @garloff @jschoone How to proceed?

I'm neither of the mentioned people, but IMO this is a good document. But I agree with your assessment that the overall value isn't that big. While reading it, I had the impression, that this is more of a Decision Record. So personally, I would just change this to a DR and take it as a base for a future standard.

[joshmue]

I'm neither of the mentioned people

Your feedback is welcome, of course. Thanks! Just wanted to limit to mentioning as much as possible.

But I agree with your assessment that the overall value isn't that big. While reading it, I had the impression, that this is more of a Decision Record. So personally, I would just change this to a DR and take it as a base for a future standard.

Indeed, I structured it a little bit DR-like. I'm still a bit unsure whether wording should be adjusted to be more standard-like or making it a DR completely. Mostly because this would have been most likely a standard if the result had been different. Should that make a difference? Also, it's been more that a year now, so the decision may be reevaluated. :man_shrugging:

[jschoone]

I'm neither of the mentioned people

Your feedback is welcome, of course. Thanks! Just wanted to limit to mentioning as much as possible.

But I agree with your assessment that the overall value isn't that big. While reading it, I had the impression, that this is more of a Decision Record. So personally, I would just change this to a DR and take it as a base for a future standard.

Indeed, I structured it a little bit DR-like. I'm still a bit unsure whether wording should be adjusted to be more standard-like or making it a DR completely. Mostly because this would have been most likely a standard if the result had been different. Should that make a difference? Also, it's been more that a year now, so the decision may be reevaluated. 🤷‍♂️

Hi @cah-hbaum and @joshmue, sorry for the very late response, I was pretty sure I answered :facepalm: Now I forgot what it was. I also think there's no blocker and I like the idea from Hannes to just make a DR out of it

[mbuechse]

Is this still relevant? I will close this PR if nothing happens by July 31st.

[cah-hbaum]

I wanted to update this yesterday, but since this is a repository fork from @joshmue, I couldn't really do that.

[joshmue]

Seems like I cannot change the source branch to some branch in this repo (not directly anyway).

@cah-hbaum would you prefer to

1. close this and create a new PR from a new branch in this repo OR
2. merge this PR into a new branch in this repo, then create another PR from the newly created branch to main?

[cah-hbaum]

I think merging this into a new branch and then updating this branch would be best. I'm gonna set that up.

[cah-hbaum]

@josmue Please merge, we will address other comments in the following PR.