csi-driver-smb VS charts

https://github.com/kubernetes-csi/csi-driver-smb. This is the CSI driver we use.

Actual media storage (movies, pictures, anything that lives on my unRAID box) is mounted to each pod that needs it via the SMB CSI driver. I would love to use NFS instead, but even with 4.x, I was running into stale file mount issues. You can see my findings and why I decided to use SMB instead here

What is the recommended way to use S3 as shared storage for media (videos)? Currently I'm using SAMBA network share RWX volumes using this plugin and I would like to switch to S3 compatible service to increase performance and to avoid my current limit set by my cloud provider on that SAMBA server of 10 active connections for SAMBA.

With SMB I'm using the CSI SMB Driver helm chart to deploy it. When creating the persistent volume I'm able to use some mounting options where I have the following included:

Kubernetes has a native solution for many different storage integrations - CSI. There is a CSI driver for SMB as well. After installing the driver you will be able to map your config files from smb server via regular volume mount and config map.

I mean, in short either find a project that includes support for it (I don't know of one), or look at a CSI that does like the SMB CSI driver.

Using a CSI Plugin you should be able to separate the admin side from the user side. I haven't dove into this but here is a plugin that might help - https://github.com/kubernetes-csi/csi-driver-smb

Look into using flex volumes (though depricated) or its successor SMB CSI driver

Spinning up workloads in kubernetes is much different than just spinning up a container in docker or even with docker compose. If someone has not already packaged it in a helm chart or some other kubernetes workload you'll have to develop one yourself. There are some nice library charts you can use as a base that should handle just about any random docker image you want to deploy. https://github.com/bjw-s/helm-charts/tree/main/charts/library/common there is also a repo of pre developed charts for common images. https://github.com/k8s-at-home/charts but be aware it was recently deprecated so it won't be receiving any updates.

Take a look at https://github.com/k8s-at-home/charts (recently deprecated but still a fantastic resource) - there are charts for the popular Arrs , tools, etc. You could deploy each chart individually into a namespace, or you could create yourself an "umbrella" chart which pulls in all the necessary charts as dependencies.

Library charts. A very thorough example can be seen here and usages of it here.

Could it be related to this? https://github.com/k8s-at-home/charts/pull/1435/files

I'd submitted a helm chart at https://github.com/k8s-at-home/charts/tree/master/charts/stable/firefly-iii if you want to try out

I know /u/stefantigro means well but the way you are both doing the helm charts is not ideal, helm charts are meant to be shared, not as a means to install apps into your cluster from a local folder. While they can be, it's not a good pattern. Take the helm chart from here for example. This is a published helm chart you can install using the commands in the Readme and you only need to provide the configuration for your instance from the values.yaml file. You can take a look at the values I use for this helm chart here. You can also see I'm using an custom Sonarr image, this image is tailored to running in Kubernetes

There is a working Helm chart for k8s-at-home that should be a good starting point. The biggest hurdle I see is that homebridge can conflict with SCALE's mDNS service as seen in this linked post.

There's an actual helm chart published here.