KFServing provides a Kubernetes Custom Resource Definition for serving machine learning (ML) models on arbitrary frameworks. It aims to solve production model serving use cases by providing performant, high abstraction interfaces for common ML frameworks like Tensorflow, XGBoost, ScikitLearn, PyTorch, and ONNX.
It encapsulates the complexity of autoscaling, networking, health checking, and server configuration to bring cutting edge serving features like GPU Autoscaling, Scale to Zero, and Canary Rollouts to your ML deployments. It enables a simple, pluggable, and complete story for Production ML Serving including prediction, pre-processing, post-processing and explainability.
To learn more about KFServing, how to deploy it as part of Kubeflow, how to use various supported features, and how to participate in the KFServing community, please follow the KFServing docs on the Kubeflow Website.
Knative Serving and Istio should be available on Kubernetes Cluster, Knative depends on Istio Ingress Gateway to route requests to Knative services. To use the exact versions tested by the Kubeflow and KFServing teams, please refer to the prerequisites on developer guide
- Istio: v1.1.6+
If you want to get up running Knative quickly or you do not need service mesh, we recommend installing Istio without service mesh(sidecar injection).
- Knative Serving: v0.11.1+
Currently only Knative Serving is required, cluster-local-gateway is required to serve cluster-internal traffic for transformer and explainer use cases. Please follow instructions here to install cluster local gateway
- Cert Manager: v1.12.0+
Cert manager is needed to provision KFServing webhook certs for production grade installation, alternatively you can run our self signed certs generation script.
KFServing can be installed standalone if your kubernetes cluster meets the above prerequisites and KFServing controller is deployed in kfserving-system namespace.
TAG=v0.3.0
kubectl apply -f ./install/$TAG/kfserving.yaml
KFServing uses pod mutator or mutating admission webhooks to inject the storage initializer component of KFServing. By default all the pods in namespaces which are not labelled with control-plane label go through the pod mutator.
This can cause problems and interfere with Kubernetes control panel when KFServing pod mutator webhook is not in ready state yet.
For Kubernetes 1.14 users we suggest enabling the following environment variable ENABLE_WEBHOOK_NAMESPACE_SELECTOR so that only pods
in the namespaces which are labelled serving.kubeflow.org/inferenceservice: enabled go through the KFServing pod mutator.
env:
- name: ENABLE_WEBHOOK_NAMESPACE_SELECTOR
value: enabled
For Kubernetes 1.15+ users we strongly suggest turning on the object selector so that only KFServing InferenceService pods go through the pod mutator.
kubectl patch mutatingwebhookconfiguration inferenceservice.serving.kubeflow.org --patch '{"webhooks":[{"name": "inferenceservice.kfserving-webhook-server.pod-mutator","objectSelector":{"matchExpressions":[{"key":"serving.kubeflow.org/inferenceservice", "operator": "Exists"}]}}]}'KFServing is installed by default as part of Kubeflow installation using Kubeflow manifests and KFServing controller is deployed in kubeflow namespace.
Since Kubeflow Kubernetes minimal requirement is 1.14 which does not support object selector, ENABLE_WEBHOOK_NAMESPACE_SELECTOR is enabled in Kubeflow installation by default.
If you are using Kubeflow dashboard or profile controller to create user namespaces, labels are automatically added to enable KFServing to deploy models. If you are creating namespaces manually using Kubernetes apis directly, you will need to add label serving.kubeflow.org/inferenceservice: enabled to allow deploying KFServing InferenceService in the given namespaces, and do ensure you do not deploy
InferenceService in kubeflow namespace which is labelled as control-panel.
Make sure you have kubectl, kustomize v3.5.4+, helm 3 installed before you start.(2 mins for setup)
- If you do not have an existing kubernetes cluster you can create a quick kubernetes local cluster with kind.(this takes 30s)
kind create cluster- Install Istio lean version, Knative Serving, KFServing all in one.(this takes 30s)
./hack/quick_install.sh- To check if KFServing Controller is installed correctly, please run the following command
kubectl get po -n kfserving-system
NAME READY STATUS RESTARTS AGE
kfserving-controller-manager-0 2/2 Running 2 13mPlease refer to our troubleshooting section for recommendations and tips for issues with installation.
- Wait all pods to be ready then launch KFServing
InferenceService.(wait 1 min for everything to be ready and 40s to launch theInferenceService)
kubectl create namespace kfserving-test
kubectl apply -f docs/samples/sklearn/sklearn.yaml -n kfserving-test- Check KFServing
InferenceServicestatus.
kubectl get inferenceservices sklearn-iris -n kfserving-test
NAME URL READY DEFAULT TRAFFIC CANARY TRAFFIC AGE
sklearn-iris http://sklearn-iris.kfserving-test.example.com/v1/models/sklearn-iris True 100 109s- Curl the
InferenceService
kubectl port-forward --namespace istio-system $(kubectl get pod --namespace istio-system --selector="app=istio-ingressgateway" --output jsonpath='{.items[0].metadata.name}') 8080:80
SERVICE_HOSTNAME=$(kubectl get inferenceservice sklearn-iris -n kfserving-test -o jsonpath='{.status.url}' | cut -d "/" -f 3)
curl -v -H "Host: ${SERVICE_HOSTNAME}" http://localhost:8080/v1/models/sklearn-iris:predict -d @./docs/samples/sklearn/iris-input.json-
Install the SDK
pip install kfserving -
Get the KFServing SDK documents from here.
-
Follow the example here to use the KFServing SDK to create, rollout, promote, and delete an InferenceService instance.
KFServing Concepts and Data Plane