Implement warm worker pool to improve transcode startup time

[mcadam]

Implementation to resolve #10 using an operator.
I separated the operator code and the chart templates as there is now more code than just a script like before. The plex-operator code can be found here https://github.com/mcadam/plex-operator.

For now its really early stages, alpha version still as there are no tests written yet in the operator and it hasn't been tested intensively but it's working.

[onedr0p]

Any documentation, or guide on how to use this would be great @mcadam

[mcadam]

hi @onedr0p I recently just started using the operator again in production, its working well so far. I have 2 repositories with the operator and one with the chart, you can use the one for the chart here: https://github.com/mcadam/kube-plex

I am on a bare metal cluster hosted in Hetzner, I currently have somewhat of a complex configuration to make it work properly, it's not as easy as just helm chart install. As you might know plex doesn't like too much to have the databases sqlite files on a NFS share and its currently the easiest way to get a file system shared across nodes in k8s. So not ideal but what I have these days is kind of done through the helm chart but not all:

• plex server through helm chart, associated to a specific node using node selector on the chart values and using a hostPath as config directory, here you could use an existing PVC claim, just not recommending a NFS mounted point. I prefer hostPath because I have had some reliability problems using Hetzner volume CSI in k8s.
• this one is not done through the helm chart as of now and done manually outside. Also this must be done before starting the helml chart. NFS server mounting the same hostPath used by plex server and is going to be used as a PVC for the transcoder pod to access plex config directory. I know I said its not good to use NFS mounted FS in plex :) but for the transcoder pod it seems to be alright so far as it mostly does READ operation in the transcoder pods and then don't mess the database files. It might need more real world testing to prove this 100% but so far so good.
• in the helm chart, I added a value on the config persistence configuration to be able to specify a different PVC for the transcoder, this is where you would specify the pvc coming from the NFS mentioned earlier.
• and then the rest is automatic through the chart, as in having the operator running, and starting new transcoder pods when needed.
• for the data I use google drive through a daemonset to have it available on every node through hostpath and available to all the transcoder pods. I mount through my own version of Plexdrive with writing possibility but you can use rclone or DriveFS for that.

That's basically it for plex side of things, as I said for now its not that easy to set up and orientated for my use, not very generic and all envs proof Id say :).
I need to put more work on it to maybe include the NFS part of it as I suppose everybody would want to do it that way and being automated as in you just give your config persistence for the "main" plex server that's going to be somewhat fixed either through a PVC forcing it on a specific node or a hostPath like i am doing currently so you get best performance for the server and then the nfs for the transcoder pods from any nodes.
But yeah if you know what you are doing you could replicate my setup with this chart, if you have some issues or questions I am happy to help but don't have much time to automate the chart all the way these days. If i can block some time i might do it but that would be completely random lol

[mcadam]

I suppose the easiest way to get the NFS in there and generic way would be to have a sidecar container pod so you have access to the file system and can use any kind of PVC as usual and being transparent to the user. Meh I might try and finish it this week :)