Closed
Description
Given that KubernetesClient is growing in scope and taking on new dependencies, it's becoming a bit monolithic and difficult to maintain and add new features. I propose moving towards a multi-package implementation to provide a-la-carte solution. Consider the following:
- Not every consumer of this library will care about installing CRDs. The PR for CRDs requires schema generation tool, which takes on NJsonSchema dependency, which I may not want in my project.
- Informers Kubernetes implementation would require a dependency on RX, which also can't support .NET 4.5 (netstandard 2.0 minimum)
- It would be great to provide dependency injection registration methods for ServiceCollection
- The autogenerated methods from AutoReset bloat the project size significantly. Especially when used with Informers which rely only on generic method class, the need for autogenerated client methods is removed. Ideally, it would be great to have models in their own project, the client (Kubernetes, IKubernetes, IKubernetesExtensions) in its own project, and core which provides authentication, watch, and cross-cutting capabilities. It would look something like
KubernetesClient.Core
KubernetesClient.Models -> KubernetesClient
KubernetesClient.WebClient
KubernetesClient.CusomResources
KubernetesClient.DependencyInjection
If maintainers are OK with this approach, I can take this on to split it up.