Details
-
Bug
-
Resolution: Unresolved
-
Major
-
None
-
None
-
None
-
3
-
False
-
False
-
Compatibility/Configuration, User Experience
-
Undefined
Description
When spec.tracing.type is set to None and sampling is not set to zero, istio continues to generate trace spans, even though it won't send them anywhere. When tracing is disabled, we should clear the sample rate too. This should probably be done in the charts, to preserve round tripping of the smcp resource from v2->v1->v2 (i.e. probably best to not handle this in conversion). Another option would be to modify the appliedValues directly before using them to render the helm charts.
When installing Service Mesh with a configuration that turns off tracing as per documentation, listener configuration for Envoy gateway instances will have the sampling part of tracing turned on.
While it seems no trace spans are actually put on the wire, this does set up the system for building up these spans internally, which comes with a little overhead; also it makes the gateway synthesize `x-request-id` headers and responses then come with `x-envoy-decorator-operation`. These things combined degraded max throughput by approximately 11% in a scaled perf test compared to a Istio 1.6 install.
Turning off tracing in the istio-basic-install configmap of the control plane and then re-creating the gateways resolves the issue as a work-around (but risks the operator overwriting/reverting this change at will, so it's not dependable).
Acceptance Criteria:
- when spec.tracing.type is None, set spec.tracing.sampling to 0 as well
- operator unit test