示例工程【免费下载链接】examplesKubernetes application example tutorials项目地址https://gitcode.com/gh_mirrors/examp/examples点击查看免费下载本指南以examples仓库中的AI/model-serving-tensorflow示例为主线讲解如何把一个预训练的 TensorFlow SavedModel 通过 TensorFlow Serving 在 Kubernetes 上跑成可用的推理服务。读完本文你将掌握模型目录的持久化挂载PersistentVolume/PersistentVolumeClaim、Deployment中 TensorFlow Serving 的核心启动参数、ClusterIPService 的 gRPC/REST 双端口暴露方式以及通过 Ingress 将/tf/v1/models/my_model:predict暴露给外部客户端并发送预测请求的完整链路。本示例的目标你将学到什么AI/model-serving-tensorflow/README.md开门见山地说明了这个示例的核心目的在 Kubernetes 上使用 TensorFlow Serving 部署一个用于推理inference的 TensorFlow 模型。具体来说完成本示例后你将能够使用预先训练好的模型配置并启动 TensorFlow Serving通过 PersistentVolume 将模型目录挂载进推理容器使用 KubernetesService与Ingress暴露推理端点向模型发送一条真实的预测prediction请求并观察返回结果。整个示例只需要 5 个清单文件即可完整落地它们全部位于 AI/model-serving-tensorflow 目录下文件作用pv.yaml定义承载模型文件的持久卷PersistentVolumepvc.yaml声明持久卷的占用PersistentVolumeClaimdeployment.yaml部署 TensorFlow Serving 容器并挂载模型service.yaml以 ClusterIP 暴露 gRPC8500与 REST8501端口ingress.yaml可选将 REST 预测端点对外暴露前置条件按照文档要求开始之前请确认以下环境就绪一个可用的 Kubernetes 集群文档标注已在 v1.29 版本上验证已正确配置好kubectl能够访问目标集群可选安装ingress-nginx用于对外部客户端开放访问入口一台 x86 架构的机器因为tensorflow/serving官方镜像面向 x86 提供deployment.yaml 中默认使用的镜像为tensorflow/serving:2.19.0本地支持hostPath用于演示或具备云厂商提供的 PVC 后端如 AWS EBS、GCE PD、NFS 等。说明示例为方便本地演示使用hostPath挂载/mnt/models/my_model在生产环境中请将该卷替换为云原生的存储后端具体做法见后文「配置定制」一节。存储准备PersistentVolume 与 PVC模型目录结构TensorFlow Serving 采用「版本化目录」组织模型每个版本对应一个以数字命名的子目录。文档给出的标准结构如下/mnt/models/my_model/ └── 1/ ├── saved_model.pb └── variables/其中/mnt/models/my_model是模型根目录对应model_base_path的上一级1/是模型的版本号目录saved_model.pb是 SavedModel 的图定义variables/存放模型权重。TensorFlow Serving 会按数字目录的版本号自动加载模型并将模型名my_model暴露给调用方。PersistentVolume 定义仓库中的 pv.yaml 内容如下apiVersion: v1 kind: PersistentVolume metadata: name: my-model-pv spec: capacity: storage: 1Gi accessModes: - ReadOnlyMany persistentVolumeReclaimPolicy: Retain hostPath: path: /mnt/models/my_model几个关键字段的实战含义capacity.storage: 1Gi声明该卷的容量为 1Gi。对于模型文件通常足够可按模型实际体积调整。accessModes: ReadOnlyMany卷以只读方式被多个节点/Pod 同时挂载。模型文件在推理阶段只需读取这是最贴合推理场景的访问模式也能避免多个副本写入造成的数据竞争。persistentVolumeReclaimPolicy: RetainPVC 被删除后卷数据保留防止误删模型文件适合模型这类「贵重建产物」。hostPath.path: /mnt/models/my_model直接把宿主机目录挂载进 Pod用于单机演示。需要确保对应节点上已经按前述目录结构放置好模型文件。PersistentVolumeClaim 定义pvc.yaml 通过volumeName显式绑定到上面定义的 PVapiVersion: v1 kind: PersistentVolumeClaim metadata: name: my-model-pvc spec: accessModes: - ReadOnlyMany resources: requests: storage: 1Gi volumeName: my-model-pvPVC 的accessModesReadOnlyMany与存储容量请求1Gi必须与 PV 匹配volumeName: my-model-pv直接指定要绑定的持久卷名称避免依赖动态供给或调度器自动匹配。后续 Deployment 正是通过这个 PVCclaimName: my-model-pvc把模型目录注入容器。部署 TensorFlow ServingDeployment 详解deployment.yaml 是整个示例的核心完整内容如下apiVersion: apps/v1 kind: Deployment metadata: name: tf-serving labels: app: tf-serving spec: replicas: 1 selector: matchLabels: app: tf-serving template: metadata: labels: app: tf-serving spec: containers: - name: tensorflow-serving image: tensorflow/serving:2.19.0 args: - --model_namemy_model - --port8500 - --rest_api_port8501 - --model_base_path/models/my_model ports: - containerPort: 8500 # gRPC - containerPort: 8501 # REST volumeMounts: - name: model-volume mountPath: /models/my_model volumes: - name: model-volume persistentVolumeClaim: claimName: my-model-pvc围绕这段配置有几个直接影响服务行为的关键点值得展开1. 启动参数args即 TensorFlow Serving 的运行时配置--model_namemy_model对外暴露的模型名。它直接决定了 REST 端点路径中的模型名部分/v1/models/my_model:predict以及 gRPC 调用时ModelSpec.name字段的取值--port8500gRPC 服务监听端口供高性能 RPC 客户端使用--rest_api_port8501RESTHTTP/JSON服务监听端口便于curl或任意 HTTP 客户端直接调用--model_base_path/models/my_model模型根目录。注意它与容器内mountPath: /models/my_model完全一致——也就是说TensorFlow Serving 会在/models/my_model下寻找版本子目录如/models/my_model/1/并加载其中1/版本对应的 SavedModel。2. 端口声明容器同时暴露 8500gRPC与 8501REST两个端口与 args 中的端口配置一一对应。这两个端口将在下一步由 Service 承接并对外暴露。3. 模型目录的注入方式容器通过volumeMounts将名为model-volume的卷挂载到/models/my_model而该卷来自persistentVolumeClaim: my-model-pvc。由此形成完整的存储链路宿主机/mnt/models/my_modelPV→ PVC → Pod 内/models/my_model→--model_base_path加载模型。4. 副本与标签replicas: 1说明示例以单副本运行app: tf-serving标签同时用于 Deployment 的selector、Pod 模板以及后续 Service 的selector三者必须保持一致Service 才能正确发现后端 Pod。暴露服务Service 与双端口设计service.yaml 定义了类型为ClusterIP的服务apiVersion: v1 kind: Service metadata: name: tf-serving spec: selector: app: tf-serving ports: - name: grpc port: 8500 targetPort: 8500 - name: rest port: 8501 targetPort: 8501 type: ClusterIPselector.app: tf-serving与 Deployment 的 Pod 标签一致Service 将流量转发给这些 Pod两个具名端口grpc8500与rest8501一一对应容器端口ClusterIP类型使集群内部其他组件可以通过tf-serving:8500gRPC和tf-serving:8501REST访问推理服务。需要理解的是ClusterIP只在集群内部可达。若要让集群外部浏览器、外部系统调用模型就需要借助 Ingress。对外访问Ingress 与路径重写ingress.yaml 提供了一条可选的外部访问通道完整内容如下apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: tf-serving-ingress annotations: nginx.ingress.kubernetes.io/rewrite-target: /$2 spec: rules: - http: paths: - path: /tf(/|$)(.*) pathType: Prefix backend: service: name: tf-serving port: number: 8501这段配置的核心在于路径重写外部请求以/tf/...前缀进入例如http://ingress-host/tf/v1/models/my_model:predict注解nginx.ingress.kubernetes.io/rewrite-target: /$2配合路径模式/tf(/|$)(.*)会把/tf/前缀剥掉将剩余部分即$2捕获的v1/models/my_model:predict重写为/v1/models/my_model:predict重写后的请求被转发到后端 Servicetf-serving的 8501 端口REST API从而命中 TensorFlow Serving 原生的 REST 预测端点路径。使用前务必把ingress.yaml中的host值替换为你自己的域名并确保集群已安装 Ingress Controller文档建议ingress-nginx。快速开始一条龙部署在仓库根目录下依次执行以下命令即可完成从存储到服务的全部部署kubectl apply -f AI/model-serving-tensorflow/pv.yaml kubectl apply -f AI/model-serving-tensorflow/pvc.yaml kubectl apply -f AI/model-serving-tensorflow/deployment.yaml kubectl apply -f AI/model-serving-tensorflow/service.yaml kubectl apply -f AI/model-serving-tensorflow/ingress.yaml # 可选建议按 PV → PVC → Deployment → Service → Ingress 的顺序执行先有可绑定的卷PVC 才能成功绑定PVC 就绪后 Deployment 才能正常挂载启动。验证发送预测请求与检查 Pod 状态通过 Ingress 发送预测请求部署完成后使用 Ingress 暴露的地址发送一条 JSON 格式的预测请求instances字段即模型的输入实例curl -X POST http://ingress-host/tf/v1/models/my_model:predict \ -H Content-Type: application/json \ -d { instances: [[1.0, 2.0, 5.0]] }预期返回结果结构如下具体数值取决于模型的输入输出定义{ predictions: [...] }检查推理服务是否正常运行kubectl get pods kubectl wait --forconditionAvailable deployment/tf-serving --timeout300s kubectl logs deployment/tf-servingkubectl get pods确认tf-serving的 Pod 处于Running且Ready状态kubectl wait --forconditionAvailable等待 Deployment 就绪--timeout300s给出 5 分钟的等待上限kubectl logs deployment/tf-serving查看服务启动日志其中会输出模型加载信息例如成功加载my_model的版本号可用于排查模型路径、版本目录等问题。深入理解gRPC 与 REST 两种调用方式从 deployment.yaml 的--port8500与--rest_api_port8501可以看出本示例同时启用了 TensorFlow Serving 的两种服务协议理解二者的分工有助于在实际项目中选型gRPC8500 端口基于 Protocol Buffers 的高性能 RPC 通道适合服务间高频、大批量的推理调用延迟更低、序列化开销更小客户端通常使用 TensorFlow Serving 提供的客户端库或通用 gRPC 客户端REST8501 端口HTTP/JSON 接口端点形如/v1/models/my_model:predict本示例的 Ingress 正是把外部请求重写到这个原生 REST 路径上任何支持 HTTP 的语言或工具如curl都能直接调用便于快速验证与异构系统集成。两个端口由同一个tf-servingService 同时暴露意味着集群内其他组件可以按需选择协议需要高性能走 gRPC 的 8500需要简单集成走 REST 的 8501。配置定制文档给出了三类典型的定制方向结合清单文件可以进一步落地更换模型与路径修改 deployment.yaml 中的--model_name与--model_base_path并将对应 PV 指向新的模型目录如果模型名变更Ingress 的访问路径/tf/v1/models/新模型名:predict与验证请求也要同步调整。替换存储后端将 pv.yaml 中的hostPath换成绑定云存储的 PV如 AWS EBS、GCE PD或 NFS 等共享存储PVC 无需改动Deployment 即可继续通过my-model-pvc挂载对于多副本横向扩展的场景建议使用支持ReadOnlyMany的共享存储让所有副本同时挂载同一份模型。调整容器资源在 deployment.yaml 的容器规格中补充resources.requests与resources.limitsCPU/内存为 TensorFlow Serving 预留足够的推理算力避免节点资源竞争影响推理延迟。清理环境按照与部署相反的顺序删除资源即可完整回收本次示例创建的所有对象kubectl delete -f AI/model-serving-tensorflow/ingress.yaml # 可选 kubectl delete -f AI/model-serving-tensorflow/service.yaml kubectl delete -f AI/model-serving-tensorflow/deployment.yaml kubectl delete -f AI/model-serving-tensorflow/pvc.yaml kubectl delete -f AI/model-serving-tensorflow/pv.yaml由于 PV 的回收策略为Retain删除后宿主机/mnt/models/my_model下的模型数据仍会保留便于后续重新绑定使用。延伸阅读本示例属于仓库AI/目录下的 AI/ML 示例体系该模块的目标是提供一套社区维护的、面向 Kubernetes 的 AI/ML 参考清单可参阅 AI/README.md 了解整体定位若你的场景是大模型推理仓库还提供了基于 vLLM 的部署示例 AI/vllm-deployment/README.md 及其 vLLM 部署清单可对比不同推理框架在 Kubernetes 上的落地方式进一步学习 TensorFlow Serving 的 REST API 约定、Kubernetes Ingress Controller 的路径重写语义以及 PersistentVolume 的访问模式与回收策略可以帮助你在生产环境中对本文示例做更精细的调优。赞分享示例工程【免费下载链接】examplesKubernetes application example tutorials项目地址https://gitcode.com/gh_mirrors/examp/examples点击查看免费下载相关推荐Awesome-Linux-Software 西班牙语版全解析Linux 优质软件清单的完整分类指南与维护机制Awesome Linux Software 西班牙语版全解析Linux 优质软件清单的完整分类指南与维护机制 导读 README_es ES.md http文档知识库教程TensorFlow2 模型服务化部署实战使用 TensorFlow Serving 发布 REST API 预测服务TensorFlow2 模型服务化部署实战使用 TensorFlow Serving 发布 REST API 预测服务 本文是《30天吃掉那只TensorFl教程深度学习机器学习awesome-kubernetes中的服务暴露Ingress控制器与API网关方案awesome kubernetes中的服务暴露Ingress控制器与API网关方案 你是否正在为Kubernetes集群中的服务暴露而烦恼不知道该选择In文档云原生上一篇5步掌握ManiSkill自定义机器人从零构建高性能仿真模型下一篇3步精通PicoRV32从零构建RISC-V嵌入式系统的完整指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考