Let's begin with the definition of the service mesh. William Morgan in 2017 defined the service mesh as follows (https://buoyant.io/2017/04/25/whats-a-service-mesh-and-why-do-i-need-one):
We can view a service mesh as a decoupling agent between Dev (provider) and Ops (consumer). Dev does not have to write any code in the microservices to provide capabilities that Ops need. Ops does not have to recompile the system, so both can operate independently of each other. The service mesh concept is a significant shift from earlier versions of DevOps, where operations were limited to software release management.
Kubernetes orchestration provides an essential service so that we can service communication through smart endpoints and dumb pipes. Martin Fowler, in his 2014 blog article (Lewis and Fowler), provided a more advanced look at the concept of smart endpoints and dumb pipes:
Dumb pipes: Service-to-service communication uses basic network traffic protocols such as HTTP, REST, gRPC, and so on. This type of connection is opposed to a centralized smart pipe using the ESB/MQ of monolithic applications."
Christian Posta defines a service mesh as a decentralized
application networking infrastructure between your services. This decoupling provides resiliency, security, observability, and routing control.
In Zach Jory's blog post (https://dzone.com/articles/comparing-service-mesh-architectures), he explains the library, node agent, and sidecar model of the service mesh architecture.