[cherry-pick] Prevent the PassthroughCluster for clients in the service mesh #369
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The KServe Ingress VirtualServices are created with configurations targeting only the Gateways. Although this works, the omission of the Istio sidecars has the following downsides for workloads that belong to the Istio mesh: * Requests to InferenceServices will be treated as going to external services (i.e. not part of the mesh), because the sidecars are unaware of the routing rules. * In consequence, the requests will be hanlded as with any external (non-mesh) workload: the ingress gateway will first receive the request and will forward it to itself doing the URL rewrite to the relevant -predictor, -explainer or -transformer hostname. Such forwarding can be avoided (for mesh-workloads) and the rewrite can be performed by the sidecars with the right VirtualService configuration. This is adding the missing configurations in the KServe-created VirtualService, so that Istio sidecars are aware of the KServe services/hostnames and do the rewrite in the sidecar, rather than delaying/deferring the rewrite to the Gateway. For workloads that belong to the mesh, slightly better performance may be seen (given one request forwarding is saved) and better observability from Istio may also be possible. Signed-off-by: Edgar Hernández <[email protected]>
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: Jooho The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Jooho
pushed a commit
to Jooho/kserve
that referenced
this pull request
Jun 6, 2024
Signed-off-by: jooho lee <[email protected]>
|
Do not merge this PR until other PRs are ready. |
Closed
|
/hold |
|
The upstream PR is merged so we don't need this cherry pick |
openshift-merge-bot bot
added a commit
that referenced
this pull request
Jun 13, 2024
cherry-pick(#369) and fix conflict
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What this PR does / why we need it:
Because we are short on time, we cherry-pick upstream PRs.(kserve#3711)
Which issue(s) this PR fixes (optional, in
fixes #<issue number>(, fixes #<issue_number>, ...)format, will close the issue(s) when PR gets merged):Fixes #
Type of changes
Please delete options that are not relevant.
Feature/Issue validation/testing:
Please describe the tests that you ran to verify your changes and relevant result summary. Provide instructions so it can be reproduced.
Please also list any relevant details for your test configuration.
Loopy Setup
refer this doc
Install Kserve with a new manifests
Deploy sample sklearn model
Check
if there is
meshin the [], it succeeds.Special notes for your reviewer:
Checklist:
Release note:
Re-running failed tests
/rerun-all- rerun all failed workflows./rerun-workflow <workflow name>- rerun a specific failed workflow. Only one workflow name can be specified. Multiple /rerun-workflow commands are allowed per comment.