SIG CLI KEP FAQ
Why not as a kubectl plugin instead of compiled in?
- The kubectl plugin mechanism does not provide a solution for distribution. Because the functionality is intended as the project's solution to issues within kubectl, we want it to be available to users of kubectl without additional steps. Having users manually download only Kustomize as a plugin might be ok, but it won't scale as a good approach as the set of commands grows.
- The effort to build and test the tool for all targets, develop a release process, etc. would be much higher for SIG CLI, also, and it would exacerbate kubectl's version-skew challenges.
- It will not support integration at more than a surface level - such as into the resource builder
(which does not offer a plugin mechanism).
- It was previously decided we didn't want to add a plugin mechanism to the resource builder. This could be reconsidered, but would need to think through it more and figure out how to address previously brought up issues. There may be other issues not listed here as well.
- There is a risk that publishing each command as a separately built binary could cause the aggregate download size of the toolset to balloon. The kubectl binary is 52M and the kustomize binary is 31M. (extrapolate to 30+ commands x 30MB). Before going down this route, we should consider how to we might want to design a solution and the tradeoffs.