|
| 1 | +--- |
| 2 | +title: Traces For Kubernetes System Components |
| 3 | +reviewers: |
| 4 | +- logicalhan |
| 5 | +- lilic |
| 6 | +content_type: concept |
| 7 | +weight: 60 |
| 8 | +--- |
| 9 | + |
| 10 | +<!-- overview --> |
| 11 | + |
| 12 | +{{< feature-state for_k8s_version="v1.22" state="alpha" >}} |
| 13 | + |
| 14 | +System component traces record the latency of and relationships between operations in the cluster. |
| 15 | + |
| 16 | +Kubernetes components emit traces using the [OpenTelemetry Protocol](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/protocol/otlp.md#opentelemetry-protocol-specification) with the gRPC exporter and can be collected and routed to tracing backends using an [OpenTelemetry Collector](https://github.com/open-telemetry/opentelemetry-collector#-opentelemetry-collector). |
| 17 | + |
| 18 | +<!-- body --> |
| 19 | + |
| 20 | +## Trace Collection |
| 21 | + |
| 22 | +For a complete guide to collecting traces and using the collector, see [Getting Started with the OpenTelemetry Collector](https://opentelemetry.io/docs/collector/getting-started/). However, there are a few things to note that are specific to Kubernetes components. |
| 23 | + |
| 24 | +By default, Kubernetes components export traces using the grpc exporter for OTLP on the [IANA OpenTelemetry port](https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=opentelemetry), 4317. As an example, if the collector is running as a sidecar to a Kubernetes component, the following receiver configuration will collect spans and log them to standard output: |
| 25 | + |
| 26 | +```yaml |
| 27 | +receivers: |
| 28 | + otlp: |
| 29 | + protocols: |
| 30 | + grpc: |
| 31 | +exporters: |
| 32 | + # Replace this exporter with the exporter for your backend |
| 33 | + logging: |
| 34 | + logLevel: debug |
| 35 | +service: |
| 36 | + pipelines: |
| 37 | + traces: |
| 38 | + receivers: [otlp] |
| 39 | + exporters: [logging] |
| 40 | +``` |
| 41 | +
|
| 42 | +## Component traces |
| 43 | +
|
| 44 | +### kube-apiserver traces |
| 45 | +
|
| 46 | +The kube-apiserver generates spans for incoming HTTP requests, and for outgoing requests to webhooks, etcd, and re-entrant requests. It propagates the [W3C Trace Context](https://www.w3.org/TR/trace-context/) with outgoing requests but does not make use of the trace context attached to incoming requests, as the kube-apiserver is often a public endpoint. |
| 47 | +
|
| 48 | +#### Enabling tracing in the kube-apiserver |
| 49 | +
|
| 50 | +To enable tracing, enable the `APIServerTracing` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) on the kube-apiserver. Also, provide the kube-apiserver with a tracing configration file with `--tracing-config-file=<path-to-config>`. This is an example config that records spans for 1 in 10000 requests, and uses the default OpenTelemetry endpoint: |
| 51 | + |
| 52 | +```yaml |
| 53 | +apiVersion: apiserver.config.k8s.io/v1alpha1 |
| 54 | +kind: TracingConfiguration |
| 55 | +# default value |
| 56 | +#endpoint: localhost:4317 |
| 57 | +samplingRatePerMillion: 100 |
| 58 | +``` |
| 59 | + |
| 60 | +## Stability |
| 61 | + |
| 62 | +Tracing instrumentation is still under active development, and may change in a variety of ways. This includes span names, attached attributes, instrumented endpoints, etc. Until this feature graduates to stable, there are no guarantees of backwards compatibility for tracing instrumentation. |
| 63 | + |
| 64 | +## {{% heading "whatsnext" %}} |
| 65 | + |
| 66 | +* Read about [Getting Started with the OpenTelemetry Collector](https://opentelemetry.io/docs/collector/getting-started/) |
0 commit comments