[Airship-discuss] Airship V2 and interaction with kubernetes

[Kanwar Saad]

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#example-Client--Create
      )
      - 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/clusterdeployer/clusterclient
   - 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 at 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 at lists.airshipit.org
> http://lists.airshipit.org/cgi-bin/mailman/listinfo/airship-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.airshipit.org/pipermail/airship-discuss/attachments/20190930/ca197113/attachment.html>