Load balancing gRPC in Kubernetes with a service mesh
useanvil.comBeyond the obvious increase in complexity, what were the other costs incurred with introducing a service mesh layer into the system?
for example:
- Latency increase measurements
- Changes in bandwidth and network throughput
- New or different failure modes
- New challenges observing application and traffic behaviour with the introduction of additional networking layer in the middle
- Any other new problems caused by introducing the service mesh
Hi, Author of the post here. Thank you for the great question!
The biggest cost comes from managing another namespace with a handful of deployments and pods. There's also all the sidecar containers that are taking up resources, even though not very many. This literally costs more, but maintenance has been minimal. The pros outweighed the cons significantly and we saw faster responses and lower latency due to the intelligent load balancing. Our pods were being loaded unevenly so when Istio balanced this out our scaling worked better and led to much faster response times across the board. So far we have not run into any new failure modes or other issues. Istio has been "set it and forget it" so far since we are using a pretty vanilla installation. Thank you for the great question and I hope this provided some insight!