This message was deleted.
# rke2
a
This message was deleted.
c
You would have to base64 the local chart tgz into the spec.chartContent field. Otherwise the job pod that runs the helm operation has no way to access the chart off your 'local' filesystem.
r
I was successful with that approach but noticed the crd was being edited during the cluster install. Is this expected?
c
Which CRD? Or do you mean the HelmChart CR that you're using to install your local chart?
đź‘Ť 1
HelmChart CRs that are in the manifests directory during startup will be edited on startup to inject cluster configuration. That's how we pass cluster configuration values to our bundled charts. That could probably be called out in the docs.
r
I also want to say that I saw issues with this approach with Weave which caused me to go another route, but that was about 6 months ago.
Anyways, now we are just using
helm template
to convert 2 helm charts, Weave and Docker Registry. I tried this approach with Certificate Manager although it silently fails to install. The CRD's are created but the pods are not listed. I am able to helm install it and deploy it using
kubectl apply
on the manifest files that I placed in the manifest directory. Ranchers documentation says that manifests are deployed "similar to
kubectl apply
". Are there any differences between
kubectl apply
and Ranchers approach that should be noted?
c
Ah. If you're using
helm template
to flatten the charts to manifests and then just dropping those in the manifests dir you should be fine. We only touch things that contain a HelmChart resource. It is pretty much the same as just running an apply in a retry loop. Check the service logs and
kubectl describe addon
output for errors.
Are you sure that the flattened manifests include the CRDs? Sometimes you need to give
helm template
extra CLI flags to get them included.
r
I am pretty sure the flattened manifests include the CRDs. I'll look into it, but everything works fine using
kubectl apply
. By service logs do you mean the service that I am attempting to start? I'll check
kubectl describe addon
but are there any other logs that you would recommend looking at other than the rke2 systemd logs?
kubectl describe addon
listed the CRDs that I would expect that relate to the service but nothing else that was relevant. The expected pods don't show up when running
kubectl get pods --all-namespaces
. When I delete the CRDs, then run
kubectl apply <service manifest files dir> --recursive
everything comes up as expected. Maybe I need to look into the
--recursive
option more based on the way rke2 is "running apply in a retry loop".
c
So, one of the caveats of the manifests directory is that the AddOn name is based on the file basename. If you have multiple directories in there, and there are any duplicate filenames across those directories, you probably won’t get the behavior you’re looking for.
I would probably recommend templating to a single file per chart, rather than templating to a directory of multiple files
r
There are definitely duplicate filenames. Ill look into templating them to a single file.
That ended up solving the issue, thanks!