https://dagster.io/ logo
#deployment-kubernetes
Title
# deployment-kubernetes
a

Adrian Rumpold

06/25/2021, 8:19 AM
I'm trying (and failing) currently, to separate the Dagster server and user code deployments into separate k8s namespaces (use case: UC is pushed from CI pipelines on multiple feature branches, each in their own namespace). Unfortunately this fails due to the
dagster-user-deployments
Helm chart trying to mount the Postgres credentials secret in the UC deployment, which is not possible across namespaces. I haven't looked at the source code for the gRPC daemon used for the user code deployments, but does it really require these credentials? In my naive understanding, the user code gRPC service should be self-contained and only relay information about its contained repository, with execution being a responsibility of the Dagster daemon (as suggested by the architecture diagram in the docs, which don't show a dependency on the DB from the UC deployment). We could potentially get around this issue by syncing the secrets using something like kubed, but I feel that's more of a workaround. Thanks for your help and awesome work!
a

alex

06/25/2021, 2:30 PM
The thing not clearly laid out in the diagram is that the evaluation of user functions for
sensor
and
schedule
s happen in the grpc server and these interact with the instance, requiring access to the runs/events dbs. This is good feedback though on the consequences of the current arrangement.
c

cat

06/29/2021, 3:03 PM
cc @rex who’s worked on the
dagster-user-deployments
chart
🙏🏻 1
a

Adrian Rumpold

06/29/2021, 3:04 PM
Thanks for your clarifications!
r

rex

06/29/2021, 11:10 PM
yeah unfortunately with your current setup, you’ll need to have postgres secrets in each of your namespaces since they can’t be referenced across namespaces like you said