2023 kpng update

[jay vyas]

Hey folks !  

We want to make sure new contributors who havent been following all the jumping around we've been doing w/ kube proxy v2 / kpng / etc, know where thigns are headed so : 

TLDR 

- a few months ago, we decided we would try to try to make kpng into an adapter that could go into /staging or in-tree

- but were backing out of that (for now) 

- b/c its just too complicated to deal w/ and dan is building a new NFT proxy impl in tree 

In other words, KPNG is like a hacking play w/ kube proxy and make a new implementation that's out of tree and vendorable... but not released officially by the Sig... and the in-tree proxy remains a linux-focused, in memory, sig-network officially released repo.  

DETAILS 

A FEW MONTHS AGO , tim made the "kpng layering thoughts" slides, about an idea to make a kpng  that decouples people making new proxies from the innards of the k8s api... 

- put a "adapter" in-tree for building new proxies that evolved from the diffstore implementation in KPNG

- retool kpng based proxies on top of that type of adapter, and allow people to

import it from staging to build their own proxies.

CURRENTLY, as a Sig, the confusion around us having 2 separate kube proxy implementations/initiatives has put us in a situation where we really need to be explicit about where things are headed.  

For the most part: 

- The new NFT work that is ongoing in kube proxy https://github.com/kubernetes/enhancements/pull/3824 is the "main thing" that is going to modernize it in the near term.  It'll have some cleanup in it.   Some of that might even pave the way for a library like experience in the near future (which many folks want 

- Per antonio, feedback such as https://github.com/kubernetes/kubernetes/issues/92369#issuecomment-1422289047 , indicates that someday, we do really want a adapter of some sort that reads and aggregates the K8s objects esp for complex things like topology - but that work isnt going to be coupled to the NFT work, which is refactoring things from the bottom up. 

- KPNG remains an easily approachable internal sig-network hangout group (i'd say, that at this point, thats actually the major role that it plays in the sig), and a  new way to build proxies that can run in any language, and use GRPC as opposed to an in-memory representation.  Its not officially "the next generation kube proxy", though (there are major architectural opinions in KPNG which arent easily adopted to a broader/generic audience , and after 3 KEPS, we figured, maybe we should just be a "friday hack around w/ kube proxy" group. 

So I think guidance to new folks in the sig: 

- if folks want to contribute to the kube proxy , in-tree, a great  thing to do is check out the NFT kep https://github.com/kubernetes/enhancements/pull/3824, and reach out to Dan, who will be owning that effort.  That is where the production code will live.  

- If folks want to hang out and play around w/ a GRPC based kube proxy, or build your own kube proxies right now without having to vendor all of the K8s API ,  we definetly have KPNG that you can use, and right now - it's the only solution that exists  - but its not an official solution (i.e. you have to compile / vendor it yourself, it doesnt have formal releases and so on).   The only support youll get is  - - posting in the sig-network-kpng channel or else, coming to our friday hangouts.   

PS We have a new https://github.com/kubernetes-sigs/windows-service-proxy repo that were proving out over time, and we'd love folks to help us on that front as well... Reach out to me, amim, or mark rosetti if you want to help there. 

 

... Oh and BTW sometimes on the KPNG hangouts we listen to viking music. ....

[Dan Winship]

On 3/18/23 13:40, jay vyas wrote:
> - b/c its just too complicated to deal w/ and dan is building a new NFT
> proxy impl in tree

("nftables" not "NFT". The command-line binary is named "nft", but the
technology is usually called "nftables". And plus "NFT" is kind of
ruined forever as an acronym... :-)

> officially by the Sig... and the in-tree proxy remains a linux-focused,
> in memory, sig-network officially released repo.  

(It is only "linux-focused" in the same way that all of kubernetes is
when there isn't steady input from sig-windows. But it is the official
service proxy implementation for both Linux and Windows.)

> Its not officially "the next generation kube proxy", though (there
> are major architectural opinions in KPNG which arent easily adopted to a
> broader/generic audience , and after 3 KEPS, we figured, maybe we should
> just be a "friday hack around w/ kube proxy" group. 

To be clear, the SIG has never formally said that it doesn't like KPNG's
architecture or that it isn't appropriate for a broader/generic
audience. It's just that the SIG has never fully considered that
question, because the original KEP was never completed.

> PS We have a
> new https://github.com/kubernetes-sigs/windows-service-proxy repo that
> were proving out over time, and we'd love folks to help us on that front
> as well...

Again, to be clear, this is not a project that has been formally
proposed to SIG Network (or AFAIK, SIG Windows). If you are hoping for
this to eventually become the new official windows proxy, it would be
good to have a solid plan (in the form of a KEP) about how that is going
to happen before too much code gets written.

-- Dan

[jay vyas]

Definitely supportive of anyone who wants to write a KEP.  For us, we are still in a prototyping phase here (but of course, i see your point about planning before prototyping, i just tend to look at it the opposite way: Prototype it so you know it works, and then do the paperwork afterwards).

Of course, touche' this approach of "doing the paperwork last" doesnt always work out that well :)... But,,, well.... we'll learn from the past and try to "do the paperwork a little earlier" next time i think :)