Samples for running gRPC on GKE and Istio:
client_grpc_app (via gRPC wire protocol) --> ingress --> (grpc Service on GKE)
- Folder:
gke_ingress_lb/
client_grpc_app (acquire gRPC lookaside loadbalancing/XDS) --> GKE pod NEG address
- Folder:
gke_td_xds/
Javascript clients:
client(browser) (via grpc-web protocol) --> Ingress --> (grpc Service on GKE)
- Folder
gke_svc_lb/
client (pod running in GKE) --> k8s Service --> (gRPC endpoint in same GKE cluster)
- Folder
gce
client_grpc_app --> L7LB --> ManagedInstanceGroup
- folder
istio/
client_grpc_app (on GCEVM) --> (GCP ILB) --> Istio --> Service
client_grpc_app (external) --> (GCP ExternalLB) --> Istio --> Service
Also see:
Update 5/14/20
: Also see xds gRPC Loadbalancing. Using xDS client-side only loadbalancing is woudl be the recommended way for internal service->service LB at scale. However, it is quite experimental at the moment and cannot be easily deployed on GKE/GCE (unless you use an xDS server like Traffic Director).
You can find the source here:
- Client and Server: app/grpc_backend/
And the various docker images on dockerhub
docker.io/salrashid123/grpc_backend
To run the gRPC server locally to see message replay:
-
Server:
docker run -p 50051:50051 -t salrashid123/grpc_backend ./grpc_server -grpcport 0.0.0.0:50051
-
Client:
docker run --net=host --add-host grpc.domain.com:127.0.0.1 -t salrashid123/grpc_backend /grpc_client --host grpc.domain.com:50051
What client app makes ONE connection out to the Server and then proceeds to send 10 RPC calls over that conn. For each call, the server will echo back the hostname of the server/pod that handled that request. In the example here locally, it will be all from one host.