Handling requests with Cloud Service Mesh
1. Handling requests with Cloud Service Mesh
Now that we've covered the basics of Cloud Service Mesh, let's dive into the request handling process. Then the Envoy sidecar proxy container is injected into the pod, and iptables are configured so that all requests are redirected to Envoy. Envoy gathers service information, routing, and configuration policy from the control plane, so that it knows where to send requests. Finally, the Service Mesh certificate authority, in this case, Mesh CA, securely distributes TLS certificates to the Envoy proxies, enabling them to establish secure, mutually authenticated connections, MTLS. When service A places a call to service B, the client-side Envoy proxy intercepts the call. Envoy consults the local configuration to determine how and where to route the call to service B. For example, Envoy might change the protocol to gRPC and establish a secure MTLS connection. Then Envoy forwards the request to the appropriate instance of service B. The server-side Envoy proxy deployed with the service intercepts the call, validates certificates, and establishes the MTLS connection. For validation, the receiving Envoy uses Envoy filters. These filters extend the functionality of Envoy proxies. For example, they can be used to enforce access control policies, perform quota checks, and collect telemetry data. After the call is validated, the server-side destination Envoy forwards the request to service B. Service B then processes the request and sends a response back, which is intercepted by the Envoy proxy of service A. At this stage, the server-side Envoy is done with the request and reports telemetry to in end proxy extensions called WebAssembly extensions. These extensions let developers add custom networking functionality by notifying the appropriate plugins. However, when considering Cloud Service Mesh, the operational philosophy shifts. CSM operates as a fully managed service, and Google Cloud takes on the responsibility of maintaining the Envoy proxies. This restriction exists because injecting unvetted Wasm modules directly into the managed Envoy proxies introduces potential vulnerabilities and stability risks that are incompatible with the managed service model. Therefore, while Envoy itself is capable of running Wasm extensions, the nature of CSM's managed service limits the direct user implementation of the technology in favor of a more stable and secure service. Finally, the client-side Envoy proxy, forwards the response to the original caller, service A.2. Let's practice!
Create Your Free Account
or
By continuing, you accept our Terms of Use, our Privacy Policy and that your data is stored in the USA.