You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Items marked with (R) are required *prior to targeting to a milestone / release*.
28
+
29
+
-[X] (R) Enhancement issue in release milestone, which links to KEP dir in [kubernetes/enhancements] (not the initial KEP PR)
30
+
-[X] (R) KEP approvers have approved the KEP status as `implementable`
31
+
-[X] (R) Design details are appropriately documented
32
+
-[X] (R) Test plan is in place, giving consideration to SIG Architecture and SIG Testing input
33
+
-[X] (R) Graduation criteria is in place
34
+
-[x] (R) Production readiness review completed
35
+
-[ ] Production readiness review approved
36
+
-[X] "Implementation History" section is up-to-date for milestone
37
+
-[ ] User-facing documentation has been created in [kubernetes/website], for publication to [kubernetes.io]
38
+
-[ ] Supporting documentation—e.g., additional design documents, links to mailing list discussions/SIG meetings, relevant PRs/issues, release notes
39
+
48
40
## Summary
49
41
50
-
This Kubernetes Enhancement Proposal (KEP) proposes enhancing the API Server to allow tracing requests.
42
+
This Kubernetes Enhancement Proposal (KEP) proposes enhancing the API Server to allow tracing requests. For this, it proposes using OpenTelemetry libraries, and exports in the OpenTelemetry format.
51
43
52
44
## Motivation
53
45
@@ -134,34 +126,24 @@ type ServiceReference struct {
134
126
135
127
As the community found in the [Metrics Stability Framework KEP](https://github.com/kubernetes/enhancements/blob/master/keps/sig-instrumentation/20190404-kubernetes-control-plane-metrics-stability.md#kubernetes-control-plane-metrics-stability), having control over how the client libraries are used in kubernetes can enable maintainers to enforce policy and make broad improvements to the quality of telemetry. To enable future improvements to tracing, we will restrict the direct use of the OpenTelemetry library within the kubernetes code base, and provide wrapped versions of functions we wish to expose in a utility library.
136
128
129
+
### Test Plan
130
+
131
+
We will e2e test this feature by deploying an OpenTelemetry Collector on the master, and configure it to export traces using the [stdout exporter](https://github.com/open-telemetry/opentelemetry-go/tree/master/exporters/stdout), which logs the spans in json format. We can then verify that the logs contain our expected traces when making calls to the API Server.
132
+
137
133
## Graduation requirements
138
134
139
135
Alpha
140
136
141
137
-[] Implement tracing of incoming and outgoing http/grpc requests in the kube-apiserver
142
-
-[] E2e testing of apiserver tracing
143
-
-[] User-facing documentation
138
+
-[] Tests are in testgrid and linked in KEP
144
139
145
140
Beta
146
141
147
-
-[] Tracing 100% of requests does not break scalability tests.
142
+
-[] Tracing 100% of requests does not break scalability tests (this does not necessarily mean trace backends can handle all the data).
148
143
-[] OpenTelemetry reaches GA
149
-
-[] Publish documentation on examples of how to use the OT Collector with kubernetes
150
-
151
-
152
-
## Alternatives considered
153
-
154
-
### Introducing a new EgressSelector type
155
-
156
-
Instead of a configuration file to choose between a url on the `Master` network, or a service on the `Cluster` network, we considered introducing a new `OpenTelemetry` egress type, which could be configured separately. However, we aren't actually introducing a new destination for traffic, so it is more conventional to make use of existing egress types. We will also likely want to add additional configuration for the OpenTelemetry client in the future.
157
-
158
-
### Other OpenTelemetry Exporters
159
-
160
-
This KEP suggests that we utilize the OpenTelemetry exporter format in all components. Alternative options include:
161
-
162
-
1. Add configuration for many exporters in-tree by vendoring multiple "supported" exporters. These exporters are the only compatible backends for tracing in kubernetes.
163
-
a. This places the kubernetes community in the position of curating supported tracing backends
164
-
2. Support *both* a curated set of in-tree exporters, and the collector exporter
144
+
-[] Publish examples of how to use the OT Collector with kubernetes
145
+
-[] Allow time for feedback
146
+
-[] Collect feedback from users
165
147
166
148
## Production Readiness Survey
167
149
@@ -229,3 +211,17 @@ This KEP suggests that we utilize the OpenTelemetry exporter format in all compo
229
211
*[Instrumentation of Kubernetes components for 1/24/2019 community demo](https://github.com/kubernetes/kubernetes/compare/master...dashpole:tracing)
230
212
* KEP merged as provisional on 1/8/2020, including controller tracing
231
213
* KEP scoped down to only API Server traces on 5/1/2020
214
+
215
+
## Alternatives considered
216
+
217
+
### Introducing a new EgressSelector type
218
+
219
+
Instead of a configuration file to choose between a url on the `Master` network, or a service on the `Cluster` network, we considered introducing a new `OpenTelemetry` egress type, which could be configured separately. However, we aren't actually introducing a new destination for traffic, so it is more conventional to make use of existing egress types. We will also likely want to add additional configuration for the OpenTelemetry client in the future.
220
+
221
+
### Other OpenTelemetry Exporters
222
+
223
+
This KEP suggests that we utilize the OpenTelemetry exporter format in all components. Alternative options include:
224
+
225
+
1. Add configuration for many exporters in-tree by vendoring multiple "supported" exporters. These exporters are the only compatible backends for tracing in kubernetes.
226
+
a. This places the kubernetes community in the position of curating supported tracing backends
227
+
2. Support *both* a curated set of in-tree exporters, and the collector exporter
0 commit comments