Add support for running separate workers

[bo0tzz]

(related: #93)

After the next release, Immich will ship as a single container with the API server and the background workers all combined, with the option to selectively enable only some of those for a running container. Ideally the chart would support running an arbitrary amount of immich containers with configuration for which workers to enable. This would for example enable dedicated transcoding workers with hwacceleration passthrough and such.

[djjudas21]

This is an important feature for Kubernetes users. Microservices architecture is best practice for Kube, and running one huge container for everything is wasteful of resources when you have multiple nodes in the cluster.

One of the main things I liked about Immich compared to PhotoPrism is the microservices architecture, so the UI/API doesn't slow down while the app is importing thousands of photos, generating thumbnails, running face recognition, etc.

[bo0tzz]

@djjudas21 note that right now there is nothing stopping you from scaling up the single container to multiple replicas. The only tradeoff is you'll be running multiple copies of the api worker as well, but maybe that's a good thing too?

[djjudas21]

@bo0tzz I don't know enough about the Immich API - is it safe to run multiple replicas without hitting concurrency issues?

[bo0tzz]

Yes, if it wasn't I wouldn't suggest it ;)

[krypton9208]

How can i increase number of replicas by helm values for each deployments/StatefulSets ?

[djjudas21]

@krypton9208 in case you're still stuck on this, you need something like this in your Helm values to run 2 replicas:

server:
  enabled: true
  controller:
    replicas: 2
    strategy: RollingUpdate

[prometheanfire]

Is the server written in such a way that it can run like this?

[bo0tzz]

Yes, as also mentioned upthread.

[djjudas21]

Just to confirm I have been running 2 replicas of the Immich server as per @bo0tzz's recommendation, and it has been working fine for me 👌

[daftu]

Anyone succeeded with autoscaling workers (microservices)?

[anokfireball]

Yes! Check out this pretty stright-forward HPA config based on CPU usage. I've been using it for a while now, it works really well for large ingests. Just make sure you set the degree of parallelism high enough to saturate the resources in whatever your scaling target is.

Of course, this does not only scale the microservices but also the API server. No negative consequence as pointed out by others.

[daftu]

I'm trying to modify my fork of this chart but I'm struggling with setting probles for pod with microservices only. I assume it won't work with /api/server/ping as I'm disabling api for this containers.
Any suggestions?