Istio support

[chason-choate]

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.

[stackedsax]

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.

[chason-choate]

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.