Cloud Service Mesh Port Naming Telemetry Failure

What the Solution Is

In Cloud Service Mesh and GKE, the service mesh relies on Kubernetes Service port definitions to determine the application protocol (e.g., HTTP, HTTP/2, gRPC). When port names do not begin with an accepted protocol prefix such as http, http2, or grpc (or use the standard appProtocol field), the Envoy proxy defaults to treating traffic as raw, unparsed TCP streams.

How It Meets the Requirements

• Identifies the Root Cause: The symptoms directly reflect a configuration mismatch in the Kubernetes Service resource. Because the port lacks an http or http- naming convention, Cloud Service Mesh treats incoming connections as generic TCP.
• Explains Missing Metrics: The Cloud Service Mesh dashboard and Cloud Monitoring HTTP server metrics strictly require recognized HTTP/gRPC traffic protocols; without them, layer 7 request metrics and latency statistics are not generated.
• Resolves Trace and Routing Anomalies: Renaming the port to start with http or http- enables Envoy to parse Layer 7 HTTP request headers, inject distributed tracing context headers, and generate appropriate HTTP-level telemetry and metrics.

Key Advantages and Capabilities

• Native Observability Alignment: Adhering to port naming conventions enables automatic protocol detection, unlocking Golden Signals metrics in Cloud Monitoring.
• Seamless Trace Context Propagation: Allows Envoy sidecars to parse HTTP headers (e.g., traceparent, x-cloud-trace-context) and attach trace spans automatically.
• Zero Application Code Changes: Resolving the issue only requires modifying the Kubernetes Service manifest without altering application binaries.
• Prevents Protocol Degradation: Ensures advanced routing, load balancing, and mTLS features operate at the application layer rather than falling back to opaque transport-layer proxies.

Why This Is Optimal

Other possibilities (such as proxy injection failure or API quota exhaustion) are ruled out by the telemetry evidence: pods already possess running istio-proxy containers, and raw TCP logs are successfully ingested. Modifying the Service port name directly fixes the root protocol mismatch.