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: v0.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)

1. 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

2. Install Istio lean version, Knative Serving, KFServing all in one.(this takes 30s)

./hack/quick_install.sh

1. 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          13m

Please refer to our troubleshooting section for recommendations and tips for issues with installation.

2. Wait all pods to be ready then launch KFServing InferenceService.(wait 1 min for everything to be ready and 40s to launch the InferenceService)

kubectl create namespace kfserving-test
kubectl apply -f docs/samples/sklearn/sklearn.yaml -n kfserving-test

3. Check KFServing InferenceService status.

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

4. 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 examples

KFServing Concepts and Data Plane

KFServing API Docs

Debug KFServing InferenceService

Developer Guide.

Performance Tests

Contributor Guide