Introduce kustomizaton manifests for standalone deployment of TA

[odubajDT]

Component(s)

target allocator

Problem

The Target Allocator (TA) can only be deployed via the OpenTelemetry Operator today. Users who want to run the TA without the operator - for example in environments where installing a CRD-based operator isn't feasible, or when managing their own collector fleet - have no official deployment manifests to work with. They must reverse-engineer the operator-generated resources or write their own from scratch.

Proposal

Add a cmd/otel-allocator/deploy/ directory containing kustomize base manifests for deploying the TA standalone:

Resource	Description
ServiceAccount	Identity for the TA pod
ClusterRole	Read access to pods, nodes, services, endpoints, endpointslices
ClusterRoleBinding	Binds the ClusterRole to the ServiceAccount
Deployment	Runs the TA (1 replica, mounts config from ConfigMap)
Service	Exposes port 80 → 8080 for collectors
kustomization.yaml	Kustomize base with image placeholder

Users provide their own ConfigMap with targetallocator.yaml and create a kustomize overlay to set namespace, image tag, and ClusterRoleBinding subject namespace.

Why kustomize

• Already used throughout this project and the broader Kubernetes ecosystem
• Users can reference the base directly from GitHub (github.com/open-telemetry/opentelemetry-operator/cmd/otel-allocator/deploy)
• Easy to override image, namespace, and names via overlays
• No additional tooling required beyond kubectl apply -k

E2E validation

An accompanying Go-based integration test prepared here deploys the TA from these manifests into a kind cluster, verifies target distribution across collectors, tests scale-up/down with consistent hashing, and validates the HTTP API contract - all without the operator.

Acceptance criteria

• Kustomize base in cmd/otel-allocator/deploy/ with README
• kustomize build produces valid, deployable manifests
• E2E test verifies standalone deployment works end-to-end
• CI job runs the standalone TA test

[swiatekm]

We discussed this during the SIG meeting on 09.04.2026 and decided that we want to do it. There are a few open questions regarding the actual implementation.

1. Where should this live in the directory hierarchy? cmd/otel-allocator is an obvious choice, but there's an argument in favor of keeping all the manifests in config.
2. What should the default image version be? latest makes the most sense to me, as otherwise we'd need to update after each release.
3. What should the default configuration do? I think we should align it with the Helm Chart.

[odubajDT]

We discussed this during the SIG meeting on 09.04.2026 and decided that we want to do it. There are a few open questions regarding the actual implementation.

Happy to hear that!

1. Where should this live in the directory hierarchy? `cmd/otel-allocator` is an obvious choice, but there's an argument in favor of keeping all the manifests in `config`.

Fully agree.

2. What should the default image version be? `latest` makes the most sense to me, as otherwise we'd need to update after each release.

No issue with using latest at this moment, but would it potentially be that big of an issue to have a pinned version int he future? We have mechanisms to achieve this

3. What should the default configuration do? I think we should align it with the [Helm Chart](https://github.com/open-telemetry/opentelemetry-helm-charts/tree/main/charts/opentelemetry-target-allocator).

Agree, we should match the helm-charts.

[swiatekm]

No issue with using latest at this moment, but would it potentially be that big of an issue to have a pinned version int he future? We have mechanisms to achieve this

There's an annoying chicken-and-egg situation where ideally we should have it set to the release version in the commit tagged for release, but that also means it's going to be invalid on main before the actual release happens. I'm not sure how big a problem that really is, though.

[odubajDT]

No issue with using latest at this moment, but would it potentially be that big of an issue to have a pinned version int he future? We have mechanisms to achieve this

There's an annoying chicken-and-egg situation where ideally we should have it set to the release version in the commit tagged for release, but that also means it's going to be invalid on main before the actual release happens. I'm not sure how big a problem that really is, though.

Here's how the the exact same problem is solved for the operator controller image:

• kustomization.yaml has NO image reference at all — it's just resources: [manager.yaml]
• The set-image-controller Make target dynamically sets the image via kustomize edit set image
• ensure-update-is-noop runs set-image-controller with VERSION=$(OPERATOR_VERSION) from versions.txt, and then checks git diff config to ensure it's committed

The same pattern should work here. I already adapted the PR to use it.