RFC: Implement plugin architecture

[aojea]

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 #1861

There 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" #1780

I have a bash script already for this, running it as a plugin will be straight forward

• kind registry Better UX for using local registry #1213

The 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.

[aojea]

/assign @BenTheElder @neolit123 @munnerz

[BenTheElder]

Why should we add the complexity of a plugin model in kind?
You are free to implement additional commands in external binaries today?

[BenTheElder]

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.

[aojea]

Why should we add the complexity of a plugin model in kind?

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

You are free to implement additional commands in external binaries today?

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 kind and vagrant here, and I think that vagrant plugins were a very great addition to the project to be able to add features without compromising the main development ...

[tao12345666333]

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.

[neolit123]

A new plugin architecture, so new features can be added out of the core, allowing the project to experiment without impacting the stability.

an early plugin model in the project timeline is often a good idea. the maintainers can defer to it.
i've seen it being inevitable in some cases too.

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

it's a pity that golang's native plugin model doesn't work very well, but what kubectl is doing is an OK workaround.

[BenTheElder]

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.

[aojea]

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 plugins as in the kubectl model, for developers are just external and independent binaries, but seems that users find them useful and I feel that this can fill the gap with docs and improve the project UX

[BenTheElder]

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.