Blixt to support the KNI project?

[shaneutt]

To date we have be tracking Blixt as an implementation of Gateway API, particularly focusing on Layer 4 level support. Recently a new project called Kubernetes Networking reImagined (KNI) has been proposed which would rework Kubernetes networking in a way that would enable:

• multi-network (multiple networks for any pod)
• egress
• composable network APIs (e.g. IPRoute)

Because we're already working at a low level in Blixt with low-level networking and directly working with the Linux kernel, we're potentially in a great place to support the KNI project by becoming an implementation of it.

What this would entail is hard to tell now, as the project is all speculative at the moment, but given what's been said today we would need to:

• general pod network management: IPAM, routing, e.t.c.
• implement a gRPC API in Blixt for network callbacks (pod network setup/teardown support)
• provide implementations of KNI APIs (none have been defined yet, but speculatively L3/L4 things like IPRoute, TCPRoute)

Doing this could be a great way to support the KNI effort, as it will provide an upstream playground (since we intend to continue to maintain our non-production approach) for us to implement KNI as it develops and try things out, see what works well, and get practical feedback on things that are problematic. It also may put us in a unique position to highlight what interplay there may be between KNI and Gateway API, since there's some possibility for overlap there.

The purpose of this discussion is to get feedback from people in the community to see what level of interest there is in such a thing, and to see if there are people in the community that are particularly interested in jumping in and working on such a thing. Please discuss!

[shaneutt]

Considering this closed for now, as there's no action that can be taken. We can re-open later as needed.