Interesting note for Istio users: if you use `isti...
# deployment-kubernetes
w
Interesting note for Istio users: if you use
istio-proxy
sidecar containers, your
check-db-ready
init containers in dagit/daemon will probably hang because they don’t have network connectivity to other pods yet. I haven’t figured out a way around this yet, but I think it’s important to note here given the popularity of Istio for service meshes in k8s.
If anyone has any tips on how to get around this, lmk please!
Perhaps the db readiness logic should simply be moved to the application itself. If dagit/daemon cannot reach the db, the pod would not move into a ready state.
n
There is Yet Another "DAG of Containers" In Each Pod proposal up now
People keep trying to write keps for it and sig-node keeps saying "no, this is too complex for the kubelet"
w
Yes… I’ve seen such KEPs.
@Noah K any tips in the meantime though?
n
Not really 😞 It's just one of those things. Patch out the initContainer
w
Yea looks like we’ll just have to fork the dagster chart. 😛
n
1) community helm charts are bad don't use them 2) you can use a post render filter plus kustomize if you don't want to follow step 1 🙂
👍 1
w
Ah right, I forgot about kustomize. Thanks!
n
Technically post render filters can be any script, kustomize is just an easy one to slot in there
👍 1