-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
RFC: Implement plugin architecture #1986
Comments
/assign @BenTheElder @neolit123 @munnerz |
Why should we add the complexity of a plugin model in kind? |
We've done the plugin model in other projects in the org for sure, but they've had more concrete justification as to why they would just be kind-port-forward. |
I can't see the complexity on the kubectl model, it looks for a binary with a specified name format and it just use it, that is why I'm proposing it , it sounds quite simple ... maybe there are something else I can't see
I can identify some profile of users that are less technical and want to focus more in the app development that will use them, I see a parallelism with |
I understand that this is indeed a use case. If we choose a plugin model similar to kubectl, it seems that we can organize some commands/tools together for use instead of expanding the core. |
an early plugin model in the project timeline is often a good idea. the maintainers can defer to it.
it's a pity that golang's native plugin model doesn't work very well, but what kubectl is doing is an OK workaround. |
Adding plugins is thorny when a project's commands are not final as they live in the same namespace. Third party command clearly don't when you don't implement this. I've implemented the exec model in kubetest and it's not that hard but there we have clear answers to namespacing (each vendor supplies their deployer, and then only testers need unique names), and we have a specific contract from the parent process to fulfill. The golang plugin model is indeed utterly useless, and given that these are already external binaries that share no data, I don't see any reason to treat them as plugins. |
I used the name |
I'd be inclined to revisit this when we declare the project 1.0 / aren't planning to expand functionality upstream. Until then I think it shouldn't be a major blocker for projects to create tools without any native support in kind and this will confuse some users about what things are actually in kind and supported by us / create conflict with future native features. |
What would you like to be added:
A new plugin architecture, so new features can be added out of the core, allowing the project to experiment without impacting the stability.
Why is this needed:
The project main goal and is testing Kubernetes, and stability and performance are critical for this, however, its wide adoption is demanding or bringing new use cases that require adding new features and, sometimes, modify current architecture.
There is a trade off between adding new feature and keeping its performance and stability, that is becoming harder and harder to maintain.
Proposal:
Kubectl has an interesting and simple plugin mechanism, that we can use in KIND.
This will allow users to implement new features, and maintainers to asses the impact before implementing it as part of the main codebase.
Kubectl uses Krew to handle the plugins, for our use case, maybe we should embed it in KIND itself? ...
User Story 1
As a user I have one custom use case that I'd like to support in KIND, however, maintainers doesn't want to implement it because it is very niche
User Story 2
As a user I will be able to expose my applications, but I don't want to follow documented steps, because I like minikube workflow using
minikube tunnel
Examples:
kind port-forward
kind port-forward #1861There are several ways to implement this, but most of them have documented network hacks, bust most of them depend on the operating system. It will not be difficult to aggregate them in a bash script per example.
kind netem
"[Feature] KIND support for external network emulation: latency, bandwidth constraint, packet drops" #1780I have a bash script already for this, running it as a plugin will be straight forward
kind registry
Better UX for using local registry #1213The local registry is a very common request that we already have a solution, making it a plugin will allow it to make it easier to use and also, to support new features.
The text was updated successfully, but these errors were encountered: