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

Allow KServe to have its own local gateways for Serverless mode #376

Conversation

israel-hdez
Copy link

Cherry-pick of kserve#3737

These changes introduce the possibility to configure KServe with its own Istio local gateway, to partially decouple KServe from the Knative local gateway.

Typically, it is OK to re-use the already configured Knative local gateway for KServe uses (as long as configs do not conflict). However, there are cases where having a dedicated local gateway for KServe is beneficial. Just to give some examples:
* To have the ability to use strict mTLS in Istio
* To reduce some pressure on the Knative local gateway by having a dedicated gateway deployment (it still would hit Knative gateway, but only once, rather than twice)
* To be able to configure TLS on cluster-local hostnames (Knative support is still experimental)

To have a dedicated Gateway in KServe, similar configurations to Knative are need to be done. At the very least, and if not having a dedicated gateway deployment, a v1/Service and an Istio Gateway resource need to be created for KServe. Such resources would need to be configured in _localGateway_ and _localGatewayService_. KServe still needs to rely on Knative routing for the KSVCs it creates. Thus, after handling an incoming request and resolving its target, it needs to be forwarded to be handled by Knative. This is the reason for introducing a new `knativeLocalGatewayService` in the ConfigMap.

The removed `ingressService` seems to be unused. Apparently, it became unused when the v1alpa1 API of the InferenceServices was deprecated and removed.

Signed-off-by: Edgar Hernández <23639005+israel-hdez@users.noreply.github.com>
@Jooho Jooho mentioned this pull request Jun 13, 2024
Jooho pushed a commit to Jooho/kserve that referenced this pull request Jun 13, 2024
Signed-off-by: jooho lee <jlee@redhat.com>
@Jooho
Copy link

Jooho commented Jun 13, 2024

You need to change overlay inferenceservice configmap as well.

Copy link

openshift-ci bot commented Jun 13, 2024

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: israel-hdez, spolti

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 /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@spolti
Copy link
Member

spolti commented Jun 13, 2024

@Jooho when you comment is addressed, please add lgtm label :)

Signed-off-by: Edgar Hernández <23639005+israel-hdez@users.noreply.github.com>
@israel-hdez
Copy link
Author

I updated the overlay.

@Jooho
Copy link

Jooho commented Jun 21, 2024

/lgtm

@openshift-ci openshift-ci bot added the lgtm label Jun 21, 2024
@openshift-merge-bot openshift-merge-bot bot merged commit 77cb50e into opendatahub-io:release-v0.12.1 Jun 21, 2024
18 checks passed
@israel-hdez israel-hdez deleted the j7924-decouple-gateway-cherry-pick branch June 21, 2024 16:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.

3 participants