akri VS charts

akri: AdmissionErrors and if it actually mounts something the process cant access the device for some reason.

If you're talking about hardware attached to nodes, Akri might be of interest: https://github.com/project-akri/akri

Fun hands on use-case/story. Trying to connect sensors & actuators sounds fun! It's clear that they need some kind of infra/platform that they can run on-prem, & this feels like a lock.

There's a new Dynamic Resource api in k8s 1.26 that feels potentially well suited to managing their various kinds of node-attached resources in a pretty broad/generic/cloudy way. Taking the cloud from anonymous compute/storage nodes to an all encompassing management system for whatever we have is an interesting next step. I rather doubt we'll see folks like this spend the 3x effort to pioneer use of these abstractions but over time it should start to emerge & become more regular. https://kubernetes.io/docs/concepts/scheduling-eviction/dyna...

There's also a really neat really nice CNCF Sandbox project Akri which performs semi-similar-ish functions as Dynamic Resources. One of the examples they use as a goto is managing a fleet of OVNIF cameras, like, security cameras. https://github.com/project-akri/akri

On another topic, appreciate this article talking about the mixed human/robot workflows. Good to consider! I worked at a great & interesting data-warehouse company a long time ago that had some very complex long running ETL pipelines & limited compute resources (good number of boxes... pre-cloud era!), and a lot of time-sensitivity. The company used Jira to manage the ETL end to end, with custom workflows where work would gate, process, get checked through various stages, with processors updating the ticket as work advanced or to report % complete. Intensely sharp choice not to build it ourselves, to use a tool for tracking work, even though the code (robots) we built were doing 9/10ths the work. Fun to see a similar topic discussed here.

Good problem setup, interesting view here. Would appreciate a little more technical specifics, but still fun to see.

You need something to act as the runner queue to schedule the nodes, so perhaps you could pull them into a k8s cluster and auto-scale oh the load queue. Using something like this to tag the nodes what special devices might be attached on certain nodes https://github.com/deislabs/akri

Some notes on Plex/Emby/Kodi and transcoding. If you want true transcoding with GPU acceleration, you have to have Nvidia GPU or be a k8s device plugin genius. The whole idea of mounting elastic devices in k8s is fairly new and rather complex. In the mean time transcoding is best done on a beefy device with a proper CPU (eg i7) or specifically Nvidia GPU because there are numerous pre-made plugins. I just run Plex and Emby on an old ATX gaming machine without GPU acceleration and it works totally fine. They were barely usable for just me when running on the RPis, wouldn't recommend it unless you can figure out how to mount the correct devices in the pod using a custom raspberry pi device plugin . . . lol good luck! - Arm labs device manager: https://community.arm.com/developer/research/b/articles/posts/a-smarter-device-manager-for-kubernetes-on-the-edge - Deis labs Akri device manager: https://github.com/deislabs/akri - Nvidia GPU plugin: https://github.com/NVIDIA/k8s-device-plugin

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.