Closed jinserk closed 1 year ago
I found this link (https://github.com/StatCan/daaas/issues/798) that they have a similar issue.
During the deployment in progress, the istio-proxy
is in the status of PodInintializing
, which means the istio layer doesn't being activated in the pod. Thus the egress settings would not work. Is it possible for the model initializer to wait until the istio-proxy
being activated?
Is it related to:
? I've tried this
apiVersion: v1
kind: ConfigMap
metadata:
name: istio-asm-managed
namespace: istio-system
data:
mesh: |-
defaultConfig:
holdApplicationUntilProxyStarts: true
but it doesn't make any changes.
I'm seeing a similar issue on OpenShift (on-prem, using RedHat OpenShift Service Mesh). The example sklearn SeldonDeployment deploys just fine without sidecar injection. With sidecar injection, the classifier-model-initializer
initContainer hangs indefinitely. Seems like it's failing to reach out to the model location.
I also tried adding the holdApplicationUntilProxyStarts
annotation, and didn't have any luck with it either.
There is not much we can do there. The issue is with Istio and side cars as they basically block any outgoing traffic from init containers and we use init containers to fetch the model before the actual inference microservice starts.
There were some solutions I remember from Istio documentation to basically annotate deployments allowing the outgoing traffic but I don't remember exactly where I've seen it.
This will be solved in Core V2 as we do not make use of init containers there.
Closing as answered.
Describe the bug
I'm trying to use GKE private cluster with standard config, with the Anthos service mesh managed profile. However, when I try to deploy "Iris" model for the test, the deployment stuck in calling "storage.googleapis.com":
I used "sidecar injection" with the namespace labeling:
When I don't use "sidecar injection", the deployment was quite successful. But in this case I need to inject the proxy manually to get the accesss to the model API. I wonder if this is the intended operation or not.
To reproduce
Expected behaviour
Deployment should be successful regardless of sidecar injection
Environment
kubectl version
]kubectl get --namespace seldon-system deploy seldon-controller-manager -o yaml | grep seldonio
]Model Details
Refer to the above description