What I would have wished to know
Jellyfin is a wonderful tool, to stream and watch legal Linux distros for the whole family. It features basic authentication, a library management, account based remembering of what was last watched and more. As a software engineer that mostly works in and on cloud environments, my logical conclusion was to self-host it on a self-built, bare-metal Kubernetes cluster which, add that point, did not event exist yet. Is Jellyfin cloud-native? No. Is it built to be deployed in such an environment? No. Does it make sense to host it there? Barely. I did it anyway and here’s how.
TL:DR
I don’t want to bore you with a long preamble about how great this post is or how my late great-grandmother baked fresh Kubernetes pods in her old cast-iron pot over an open flame. So this section is for all of you who just want a quick solution.
Just use host-path volume mounting.
If there is anything you should take with you from this post, it is that. You probably want some kind of hardware acceleration, so will have to bind it to a node with a GPU anyway. So might as well bind needed volumes, like config and media folders, as host-path as well. Even if you have a Ceph setup running, you still want some form of GPU connected to that thing, otherwise 4K, or even multiple HD streams, are gonna be a pain.
Here are my deployment files for the really impatient:
Configuration
Jellyfin, as well as the *arr stack, use a combination of files and an SQLite database to store their configuration. Configuration should be persistent, because otherwise, the apps must be setup each time a pod crashes or is evicted or what have you.
In my first setup I used Samba. Yes, I now know that that was wrong, but I didn’t then. So I setup a Samba server on a machine in my local network. Since its a network share, I also thought that Jellyfin can run anywhere, even on my remote server in a data-center somewhere in Germany, so no node-selector. Then the first roadblock hit me. My ISP blocks outgoing Samba ports. A very good decision on their side, but annoying on mine. A colleague of mine, which I asked for advice in this regard, then told me that I am a maniac and suggested an NFS share and a VPN.
So onward to my second attempt. I replaced the Samba share with an NFS one and setup Wireguard between my server and my notebook local home node which incidentally has a GPU. That worked and all was well. Until I noticed very quickly that SQLite database do not like network file systems at all and they lock-up rather quickly which is a problem underlined by this StackOverflow post: https://stackoverflow.com/a/9962003
“Then I will try Postgres!”, I thought, digging my hole even deeper. The *arr stack can deal with Postgres and even has documentation on how to connect with it. Which worked great at first. Jellyfin, on the other hand, is still working on implementing such a feature. At least at the time of writing. I tried checking out the repository and implementing that myself but the SQLite code was really interwoven and the work to refactor that was midway. So nothing I could do in a limited time-frame. I do want to note their efforts in that regard and I am thrilled for the future. As far as I could tell, they are doing fine work.
The following SQLite lock-ups that slowed down Jellyfin were the final nail in my “i want to do everything cloud-style”-coffin. So I re-deployed Jellyfin using host-paths, directly mounting the folders from my node into the pod and specifying a nodeName, so that it is always deployed on the correct node. As mentioned previously, it turned out that I needed that anyway to enable hardware acceleration.
Since Jellyfin was now running on a fixed node with host-path volumes, I also switched my *arr deployments to host path as well. It saves me the trouble of maintaining a database and it increases the overall performance, since file pointer, -requests, -copies, -whatever, do not have to go through a network layer.
And that was my story of how I fought, and lost, the war with trying to compete with Netflix. I hope you enjoyed the read.
