Kubernetes-client: Create a Quarkus extension

[rhuss]

Not 100% sure what this implies, but it would be awesome if kubernetes-client could work seamlessly with an Quarkus application.

I think this can be done by creating a Quarkus extension.

This story is a good standalone story and would be a good candidate for a GSoC task. Or for anyone interested in learning to write Quarkus extensions ;-)

This would be also a very good basis to transform https://github.com/jvm-operators to Quarkus applications. // @Jiri-Kremser @geoand @iocanel @rohanKanojia

[geoand]

It would definitely be awesome to get the Kubernetes Client to work with Quarkus on native mode!

The simplest approach I think would be to just create the declarations about reflection and whatever else the client does that doesn't work OOTB with native mode.
@gastaldi have you tried the "Quarkus" version of the Latest in native mode perhaps? That would give us an initial idea of what the problems may be.

But I think that having some sort of tighter Kubernetes / Openshift integration should also be something we need to think about.

[gastaldi]

@geoand the only problem I have met so far is that the Jandex index is not present in the kubernetes-client JAR, even after https://github.com/fabric8io/kubernetes-client/commit/7ae4c567763f635140ba60eab9bc679d14f39d9a was merged

[geoand]

Thanks for that info @gastaldi!

[jkremser]

I tried the native image last week with k8s client in version 4.1.1 (not the latest version of the client) and it built fine, but then had some troubles with creating the default k8s client new DefaultKubernetesClient() in run-time.

2019-03-11 10:58:08 ERROR Config:552 - Failed to parse the kubeconfig.
com.fasterxml.jackson.databind.JsonMappingException: No suitable constructor found for type [simple type, class io.fabric8.kubernetes.api.model.Config]: can not instantiate from JSON object (missing default constructor or creator, or perhaps need to add/enable type information?)
 at [Source: java.io.StringReader@7fa718b29df0; line: 1, column: 1]
    at com.fasterxml.jackson.databind.deser.BeanDeserializerBase.deserializeFromObjectUsingNonDefault(BeanDeserializerBase.java:1134)
    at com.fasterxml.jackson.databind.deser.BeanDeserializer.deserializeFromObject(BeanDeserializer.java:298)
    at com.fasterxml.jackson.databind.deser.BeanDeserializer.deserialize(BeanDeserializer.java:133)
    at com.fasterxml.jackson.databind.ObjectMapper._readMapAndClose(ObjectMapper.java:3807)
    at com.fasterxml.jackson.databind.ObjectMapper.readValue(ObjectMapper.java:2797)
    at io.fabric8.kubernetes.client.internal.KubeConfigUtils.parseConfigFromString(KubeConfigUtils.java:45)
    at io.fabric8.kubernetes.client.Config.loadFromKubeconfig(Config.java:466)
    at io.fabric8.kubernetes.client.Config.tryKubeConfig(Config.java:452)
    at io.fabric8.kubernetes.client.Config.autoConfigure(Config.java:204)
    at io.fabric8.kubernetes.client.Config.<init>(Config.java:192)
    at io.fabric8.kubernetes.client.ConfigBuilder.<init>(ConfigBuilder.java:16)
    at io.fabric8.kubernetes.client.ConfigBuilder.<init>(ConfigBuilder.java:13)
    at io.radanalytics.operator.Entrypoint.main(Entrypoint.java:63)

[geoand]

I think making the KubernetesClient SubstrateVM friendly is the first step to doing anything in this space. I know that @iocanel and I have talked about it a little

[rhuss]

@geoand @iocanel I totally agree that SubstrateVM compatibility OOTB (without any extra help by Quarkus) would be a total killer feature for K8s intra-cluster usage (like for operators). Something which would be a clear winner feature over the standard Java K8s client.

I really would love to push hard here, maybe we should ask the Quarkus folks directly with e.g. the error message @Jiri-Kremser found above ?

[Sanne]

Relates to https://github.com/quarkusio/quarkus/issues/1488

[ricardozanini]

Hi! I'm working in a project that would benefit a lot from the Kube client if at least the Config and Authentication features was working OOTB with Quarkus.

The main problem here is in this line:
https://github.com/fabric8io/kubernetes-client/blob/master/kubernetes-client/src/main/java/io/fabric8/kubernetes/client/internal/KubeConfigUtils.java#L40

Is it possible to suggest a PR to parse the file without using reflection? If not, we'll have to manually register for reflection the entire io.fabric8.kubernetes.api.model.Config dependency tree. :(

Another option would to just annotate the entire domain with @RegisterForReflection, like @geoand suggested. :)

[geoand]

Hi, I think @iocanel would agree that the more reflection we can get rid of the better 😎

[ricardozanini]

@geoand @iocanel if this is a yes, I'll start working on it right now. :stuck_out_tongue_closed_eyes:

[geoand]

I would say @iocanel has the final say on this 😉

[ricardozanini]

@geoand many thanks for your help!! Let's wait for @iocanel then. :sunglasses:

[ruromero]

I had the same experience as @ricardozanini Adding a @BuildStep to the BouncyCastle class just raised more errors and I finally had to give up.
So far it seems to be working with the kubernetes-client although I haven't done too fancy things. I must say that depending on how you create the config you must add the flags that @ricardozanini mentioned but that's the magic of GraalVM :smile:

[iocanel]

Parsing the config without reflection sounds good to me.

[stale[bot]]

This issue has been automatically marked as stale because it has not had any activity since 90 days. It will be closed if no further activity occurs within 7 days. Thank you for your contributions!