By: Chansung Park and Sayak Paul

^{Figure developed by Chansung Park}

This project shows how to serve a TensorFlow image classification model as RESTful and gRPC based services with TFServing, Docker, and Kubernetes. The idea is to first create a custom TFServing docker image with a TensorFlow model, and then deploy it on a k8s cluster running on Google Kubernetes Engine (GKE). We are particularly interested in deploying the model as a gRPC endpoint with TF Serving on a k8s cluster using GKE and also with GitHub Actions to automate all the procedures when a new TensorFlow model is released.

👋 NOTE

• Even though this project uses an image classification its structure and techniques can be used to serve other models as well.
• There is a counter part of this project that uses FastAPI instead of TFServing. It shows how to convert a TensorFlow model to an ONNX optimized model and deploy it on a k8s cluster, check out the this repo.

Update Jule 29 2022: We published a blog post on load-testing the REST endpoint. Check it out on the TensorFlow blog here.

• Prerequisites: Doing anything beforehand, you have to create GKE cluster and service accounts with appropriate roles. Also, you need to grasp GCP credentials to access any GCP resources in GitHub Action. Please check out the more detailed information here.

flowchart LR
    A[First: Environmental Setup]-->B;
    B[Second: Build TFServing Image]-->C[Third: Deploy on GKE];

• To deploy a custom TFServing Docker image, we define deployment.yml workflow file which is is only triggered when there is a new release for the current repository. It is subdivided into three parts to do the following tasks:
  • First subtask handles the environmental setup.
    • GCP Authentication (GCP credential has to be provided in GitHub Secret)
    • Install gcloud CLI toolkit
    • Authenticate Docker to push images to GCR (Google Cloud Registry)
    • Connect to the designated GKE cluster
  • Second subtask handles building a custom TFServing image.
    • Download and extract the latest released model from the current repository
    • Run the CPU optimized TFServing image which is compiled from the source code (FYI. image tag is gcr.io/gcp-ml-172005/tfs-resnet-cpu-opt, and it is publicly available)
    • Copy the extracted model into the running container
    • Commit the changes of the running container and give it a new image name
    • Push the commited image
  • Third subtask handles deploying the custom TFServing image to GKE cluster.
    • Pick a one of the scenarios from a various experiments
    • Download Kustomize toolkit to handle overlay configurations.
    • Update image tag with the currently built one with Kustomize
    • By provisioning Deployment, Service, and ConfigMap, the custom TFServing image gets deployed.
      • NOTE: ConfigMap is only used for batching enabled scenarios to inject batching configurations dynamically into the Deployment.
  • In order to use this repo for your own purpose, please read this document to know what environment variables have to be set.

If the entire workflow goes without any errors, you will see something silimar to the text below. As you see, two external interfaces(8500 for RESTful, 8501 for gRPC) are exposed. You can check out the complete logs in the past runs.

NAME             TYPE           CLUSTER-IP     EXTERNAL-IP     PORT(S)                          AGE
tfs-server       LoadBalancer   xxxxxxxxxx     xxxxxxxxxx      8500:30869/TCP,8501:31469/TCP    23m
kubernetes       ClusterIP      xxxxxxxxxx     <none>          443/TCP                         160m

If you wonder how to perform gRPC inference, grpc_client.py provides code to perform inference with the gRPC client (grpc_client.py contains $ENDPOINT placeholder. To replace it with your own endpoint, you can envsubst < grpc_client.py > grpc_client.py after defining ENDPOINT environment variable). TFServing API provides handy features to construct protobuf request message via predict_pb2.PredictRequest(), and tf.make_tensor_proto(image) creates protobuf compatible values from Tensor data type.

We used Locust to conduct load tests for both TFServing and FastAPI. Below is the results for TFServing (gRPC) on a various setups, and you can find out the result for FastAPI (RESTful) in a separate repo. For specific instructions about how to install Locust and run a load test, follow this separate document.

👋 NOTE

• Locust doesn't have a built-in support to write a gRPC based client, so we have written one for ourselves. If you are curious about the implementation, check this locustfile.py out.
• The plot is generated by matplotlib after collecting CSV files generated from Locust.
• For the legend in the plot, n means the number of nodes(pods), c means the number of CPU cores, r means the RAM capacity, interop means the number of --tensorflow_inter_op_parallelism, and batch means the batching configuration is enabled with this config.

• More load test comparisons with more ML inference frameworks such as NVIDIA's Triton Inference Server, KServe, and RedisAI.

• Advancing this repo by providing a semi-automatic model deployment. To be more specific, when new codes implementing new ML model is pull requested, maintainers could trigger model performance evaluable on GCP's Vertex Training via comments. The experiment results could be exposed through TensorBoard.dev or W&B. If it is approved, the code will be merged, the trained model will be released, and it is going to be deployed on GKE.

• ML-GDE program for providing GCP credit support.
• Hannes Hapke for providing great insights for load-testing.