Closed DnPlas closed 10 months ago
Thank you for reporting us your feedback!
The internal ticket has been created: https://warthogs.atlassian.net/browse/KF-5050.
This message was autogenerated
This issue can be workaround by adding the right annotations to the Pod
that eventually gets created via the InferenceService
definition. Something like this should help:
apiVersion: "serving.kserve.io/v1beta1"
kind: "InferenceService"
metadata:
name: "sklearn-iris-workaround"
annotations:
traffic.sidecar.istio.io/excludeOutboundIPRanges: "0.0.0.0/0"
spec:
...
This workaround is provided in the official documentation and has also been tested in upstream https://github.com/kubeflow/manifests/issues/2014#issuecomment-1036168983.
Please note this is a workaround and a real solution should be something that applies to any workload, this effort will be tracked in #356
Closing this issue, since we tested the ISVC. As mentioned above we can then proceed with evaluating Charming kyverno in the future.
What needs to get done
Because of the Istio CNI plugin limitations, the Kserve InferenceServices (
ISVC
) may be affected by the network configuration, as eachISVC
has astorage-initializer
init-container, which executes this code, which may require network connectivity.NOTE: this scenario is possible for other workloads, not just ISVCs, so the actual solution should be generic enough to cover all.
This task requires us to create a Kserve InferenceService inside an Istio mesh with the Istio CNI plugin enabled. Since it will most likely produce an error, we need to provide a solution and document it. An option for fixing this could be to add annotations as described here to all workload Pods, which will require us to change several components controllers/mutatingwebhookconfigs.
Relevant logs
DOD:
Why it needs to get done
To avoid potential issues when we enable the Istio CNI plugin.