-
Notifications
You must be signed in to change notification settings - Fork 469
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Seeking New Maintainers #1715
Comments
Tagging some people that have contributed recently-ish to spread awareness: @elchenberg @brandond @whooo @rkojedzinszky @bhcleek @ncopa @KSauter @BoleynSu |
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days. |
Hi all, we were looking into kube-router a while ago. We discussed the pros and cons of it and still not sure, if we should use it. If you're open to a discussion and we come to the conclusion, that we should go with it, take over some parts might be possible. We run a very special setup with a LXC driven Kubernetes and an external router pair. Within of that Kubernetes, we run customer service, i.e. databases but Kubernetes as well again. Base network is bridged, so the router doesn't really need to know the topology. Customer networks within customer's Kubernetes of course is layered. What we want to achieve:
|
@automaticserver - Thanks for reaching out. Your use-case seems pretty complex and, similar to you, I'm not sure if kube-router is a good fix for you. Feel free to poke around and see how it fits. If you feel like there is a good fit without adding substantial complexity, then we would love for you to be involved in the project. If you end up finding this to be the case, feel free to reach out to me privately on slack. However, the project as it stands now is not at a place where it can accept a sizeable amount of complexity from a large, yet unsupported, use-case. |
Hey there!
As you may or may not know, kube-router essentially only has two active maintainers right now, @mrueg and myself. Many of the older maintainers of this project have unfortunately moved on and @mrueg and myself are starting to have less and less time to work on kube-router ourselves.
That being said, I still think that there is a place for kube-router in the Kubernetes networking space! kube-router has always been a simple, but full featured networking plugin that sits in the control path, and relies on time tested and performant Linux kernel networking components for the data path.
As more and more Kubernetes networking plugins begin to focus on enterprise use-cases and become more complex by relying on eBPF, kube-router has found its niche in small to mid-sized clusters that work across a broad range of Linux distros and versions. That being said, it's still running neck and neck with the big players as seen in the ITNEXT benchmarks from earlier this year.
All in all, I feel like this has served kube-router fairly well, and from what I can tell, via Slack / GitHub / etc. it seems to still be a widely used and valued project. So this seems like a good time to seek more maintainers for the project.
Helpful Background for Maintainers:
If you are interested, please PM me in the Kubernetes slack space (username
@aauren
). We'll start gradually, with a focus on working on existing issues and PR reviews, and then move towards a maintainer role as we get to know each other better.If you're reading this, thanks for being part of the kube-router family and for using the project!
The text was updated successfully, but these errors were encountered: