apiserver-network-proxy
apiserver-network-proxy copied to clipboard
kubernetes-sigs
export server&agent as library to integrate
Hi, thanks for your awesome work first, it is a cool project I think!
I want to ask for any chance about exporting server/agent codes as a library for convenient integration.
The background is that at the edge computing field, the edge nodes may not have public IP or have a low-quality and low-speed network, direct connection to api-server is not a good choice.
Like Kubeedge does, add a tunnel between api-server and edge node to optimize them is common.
After I see this awesome project, I notice that implement this would be a better choice in this case. Then I find that now server or agent can not work as a library, the only way to implement it is to fork and do some change, it is not cool.
Besides, I want to add some feature like multi-agent support, agent discovery and so on, if can not work as a library, I need fork first to reduce some sync work.
I would like to do export thing as well.
@daixiang0 I think the ANP can be applied to your case directly. The tunnel between the ANP agent and the server is set up by the agent, so we don't need to assign a public IP to the agent.
Almost close, I want ANP server/agent work as a library, not a single binary.
I have no objection to making library versions of server and/or agent. We would need to scope what is in each of these libraries. Curious what the difference between pkg/agent and pkg/server and the libraries you have in mind? Also want to mention that as far as Kubernetes goes, the use of the server and agent binaries is outside our control. Multiple SIGs (Architecture, Networking, API Machinery, Node to name a few) would need to be involved in directly embedding the server & agent code in the relevant binaries. After the issues with SSHTunnel, I don't think we are likely to find much appetite for such a change.
For example, I think working as a library still need a func call Run, now it exists in cmd/server, so if I implent it, i need to write some codes to do "run" things, most of them are already done in cmd/server.
I think making library versions do not need breaking change since it only needs to add some export funcs.
I'd like to add that it's actually quite complicated to change this repo into a library because of how go mod works, and also the interactions with konnectivity-client (see https://github.com/kubernetes-sigs/apiserver-network-proxy/issues/62#issuecomment-585446782). We may need to split the repo if we want to go down that path.
I have no objections either but it would be helpful to understand the use case better.
I think it would make sense to break this into two issues, one for server and one for agent. Each is complicated. I do not want to cross the beams, or confuse the issues when we talk about what needs to be done for each one. They can also merge/ship separately.
A Run function sounds ok but we should probably define its inputs, outputs and responsibilities. For example the existing cmd/Server binary listens on 3 sockets. My guess is that the library should only listen on two. Further those two should be configured by some sort of new configuration object we should pass in. However I could also see an argument for letting the called configure/setup the sockets and pass them in. The new upcoming configurable backend manager changes will add yet further complexity to this.
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale
Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.
Send feedback to sig-contributor-experience at kubernetes/community. /lifecycle rotten