Description
Component(s)
target allocator
Describe the issue you're reporting
The Target Allocator subresource of the OpenTelemetryCollector CR has been growing in size over time, in particular due to various infrastructure-related attributes that users rightfully want to set for it. It’s time to split it into its own CRD, improving separation of concerns and reducing the size of the Collector CRD.
Design
The TargetAllocator CRD should contain all the fields the Target Allocator subresource currently does, to begin with. We will later continue adding fields to it, while possibly deprecating some fields from the subresource. The subresource should always only contain a subset of the CRD fields. Internally, the operator will create a CRD based on the subresource, which is how we’ll maintain backwards compatibility.
apiVersion: opentelemetry.io/v1alpha1
kind: TargetAllocator
metadata:
name: example
spec:
scrapeConfigs:
- job_name: otel-collector
scrape_interval: 10s
static_configs:
- targets:
- 0.0.0.0:8888
- 0.0.0.0:9999
prometheusCR:
enabled: true
..
Relation to the Collector CR
A Collector can be configured to use a given target allocator by setting a label on the collector CR:
apiVersion: opentelemetry.io/v1beta1
kind: TargetAllocator
metadata:
name: example
labels:
opentelemetry.io/target-allocator: example
spec:
config:
receivers:
prometheus:
...
Collectors and Target Allocators are independent, neither owns the other, and each can in principle run on their own. By establishing a connection between them, certain aspects of their configuration will change under the hood.
Rollout
We should be able to roll out most of the necessary changes without any user-facing change:
- Add the type definitions for the TargetAllocator CRD
- Generate the TargetAllocator CR from the subresource
- Use the generated TargetAllocator CR to generate target allocator manifests
- Add webhooks for TargetAllocator without enabling them
- Enable the webhooks and reconciliation for the TargetAllocator CR