Hi, We have worked with other options also. Although they are built on top of k8s/go-client, they don't fulfill completely all use-cases which we require. Anyway using these libraries is better than using raw go-client directly. What we might need is a minimal shim on top of these libraries to use relevant functionality when required. - https://godoc.org/github.com/kubernetes-sigs/controller-runtime/pkg/client - this client is used by all k8s controllers for reconciling and performing other actions. - it can handle structured and unstructured data. see example ( https://godoc.org/github.com/kubernetes-sigs/controller-runtime/pkg/client#e... ) - It has high-level functions and also gives access to raw rest mappers for low-level functionality. - https://github.com/kubernetes-sigs/cluster-api/tree/master/cmd/clusterctl/cl... - there were several helper functions created for cluster API operations in clusterctl. - Much of this functionality we might need but it is not production-ready. - clusterctl is deprecated and clusteradm is introduced instead of this. We don't know how much of this functionality will evolve. - We can reuse some stuff from here while creating our own shim. Br, Kanwar On Fri, Sep 27, 2019 at 2:53 AM Kostiantyn Kalynovskyi < kkalynovskyi@mirantis.com> wrote:
Hello Airship team, in the light of development of Airship v2.0 , we are now coming to the point where we need to interact with deployed kubernetes clusters, ephemeral or target.
So far I have found 2 major options for this communication:
- k8s/go-client library with dynamic client and RESTmapper - we would have to build our own wrapper over it, that would implement some of the kubectl functionality as well as some of kustomize functionality - with this approach, we can develop any input driver of our own, like golang structs, runtime.Object, []bytes, filesystem etc... (i think it is quite a lot of effort) - use k8s/kubectl as a library: - encompasses both *kustomize*, via *FilenameOptions.Kustomize, *and default *kubectl *functionality. - Has limited input capabilities (I think), read from stdin, or directly from filesystem - With this approach we would not care, what resources we are dealing with. - And in the light of development of *airship document *command, we would have to keep those limitations in mind. - *airshipctl document* subcommands would have to filter, for example based on annotations required resources, and simply provide *root directory*, where kustomize starts working, the rest would be done for example by KubeApply.Run() function with correct FilenameOptions.Kustomize flag. - There is a con, kubectl is a cmd tool itself, and sometimes using it as a library maybe be complicated, (not sure about that though)
If someone has any ideas, relevant experience or advice, it would be greatly appreciated, thank you in advance. _______________________________________________ Airship-discuss mailing list Airship-discuss@lists.airshipit.org http://lists.airshipit.org/cgi-bin/mailman/listinfo/airship-discuss