Decomposing the Kubernetes Service API

[shaneutt]

The Kubernetes Service API is notable for having a wide scope with many different faucets, and where a lot of networking functionality in Kubernetes has historically converged. Consequently (and detrimentally) in upstream Kubernetes there is very strong resistance to changing or adding anything on top of it (understandably).

Blixt has been existing as a place to experiment and try new things, and to this end the purpose of this issue is to propose that we try and decompose the Service API into the constituent underlying things it currently performs all-in-one. Those things include (but are not necessarily limited to):

• IPAM
• DNS
• Routing
• Load-Balancing

Ideally the result of this feature would be to have new APIs that solve at least each of the above problems separately, and subsequently can then be composed into a replacement for Service. Afterwards we should retrofit our Service implementation such that creating a Service no longer has it's own implementation, but instead the controller would just assemble these composable pieces together to provide the same functionality.

[shaneutt]

We talked about this in a sync, and we're up for doing this experiment.

/triage accepted

In the past we haven't done full on proposals in Blixt, for this one we want to create a new collaborative proposal so we'll need to put together a proposal process. We should go as lightweight as possible (probably just follow the Gateway Enhancement Proposal (GEP) process lightly). Sanskar and I are going to pair up to bootstrap this.

/assign @aryan9600 @shaneutt

This one will get it's own milestone, so will be on hold now while we finish up some of the preceeding milestones.

/hold
/blocked