opentelemetry-operator
opentelemetry-operator copied to clipboard
Label "sidecar.opentelemetry.io/injected" value sometimes longer than 63 characters
With an OpenTelemetryCollector
in sidecar
mode, the sidecar.opentelemetry.io/injected
label gets added to the pod using the format [otc_namespace].[otc_name]
https://github.com/open-telemetry/opentelemetry-operator/blob/07b9f22df8a87852464bf4877d793afcddae37c3/pkg/sidecar/pod.go#L48
Under the right conditions, the label value can exceed 63 characters, which causes Kubernetes controllers to produce the following error:
Error creating: Pod "[name]-59ff54b4c6-9mh4g" is invalid: metadata.labels: Invalid value: "[otc_namespace].[otc_name]": must be no more than 63 characters
(Replace brackets with sufficiently long values.)
If the name of the OpenTelemetryCollector
does not identify it as such, this error message is particularly cryptic as it is not obvious what is producing the invalid label. (Took me a while to dig through various controllers and mutating webhooks to find the culprit. Though arguably this is more an issue with how Kubernetes reports such errors.)
Possible solutions:
- Move
sidecar.opentelemetry.io/injected
to annotations- Annotations do not have the same restrictions on values as labels
- Allow user to disable addition of
sidecar.opentelemetry.io/injected
label- Presumably this would be an option in the
OpenTelemetryCollector
resource
- Presumably this would be an option in the
- Split the
[otc_namespace]
and[otc_name]
across multiple labels- This is how I've seen other projects handle such cases. Since Kubernetes object names and label values have the same restrictions, you can safely put the
[otc_namespace]
in one label and the[otc_name]
in another, guaranteeing that they will never exceed the character limit.
- This is how I've seen other projects handle such cases. Since Kubernetes object names and label values have the same restrictions, you can safely put the
Would be happy to open a PR with your preferred solution. Thanks 🙂
An implementation of solution 3, which also maintains backwards compatibility, can be found here: https://github.com/open-telemetry/opentelemetry-operator/pull/1032