[Kubeflow系列]KFServing介绍

发表于 更新于 分类于 阅读次数： 本文字数： 2.7k 阅读时长 ≈ 2 分钟

之前调研了TensorFlow Serving的功能, 这周又抽出来一点时间, 调研一下KubeFlow Serving

KFServing的定位

之前在Kubeflow的介绍文章有提过, Kubeflow支持Training和Serving, 但是如果仔细看Serving的官网会发现, 目前这个Serving似乎只是把这种各样的Serving镜像给安装部署起来就好了, 感觉游离在系统之外的.

所以TFServing的目标就是设计一套接口, 将各个Serving模块抽象化, 变成一套系统.

但是, 目前TFServing虽然提交活跃度挺高, 但是还没有挂在官网介绍文章之中, 版本非常新, 目前才v0.2版本, 未来接口可能会有很大变化

KFServing架构

从架构图上可以看出, KFServing在非常高的位置之上, 它底层的服务能力依赖于KNative(主要是KNative的Serving模块), 上层支持的框架有:

  1. TensorFlow: 镜像由于TensorFlow官网提供
  2. PyTorch: 镜像由KFServing制作, 代码逻辑位于此
  3. SKLearn: 同上
  4. XGBoost: 同上
  5. TensorRT: 镜像由NVIDIA提供

基本上主流的一些机器学习框架都已经支持

下面看一下KFServing的服务能力, 数据流图如下所以:

这个是一个典型的灰度发布场景, 一个默认环境, 一个灰度环境, 由KNative的来控制流量.

KFServing似乎目前只支持一个灰度实例

KFServing的使用案例

看个简单的TensorFlow Serving的例子, 所有的样例在这个代码路径之中

1
2
3
4
5
6
7
8
apiVersion: "serving.kubeflow.org/v1alpha1"
kind: "KFService" # `KFService`是KFServing在K8s上定义的CRD.
metadata:
  name: "flowers-sample"
spec:
  default:
    tensorflow:
      modelUri: "gs://kfserving-samples/models/tensorflow/flowers"

这段YAML的意思为, 创建一个TensorFlow类型的Serving, 模型文件存在Google Cloud的gs://kfserving-samples/models/tensorflow/flowers的路径之中.

TensorFlow Serving并不支持GCS的路径, 这里TF Serving通过一个model-initializer的init-container提前下载到容器内部, TF Serving实例上读取是本地路径, 所以模型不能太大, 因为目前还不支持挂载PVC

当然也可以设置一个灰度服务: 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
apiVersion: "serving.kubeflow.org/v1alpha1"
kind: "KFService"
metadata:
  name: "flowers-sample"
spec:
  default:
   # 90% of traffic is sent to this model
    tensorflow:
      modelUri: "gs://kfserving-samples/models/tensorflow/flowers"
  canaryTrafficPercent: 10
  canary:
   # 10% of traffic is sent to this model
    tensorflow:
      modelUri: "gs://kfserving-samples/models/tensorflow/flowers-2"

这个YAML的含义是, 90%走到default服务, 也就是flowers模型, 而剩下的10%的模型走到canary去, 模型为flowers-2

这里会生成KNative的资源有: 1个Service, 1个Route, 2个Configuration, 2个Revision

你可以使用KNative的客户端, 来完成两个灰度升级回滚等操作.

访问流量需要获取istio-ingressgateway的地址, 加上定义的url就能访问了

1
2
3
4
5
6
MODEL_NAME=flowers-sample
INPUT_PATH=@./input.json
CLUSTER_IP=$(kubectl -n istio-system get service istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
SERVICE_HOSTNAME=$(kubectl get kfservice ${MODEL_NAME} -o jsonpath='{.status.url}')

curl -v -H "Host: ${SERVICE_HOSTNAME}" http://$CLUSTER_IP/v1/models/$MODEL_NAME:predict -d $INPUT_PATH

YAML的字段定义在这篇文档之中

KFServing总结

首先, KFServing目前是一个非常前期的项目, 这就注定了可能很多功能, 它目前都不支持, 但是目前它的目标我们实际上是接受的, 等这个版本再经过几轮迭代之后可以跟进.

模型资产存储在OBS上, Serving获取模型, 自动部署模型推理服务

其次, KFServing的架构依赖实在太多了, 特别依赖是KNative, 目前还不能确定KNative能够在Serverless框架的竞争之中胜出, 而且KNative的版本也比较前期, 问题也挺多, 对于KFServing质量评分造成了不少影响.

实际上灰度发布和流量控制, Istio能力已经完全具备, 不知道为什么必须依赖KNative, 未来能解除KNative的依赖就好了

再次, KFServing有Python的SDK, 可以使用代码直接部署KFServing的Service, 这对工程人员是一个很方便的能力.

此外, 它由一个叫做TF2OpenAPI的小工具, 能够将TF的模型的API描述自动生成, 又是对工程人员的工具.

最后, KFServing的路标之中提到, KFServing马上会在Kubeflow 0.7版本之中就集成了, 而且9月初就会支持PVC啦, 赶紧迭代起来吧.