Hey!
So I've been running 2 Octoprint instances to manage my printers for ~2.5 years. I've been also running Kubernetes cluster at home on some Raspberry Pis as my main platform for home automation and home projects for some time now. I wanted to migrate all my home services to k8s but I struggled with my 3D printers and migrating Octoprint - since I have to connect to physical devices it seemed like I need to schedule my application to the node where the printer is connected. I didn't like this idea at all so I decided to do something about it
So I started with 3 objectives:
I wanted to be able to just connect a printer to any usb port of any node in the cluster and the whole setup should just work
I wanted to be able to schedule my Octoprint instances to any node in the cluster, regardless of where the printer is connected
I wanted to be able to have as many printers managed this way as I wanted, and adding new device should be as easy as writing 4 lines of configuration yaml.
Well, I think I can share with you "beta" version of my solution.
KubeSerial is a Kubernetes Operator that monitors your cluster nodes looking for your devices, exposes them over the network in the cluster and schedules your Octoprint instance. It can manage as many printers as you like and creates printer setup only when it's connected - so when you're not printing you won't have Octoprint just waiting there occupying your RPi. Each Octoprint instance is started automatically connected to proper printer - so you don't need to remember or test each time which port is for which printer. It also can expose your Octoprint instance through Ingress under specified domain (like http://ender3.my.home). Take a look at project readme for more examples.
So yeah, I have no idea if anyone will be even interested in this but I though I'll share this as it can make managing multiple printers nice and easy. If anyone is running RPi Kubernetes cluster give it a try and let me know what you think or if you encountered any problems . Install guide is in project readme. Also, if you have some other devices in your workshop (like CNC machines or whatnot) that are managed by software that this could support - I'm open for ideas.
Honestly, I would be careful within this space. From earlier queries, it feels like big players are trying to setup print farm solutions. In my humble opinion big players need to pay for code like this.
If you solve a big-company problem then you should be paid for it, that's all I'm saying.
I'm thinking about print farm solutions for a while, and I think this can be a nice first step, but I let k8s go.
Mainly bcs:
you need to handle the serial port and a webcam too
I don't want anything to kill my printing container (random rebalance...)
what are the other applications that would be useful to run on a printing node, besides the printer app?
I think a generally better direction is:
preinstalled nodes with installed octoprint and docker
octoprint script that can bring up "compute" image if not used/idle
compute image with mqtt customer, and a general interfaced slicer/model generator to not waste idle cpu when we are not printing (kill it when print starts, I want to use bigger hardware than the rpis)
some auto service discovery tool which polls the ip-range for possible running octoprints
some management interface which can show printer states from separate octoprint instances, and can easily navigate between them (maybe show webcam feeds too)
some job balancer for printjobs (I think this is the biggest challenge and this is where the big fishes have problems)
prometheus+graphana bcs everybody loves graphs
So far I worked on the "compute" image, bcs that was a new area which was in fit in my professional career, but I think I will move on this list and maybe build a farm
Believe it or not, Docker grew out of the LXC virtual containers from OpenStack. OpenStack didn't initially have that in the beginning but it was super helpful for people who wanted to drop lots of non-dedicated things to one machine.
I'm thinking that Docker could be the way to go (in agreement here). But then again, one might be able to craft a Juju charm to spin up a printer farm.
But of course, somebody with deep pockets needs to pay for all that sort of stuff. ha
I know the story, the main concern from my side is that when you want a printer, and a controlling hw phisically connected to that printer, you want that hw to run your "print program" as error less as it can. If we decouple/demonize the serial communication, and let a big hw to run the gcode streaming, - and a small program to handle only the serial communication, - we can save money (bcs probably a less efficient hw (e.g. cheaper) can manage our printer), BUT we include networking delay, in a "close to realtime" application which can be bad. Also k8s is running with the mentality that your containers need to stay as stateless as possible, so if we scale up/down a pod, there will be no problem. At the backend side we learned to write scaleable applications, but a printjob has state which sould be managed in realtime without delay, so a reschedule can ruin a 12h print.
This is why I think k8s is not a great tool for this application. Kubernetes is build for a totally different problem set, and we tend to use production grade tools for every problem, I think k8s is not the best alternative for printfarms.
Docker is a good choice in general, but here I think we want dedicated hw to solve the problem, and if we want dedicated hw we don't need to shoot for containers. (Only if we want to utilize that hw when we not print.)
Part of the solution should include capabilities of the printers. Look into OpenStack's Cluster Controller, opc-ua and conversations I've had on here for advertising printer capabilities back to a server-based controller.
I'm in agreement with dedicated hardware, especially in a production setting. Personally I'd do server and node setup and PXE booting maybe. I'm a sys admin by trade so it's probably that talking but heck you could spin and pull down nodes with ease, backups are a breeze, centralised file management with all the nodes connected...
I do like this project though, it's interesting to see it been done this way.
. Install guide is in project readme. Also, if you have some other devices in your workshop (like CNC machines or whatnot) that are managed by software that this could support - I'm open for ideas.