kubeflow kfserving 详解
github 官方地址 https://github.com/kubeflow/kfservingkfserving 内部使用的是knative。封装了一层InferenceService的k8s自定义资源,来实现knative中serving的services,route,configurations,revisionknative 创建管理网络部分certificateskcertnetwor
全栈工程师开发手册 (作者:栾鹏)
架构系列文章
github 官方地址 https://github.com/kubeflow/kfserving
kfserving 内部使用的是knative。
封装了一层InferenceService的k8s自定义资源,来实现knative中serving的services,route,configurations,revision
knative 创建管理网络部分
certificates kcert networking.internal.knative.dev true Certificate
ingresses ing networking.internal.knative.dev true Ingress
serverlessservices sks networking.internal.knative.dev true ServerlessService
同时创建管理自动化部署部分
configurations config,cfg serving.knative.dev true Configuration
revisions rev serving.knative.dev true Revision
routes rt serving.knative.dev true Route
services kservice,ksvc serving.knative.dev true Service
inferenceservices inferenceservice serving.kubeflow.org true InferenceService
可以看出部署knative的serving 就会包含configurations,revisions,routes,services
kubeflow通过部署inferenceservice来操作knative的serving。
knative的serving的api
可以参考https://skyao.io/learning-knative/serving/overview/
knative的serving中的每种资源的yaml格式
可以参考https://skyao.io/learning-knative/serving/api/spec.html
route的yaml中 定义流量向哪个revisions分流比例。也可以直接指向configurations,则表示configurations的最新的那个revisions。通过route的名称去代表配置的是哪个serving.knative.dev
configurations的yaml中定义build( build.knative.dev)和revisionTemplate。已经定义了运行所需要的配置信息。build也就是从从哪个源码进行构建的。构建相关的参数。而在kfserving中并没有使用knative的build。kubeflow中使用fairing的build和deploy,以及knative的serving完成一整套的。
Revision是每次configurations更新的历史信息。image、command、args、env、livenessProbe、readinessProbe、serviceAccountName、concurrencyModel 这些信息都是通过configurations 获取保存下来的。
serving.knative.dev 绑定configuration或者revisionName和
kfseving的模块
api/client 可以通过客户端的包去查询部署的serving信息。
model文件夹中 是k8s资源的部署相关的文件。包含deploy,service,endpoint,TensorFlow service,knative serving相关的部署文件的生成。
kfserving 封装了isvc的概念,也就是InferenceService,用户管理 knative中的service,configurations,route,Revision。
同时因为service可能是不同的算法计算框架,例如xgb,TensorFlow,pytorch等,所以:
kfserving在各种类型的算法框架服务化的基础上,封装了一层Predictor的概念。用于实现模型服务化部署时的公共配置。就是传入对应框架的部署方案和公共配置方案(主要是max_replicas,min_replicas,parallelism,logger,batcher等),来实现部署服务化。在v1alpha2_predictor_spec.py文件中
而每种算法框架的部署文件构建大同小异,分别在v1alpha2_onnx_spec.py、v1alpha2_py_torch_spec.py、v1alpha2_sk_learn_spec.py、v1alpha2_tensorflow_spec.py、v1alpha2_xg_boost_spec.py、v1alpha2_onnx_spec.py。 这些对应框架的服务化配置构建代码中主要是配置部署的resources,runtime_version,storage_uri
类的包含关系
InferenceService:
api_version、kind、metadata、spec(V1alpha2InferenceServiceSpec)、status
InferenceServiceSpec:
default(EndpointSpec)、canary、canary_traffic_percent
EndpointSpec:
explainer(ExplainerSpec)、predictor(PredictorSpec)、transformer(TransformerSpec)
PredictorSpec:
max_replicas、min_replicas、parallelism、service_account_name、tensorflow、xgboost、pytorch、custom(完全自定义运行container的属性)
tensorflow:
resources、runtime_version、storage_uri
在实际部署InferenceService的时候,InferenceService-controller,会检测到InferenceService 产生,根据InferenceService-config的configmap来生成knative的service,route,rev,config等。
InferenceService-controller的代码在kfserving的pkg文件夹下。
更多推荐
所有评论(0)