Use the new k8s distro

[jaronoff97]

Component(s)

collector

Is your feature request related to a problem? Please describe.

We now have a kubernetes distro! 🎉 let's use that
open-telemetry/opentelemetry-collector-releases#507

Describe the solution you'd like

change all our core uses to the k8s distro

Describe alternatives you've considered

No response

Additional context

No response

[pavolloffay]

At the moment the operator uses the core as a default distro https://github.com/open-telemetry/opentelemetry-collector-releases/blob/main/distributions/otelcol/manifest.yaml

The proposal is to use https://github.com/open-telemetry/opentelemetry-collector-releases/blob/main/distributions/otelcol-k8s/manifest.yaml

This will be a breaking change for users. The k8s distribution does not have
receivers:

• kafka
• noop

exporters:

• noop
• logging (deprecated)
• opencensus
• zipkin
• kafka
• prometheus
• prometheusremotewrite

extensions:

• ballast

processors:

• span

[swiatekm-sumo]

So we do need to migrate after all. Thanks for being vigilant about this. In that case, do we go back to the original plan we hatched at KubeCon? That is, set the image to core while converting from v1alpha1 to v1beta1?

[swiatekm-sumo]

Looking at that list, we actually use the prometheus exporter in some tests, which is a bit annoying. We'd need to keep using either core or contrib there.

[jaronoff97]

I do think it may be worth updating the k8s distro to include the prom-remote-write exporter and prom exporter as both of those are things we know operator installations use

[pavolloffay]

I would agree about the p8s exporter.

[swiatekm-sumo]

The k8s distribution rules state: Only exporters that use OTLP are allowed. . That rule can probably be relaxed, but judging from the process of establishing the k8s distribution, I wouldn't count on that happening in less than 3-4 weeks. So if we want to make this change alongside the v1beta1 transition, then we either delay it yet again, or we go with the k8s distribution as-is and pursue adding the additional exporters independently.

Could we also do a cleverer conversion method, where we check which components the Collector is using, and keep core as the default image only if those components aren't present in the k8s distribution?

@TylerHelmuth what do you think? It sounded like you gave some thought to doing this transition in the Helm Chart.

[swiatekm-sumo]

To specifically address some of the differences:

• nopexporter and nopreceiver should probably be included in all distributions. That they aren't yet is due to how new they are.
• deprecated components like loggingexporter and ballastextension should rightfully not be included
• spanprocessor is not included because it's alpha
• kafkareceiver and kafkaexporter should rightfully not be included (why kafka and not any other particular tech?)
• zipkin and opencensus exporters are probably not widely used, and are in practice supplanted by otlp

So that leaves the prometheus exporters, which I do agree merit some consideration, but are probably not blockers for us.

[TylerHelmuth]

There is good history in the PR and issue, but it came down to favoring OTLP in an OpenTelemetry Community distribution over other export protocols - it is a slippery slope supporting other protocols, although an argument could be made for prometheus since it is Kubernetes if you'd like to raise it.

@swiatekm-sumo the specific differences you addressed are all correct except that the spanprocessor was not included bc it is entirely eclipsed by the transformprocessor. Someday I'll have time to move forward with the deprecation process.

[pavolloffay]

I that case I would decouple shipping v1beta1 from the k8s distribution.

[swiatekm-sumo]

Can we do that without a CRD version bump? It's going to a breaking change even if we do add the prometheus components.

[TylerHelmuth]

Is there a feature in the Operator that requires the Prometheus exporter?

[swiatekm-sumo]

There isn't, but exporting metrics to Prometheus is something you'd commonly do in K8s, and ingest via OTLP is still experimental.

[pavolloffay]

Nots from the SIG meeting 2024/04/24 https://docs.google.com/document/d/1Unbs2qp_j5kp8FfL_lRH-ld7i5EOQpsq0I4djkOOSL4/edit

Require users to set the image? It puts more complexity to end users.
Use the upgrade procedure for setting/changing the image
Wait for the helm chart to rollout the change for requiring the default image