Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Istio support #78

Open
chason-choate opened this issue Jul 29, 2022 · 2 comments
Open

Istio support #78

chason-choate opened this issue Jul 29, 2022 · 2 comments

Comments

@chason-choate
Copy link

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
Copy link
Contributor

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
Copy link
Author

chason-choate commented Aug 5, 2022

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants