You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Istio is used as a means to encrypt traffic between pods in a namespace. When deployed in a namespace that has istio enabled the supervisors will never become ready as they fail to contact the nimbus service.
Upon further digging it seems istio is not compatible with init containers as istio does some network proxy config in it's own init container before the encryption proxy is started. Which is needed for network traffic.
Therefore the fix for istio would be to move away from init containers and instead pull that logic into the primary container.
The text was updated successfully, but these errors were encountered:
Hey there @chason-choate, thanks for reaching out. Are you talking about running the storm chart? You mention nimbus, so I assume so, but I just want to check that it's what we're talking about here.
Correct I was using helm install my-storm gresearch/storm.
The cluster I was deploying on had istio installed. (I'm not an istio expert so this will likely need some follow-up) The nimbus and zookeeper pods are fine. But the supervisor pods have an init container that are polling nimbus/zookeeper? over the network. In an istio managed cluster this will always fail as istio has not had time to properly setup it's proxy service.
After a bit of research it seems the proposed approach in an istio managed cluster is that the pod will do any initialization work in it's main pod. i.e. poll storm as part of the main container then launch the supervisor process.
But as I type this I think you could also just remove the init container completely and just let the supervisor pod crash loop until it's dependencies are ready. That would allow istio to run it's init container and setup it's proxy while also removing complexity from your chart.
Istio is used as a means to encrypt traffic between pods in a namespace. When deployed in a namespace that has istio enabled the supervisors will never become ready as they fail to contact the nimbus service.
Upon further digging it seems istio is not compatible with init containers as istio does some network proxy config in it's own init container before the encryption proxy is started. Which is needed for network traffic.
Therefore the fix for istio would be to move away from init containers and instead pull that logic into the primary container.
The text was updated successfully, but these errors were encountered: