StatefulSet vs Deployment

[eric-pierre]

Hi!

I will confess being completly new to CubeJs, which is why my question may sound profoundly ignorant, but I was wondering whether the worker and router pods could be scheduled via a Deployment instead of a StatefulSet? What would be the consequence?

Thanks for your kind help!

[lvauvillier]

Hi @eric-pierre,

We require a StatefulSet because we deploy a headless service, allowing worker instances to receive stable names to communicate each other and declared to the router.

More info here:
https://kubernetes.io/docs/concepts/services-networking/service/#headless-services

Router registration:
https://github.com/gadsme/charts/blob/main/charts/cubestore/templates/router/statefulset.yaml#L83

Worker registration:
https://github.com/gadsme/charts/blob/main/charts/cubestore/templates/workers/statefulset.yaml#L70

[eric-pierre]

Thank you so much for your kind elaboration- Just as a follow up- Could we use a regular service instead of headless? Again I apologize if this is a silly question!

…

On Wed, Apr 10, 2024 at 4:47 AM Luc Vauvillier ***@***.***> wrote: Hi @eric-pierre <https://github.com/eric-pierre>, We require a StatefulSet because we deploy a headless service, allowing worker instances to receive stable names to communicate each other and declared to the router. More info here: https://kubernetes.io/docs/concepts/services-networking/service/#headless-services Router registration: https://github.com/gadsme/charts/blob/main/charts/cubestore/templates/router/statefulset.yaml#L83 Worker registration: https://github.com/gadsme/charts/blob/main/charts/cubestore/templates/workers/statefulset.yaml#L70 — Reply to this email directly, view it on GitHub <#44 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AALWNWS4NMOBFCN7I3GKFYLY4T4DZAVCNFSM6AAAAABF7HML7GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANBWHEZTEMRQHA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[lvauvillier]

The CUBESTORE_WORKERS environment variable is required to communicate with all declared workers. Therefore, we require a list of DNS names that provides direct access to all worker pods.

We opt for a headless service in this scenario because we wish to avoid using a load balancer. The goal is to enable communication between individual pods while ensuring stable network identities and DNS-based service discovery.

[eric-pierre]

Thanks! This helps a lot! If I were to use a regular service, I could essentially configure the router to point to it, and let the LB worry about the actual routing. I think that would work, unless the router needs to know about the individual worker instances- This is where my knowledge of CubeJS fails me.

…

On Wed, Apr 10, 2024 at 9:26 AM Luc Vauvillier ***@***.***> wrote: Yes, you can if you write your own files and manually set the CUBESTORE_WORKERSenv var. But in the context of this chart this is the only way i found to properly generate list of stable pod dns names from a simple workers.workersCount config. — Reply to this email directly, view it on GitHub <#44 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AALWNWX7MZMOZ7TIVA7T55DY4U4X7AVCNFSM6AAAAABF7HML7GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANBXGU2DENJUGA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[lvauvillier]

I updated my previous comment. When using a load balancer, the CUBESTORE_WORKERS value becomes a single entry point. However, CubeStore requires direct access to each individual pod.

You can look at the CUBESTORE_WORKERS value in the docker-compose example here:
https://cube.dev/docs/product/caching/running-in-production