A sidecar proxy runs alongside an application workload and handles its network traffic without requiring application-code changes. It can forward, filter, or modify traffic according to its configuration. In a service mesh, this makes communication behavior a platform concern rather than something every service must implement. section 8.4.2
A proxy can be configured to:
- Validate a web token on requests to an API. section 8.4.2
- Retry a connection before returning a failure. section 8.4.2
- Encrypt traffic between proxies on communicating services. section 8.4.2
On Kubernetes, a proxy runs over the container network. A dedicated proxy per pod supports finer-grained traffic control, isolation, and observability. Sharing one proxy per node or cluster is an alternative, but makes service-specific policies and granular metrics harder. Choose the placement according to the control each workload needs. section 8.4.2
Figure 8.5 A service mesh acts as a control plane for proxy servers, deploying and configuring them based on our instructions, creating a standardized way of utilizing this integration point.
The diagram shows how a service mesh deploys and configures proxies through a control plane, standardizing this integration point. section 8.4.2










