Closed jlewi closed 4 years ago
/cc @karthikv2k @r2d4
Using a service mesh for routing would preclude fairing from deploying on vanilla Kubernetes clusters then. Is that ok?
@r2d4 You raise a good point; I hadn't thought about that.
Could we add an option to set the service type?
We've generally tried to follow a policy in Kubeflow of not exposing ports by default because its unsafe (e.g. kubeflow/kubeflow#123).
I think we should continue to follow that and try to figure out how to handle other cases as needed.
Related to that, I plan on filing an issue to add mesh routing rules so the services can be accessed via the ingress configured for Kubeflow.
@karthikv2k What is the plan for 0.6?
We don't have cycles to fix it in 0.6.
This should be enhanced in #376 , closing the ticket.
Issue-Label Bot is automatically applying the labels:
Label | Probability |
---|---|
feature | 0.84 |
Please mark this comment with :thumbsup: or :thumbsdown: to give our bot feedback! Links: app homepage, dashboard and code for this bot.
Issue-Label Bot is automatically applying the labels:
Label | Probability |
---|---|
feature | 0.84 |
Please mark this comment with :thumbsup: or :thumbsdown: to give our bot feedback! Links: app homepage, dashboard and code for this bot.
It looks like by default when you deploy with fairing you create a service of type loadbalancer https://github.com/kubeflow/fairing/blob/642530567d0255f88b0f83b0a40b3325c303bfa2/fairing/deployers/serving/serving.py#L79
This exposes the model on a public endpoint by default.
In general we want to avoid making services publicly available. Especially for fairing since the target audience (datascientists) may not know the security implications of doing so.
By default we should use ClusterIP.
To make the service accessible from outside the cluster we should add an appropriate reverse proxy route (e.g. via Ambassador or ISTIO). This way it will be secured via whatever authentication/authorization method the user has setup.