OTA TV to Plex - Part 3

As with all homelabs, mine's constantly shifting and evolving [...and expanding]  to meet the needs that I have for it. When I originally setup a K3s cluster, my goal was to learn K3s/K8s, but I didn't have a good purpose for the cluster, so it sat for like a week(month?) just idling. Then a friend of mine pointed me at Tdarr for video transcoding, and it occurred to me that Tdarr could replace the script that I had for manual transcoding with some tweaks. 

Mainly the issue I was running into with the transcoding script at that time was that it was running  on a piece of older hardware, and the time it took often exceeded 12 hours for each run. Given that it was usually trying to transcode more then 1 episode ( I like Bob's Bugers as well, and I wanted it, so NYAH) and each episode was taking 2-4 hours to convert from MPEG-2 to H.264.  

This lead to me to think "distributed transcoding? well it wont make the transcode faster, but it'll make the overall process faster...hopefully". So I started experimenting with putting Tdarr on my cluster. 

One of the early issues I ran into is the conversion from a docker based deployment to a K3s deployment. Since Tdarr was designed to be in a docker container, it could depend on local storage for data sharing and explicitly states that some of the mount points must overlap between the "server" instances and the "node" instances. K8s does not come with a local directory storage, and is actively discouraged for most deployments. K3s does come with a local storage provisioner, but that means that I must run all Tdarr node instances on the same K3s node, which is basically what I was already doing. After testing several attempts, I settled into an NFS share against an SSD, which isn't as fast as a direct access to a drive, but is fast enough to not slow down the trancode process (much). 

Another issue that arose a little later( after an attempt to update a node on the cluster), was that in early deployments, I let K3s handle scheduling the Tdarr node instances with out restrictions. This lead to multiple instances of the Tdarr node being assigned to the same K3s node, which ended up locking up the node for hours as the containers competed for the same CPU. After much tinkering and a random glance at the Traefik service deployments, I found out that by adding a "podAntiAffinity" setup to the deployment, I [finally] could tell K3s that I want the Tdarr node instances deployed on different K8s nodes. 

The script still needs to run, but it's now regulated to just the moving of the now-transcoded files.