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
After quite a lot of debugging of Shinyproxy on a K8s + Istio cluster it looks like Shinyproxy itself runs fine, and can launch pods without the kube-sidecar proxy (kubernetes.url: [IP of kubernetes.default.svc.cluster.local] , but it fails to communicate with the child pods since Containerproxy uses either pod IP (for internal networking) or hostIP+servicePort for external networking. Istio mostly requires services.
I've tried a few options, and a quick and dirty workaround could be to define a separate (non-injected) namespace for the child pods, create a ServiceEntry for spec.hosts childnamespace.svc.cluster.local, resolution: DNS, and have an option which acts similarly to internal-networking=false, but uses the service IP address & port, not the host.
To allow full functionality of istio, it'd be preferable to allow an 'istio' option, which would cause pods to be addressed by created services, even when internal-networking is true. I'm certain I don't have the Java skills to submit this request, but I'll give it a go at this end, even if only to help those with real skill get on the right path.
Stuart
The text was updated successfully, but these errors were encountered:
I ran into the same issue, I have managed to make it work with Istio mtls. Feel free to test it out from the fork. You just need to set internal-networking=false. https://github.com/zarrarrana/containerproxy
After quite a lot of debugging of Shinyproxy on a K8s + Istio cluster it looks like Shinyproxy itself runs fine, and can launch pods without the kube-sidecar proxy (kubernetes.url: [IP of kubernetes.default.svc.cluster.local] , but it fails to communicate with the child pods since Containerproxy uses either pod IP (for internal networking) or hostIP+servicePort for external networking. Istio mostly requires services.
I've tried a few options, and a quick and dirty workaround could be to define a separate (non-injected) namespace for the child pods, create a ServiceEntry for spec.hosts childnamespace.svc.cluster.local, resolution: DNS, and have an option which acts similarly to internal-networking=false, but uses the service IP address & port, not the host.
To allow full functionality of istio, it'd be preferable to allow an 'istio' option, which would cause pods to be addressed by created services, even when internal-networking is true. I'm certain I don't have the Java skills to submit this request, but I'll give it a go at this end, even if only to help those with real skill get on the right path.
Stuart
The text was updated successfully, but these errors were encountered: