/kind feature
Describe the solution you'd like
Allow user to specify node selector, affinity, anti-affinity, and toleration so that they can control in which node the inference service pods will be scheduled.
The implementation should also allow predictor and transformer to have a different configuration (related to https://github.com/kubeflow/kfserving/issues/666).
It could look something like this
apiVersion: serving.kubeflow.org/v1alpha2
kind: InferenceService
metadata:
name: transformer-cifar10
spec:
default:
predictor:
pytorch:
modelClassName: Net
storageUri: gs://kfserving-samples/models/pytorch/cifar10
nodeSelector:
disktype: ssd
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: kubernetes.io/e2e-az-name
operator: In
values:
- e2e-az1
- e2e-az2
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 1
preference:
matchExpressions:
- key: another-node-label-key
operator: In
values:
- another-node-label-value
tolerations:
- key: "key"
operator: "Exists"
effect: "NoSchedule"
transformer:
custom:
container:
image: gcr.io/kubeflow-ci/kfserving/image-transformer:latest
name: user-container
Anything else you would like to add:
Knative serving has this limitation (https://github.com/knative/serving/issues/1816). Alternatively, it could be implemented in the webhook.
Issue-Label Bot is automatically applying the labels:
| Label | Probability |
| ------------- | ------------- |
| feature | 0.99 |
Please mark this comment with :thumbsup: or :thumbsdown: to give our bot feedback!
Links: app homepage, dashboard and code for this bot.
this is probably best to be implemented in your pod or deployment mutating webhook imo.
@yuzisun Can you explain more? Is it inside kfserving or outside?
@yuzisun: I don't think it's reasonable to expect every user to implement a custom admission controller just to add affinities. It also makes sense to have them as part of the InferenceService, instead of having to define my node requirements for my InferenceService in custom code in a separate admission controller.
@salanki KFServing has been trying to find a right balance between allowing leaking operator fields into our inference service API which is data scientist/developer friendly and this use case definitely hits that, we can discuss what鈥檚 best way to implement this if you can join our WG meeting.
Completely agree with this request.
We actually have this exact same problem with Knative, who made similar restrictions on their API before finally exposing the Pod Template Spec instead of ContainerTemplateSpec.
This is a big API discussion and I think we need to solve it before GA. It would be great to enable the full power of the PodTemplateSpec while simultaneously empowering users with framework specs.
One option would be to use variant interfaces to effectively extend the PodTemplateSpec with some of our magic. We will need to discuss in the working group.
Happy to join a WG meeting and also write up some use cases / examples if it is helpful!
Hi. Any news on this subject?
We are addressing this in our new api v1beta1. Stay tuned.
@salanki @pradithya @dalfos Looks like knative has lifted the restriction now https://github.com/knative/serving/pull/8645/files.
Issue-Label Bot is automatically applying the labels:
| Label | Probability |
| ------------- | ------------- |
| area/inference | 0.68 |
Please mark this comment with :thumbsup: or :thumbsdown: to give our bot feedback!
Links: app homepage, dashboard and code for this bot.
Most helpful comment
@salanki @pradithya @dalfos Looks like knative has lifted the restriction now https://github.com/knative/serving/pull/8645/files.