Unable to install in MicroK8s/Kubernetes 1.18: unable to recognize "": no matches for kind "Deployment" in version "apps/v1beta1"

[ceefour]

ceefour@amanah:~/project/fusionauth-trial$ sudo microk8s helm3 repo add fusionauth https://fusionauth.github.io/charts

ceefour@amanah:~/project/fusionauth-trial$ sudo microk8s helm3 install -v5 fusionauth fusionauth/fusionauth
I0414 15:18:28.311174    2962 discovery.go:214] Invalidating discovery information
Error: unable to build kubernetes objects from release manifest: [unable to recognize "": no matches for kind "Deployment" in version "apps/v1beta1", unable to recognize "": no matches for kind "StatefulSet" in version "apps/v1beta1", unable to recognize "": no matches for kind "StatefulSet" in version "apps/v1beta2"]

$ kubectl version
Client Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.1", GitCommit:"7879fc12a63337efff607952a323df90cdc7a335", GitTreeState:"clean", BuildDate:"2020-04-08T17:38:50Z", GoVersion:"go1.13.9", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.0", GitCommit:"9e991415386e4cf155a24b1da15becaa390438d8", GitTreeState:"clean", BuildDate:"2020-03-25T14:50:46Z", GoVersion:"go1.13.8", Compiler:"gc", Platform:"linux/amd64"}

$ sudo microk8s helm3 version
version.BuildInfo{Version:"v3.0.2", GitCommit:"19e47ee3283ae98139d98460de796c1be1e3975f", GitTreeState:"clean", GoVersion:"go1.13.5"}

Seems to be caused by newer Kubernetes (1.18) not accepting resource versions apps/v1beta1 and apps/v1beta2.

[bennycooly]

I have the same issue here. It looks like this helm chart is using old chart versions of ElasticSearch and Postgres. I had to manually download the chart (helm pull fusionauth/fusionauth) and then regenerate the requirements lock file in order for it to pull the updated chart dependencies. It looks like there's a mismatch between the requirements file and the requirements lock file. Newer versions of the ElasticSearch chart should be working with Helm 3 even though they don't explicitly support it.

I also had to update the values once the newer ElasticSearch chart was pulled in:

elasticsearch:
  clusterName: fusionauth-elasticsearch

search:
  host: fusionauth-elasticsearch-master

[drpebcak]

Unfortunately FusionAuth only officially supports this old version of ES - FusionAuth/fusionauth-issues#199

Once that ticket is complete we can update the version pulled into this chart.

As far as the lock goes, that probably shouldn't be committed to this repo.

[bennycooly]

Unfortunately FusionAuth only officially supports this old version of ES - FusionAuth/fusionauth-issues#199

The ElasticSearch chart version supports 6.8.x versions though: https://github.com/elastic/helm-charts/tree/master/elasticsearch#compatibility

Can FusionAuth use the updated Helm charts from ElasticSearch but just use the 6.x image tag? The issue is that the older Helm charts are not compatible with Kubernetes 1.18.x

[ceefour]

@drpebcak By "wontfix" does this mean the helm chart is unusable in currently? If this issue will be resolved in the future I think it should stay open?

[drpebcak]

I personally do not recommend using the embedded dependencies. I think best practice would be setting elasticsearch and postgresql externally, using something like the elasticsearch operator and the postgresql helm chart (or even something external like RDS) yourself so that you can control the persistent layer outside of the essentially stateless fusionauth app.

I think that having the dependencies embedded is not something we should try to maintain longterm, and so the end goal will be to remove those external charts instead of trying to keep them updated all the time.

[drpebcak]

If you deploy your own elasticsearch and postgresql, this chart works on 1.18 by the way. It's just those external deps that don't.

[ceefour]

I personally do not recommend using the embedded dependencies. I think best practice would be setting elasticsearch and postgresql externally, using something like the elasticsearch operator and the postgresql helm chart (or even something external like RDS) yourself so that you can control the persistent layer outside of the essentially stateless fusionauth app.

I think that having the dependencies embedded is not something we should try to maintain longterm, and so the end goal will be to remove those external charts instead of trying to keep them updated all the time.

@drpebcak I agree with you on this on the long term. PostgreSQL and Elasticsearch will be moved into README/docs that quickly review how to install their respective charts, with links to their own chart documentation (for Elasticsearch specifically, a link/nod to Elastic Cloud will make Elastic happier). Then we describe how to configure fusionauth chart with required URI/credentials for these external dependencies.

[ceefour]

@drpebcak is there README/docs on how to use this chart without "including" PostgreSQL/Elasticsearch?

[drpebcak]

The values.yaml vaguely describes it:
https://github.com/FusionAuth/charts/blob/master/chart/values.yaml#L8
https://github.com/FusionAuth/charts/blob/master/chart/values.yaml#L15

If you think that could be expanded upon, I would welcome the PR.

[bennycooly]

I am totally for not including dependencies with the chart, but I was pointing out that since the current version of the Helm chart does include the dependencies and specifies the version for those dependencies, it may be beneficial to update the lock file so that they match.

[drpebcak]

Removing the dependencies has actually already been done in master now, it just hasn't been released quite yet. I'm going to release 0.4.0 in the next day or so which will contain that.