A service mesh is an infrastructure layer that controls communication between distributed services. It manages ingress and egress traffic, security, observability, resilience, and traffic policies without requiring changes to application logic. Meshes can operate within Kubernetes, span multiple clusters, or connect services running on virtual machines. section 4.0 section 4.2
A mesh typically provides:
- Sidecar proxies that run alongside services, handle ingress and egress, and forward telemetry to a centralized control plane. section 4.2
- Proxyless operation, where services send telemetry directly to the control plane through gRPC or a remote proxy. section 4.2
- Encrypted and authenticated service-to-service communication through mutual TLS, together with authorization policies. section 4.0 section 4.6
- Centralized metrics, logs, topology, and traffic visibility for diagnosing failing workloads and monitoring service levels. section 4.0 section 15.7
- Traffic controls such as retries, circuit breaking, traffic splitting, canary releases, and A/B testing. section 15.1.6 section 4.6
Applying a mesh after migration
After containerizing an application, Anthos Service Mesh can expose service dependencies and telemetry without changing application code. Operators can inspect error, latency, and request-rate metrics, define service-level objectives, shift a weighted portion of traffic to a newer version, and connect services across on-premises and multiple-cloud environments. section 15.1.6 section 15.7
Use the sidecar architecture diagram to see how a proxy accompanies each service while remaining separate from application logic. section 4.2
