Service mesh technologies solve problems with service-to-service communications across cloud networks. Problems such as service identity, consistent L7 network telemetry gathering, service resilience, traffic routing between services, as well as policy enforcement (like quotas, rate limiting, etc) can be solved with a service mesh. For a service mesh to operate correctly, it needs a way to get traffic into the mesh. The problems with getting traffic from the edge into the cluster are a bit different from service-to-service problems. Things like edge caching, first-hop security and traffic management, Oauth and end-user authentication/authorization, per-user rate limiting, web-application firewalling, etc are all things an Ingress gateway can and should help with. Gloo solves these problems and complements any service mesh including Istio, Linkerd, Consul Connect, and AWS App Mesh.
Gloo integration with service-mesh technology
- Gloo and Istio mTLS
- Gloo and AWS App Mesh
Motivation Serving as the Ingress for an Istio cluster – without compromising on security – means supporting mutual TLS communication between Gloo and the rest of the cluster. Mutual TLS means that the client proves its identity to the server (in addition to the server proving its identity to the client, which happens in regular TLS). For this exercise, you will need Istio installed with mTLS enabled. This guide was tested with istio 1.
Using Gloo as an ingress to App Mesh
Consul Connect (Soon to come!)