What does the OpenTelemetry Operator for Kubernetes actually do? Name the custom resources it introduces and explain what each one buys you compared with deploying the same thing by hand.

## What problem the operator solves Running OpenTelemetry in Kubernetes without an operator means: build collector config into ConfigMaps by hand, keep Deployments/DaemonSets in sync with it, restart on change, and — the painful part — get a language agent into every application image or entrypoint. The operator turns all of that into declarative resources reconciled by a controller, and it does the agent delivery with an admission webhook so application images stay untouched. ## `OpenTelemetryCollector` The spec contains the collector configuration itself plus deployment intent. The **mode** is the key field: - **deployment** — a scalable, centrally reachable gateway. Applications push OTLP to its service. This is where expensive processing (tail sampling, attribute policy, routing to several backends) belongs, because it sees traffic from many pods. - **daemonset** — one instance per node. Correct for anything node-local: reading container logs off the node filesystem, host metrics, or acting as a nearby first hop that batches before a longer network trip. - **statefulset** — stable network identity per replica. The motivating case is Prometheus-style scraping, where each replica must own a deterministic slice of the targets. - **sidecar** — injected into pods annotated for it, giving each application its own local collector. Lowest-latency handoff and per-pod isolation, at the cost of one more container per pod and N copies of the config. The operator reconciles the ConfigMap, the workload, and a Service whose ports it derives from the receivers you declared. Changing the config triggers a managed rollout, which is exactly the fiddly part when hand-rolled. It can also manage autoscaling and expose the collector's own telemetry. ### Target Allocator A separate component the operator can run alongside a StatefulSet collector. It performs service discovery for Prometheus scrape configuration and then *assigns* targets to collector replicas, keeping the assignment stable as replicas and targets change. Without it, every replica scrapes everything (duplicate samples) or you shard by hand. It also supports discovering scrape configuration from Prometheus-ecosystem CRDs, which is what makes migrating an existing Prometheus-operator setup onto collectors realistic. ## `Instrumentation` This resource is the declarative form of 'how should applications in this namespace be instrumented': the auto-instrumentation image per language, the exporter endpoint, the propagator list, sampler defaults, and extra resource attributes. Delivery is by mutating admission webhook. A pod (or its namespace) carries an annotation naming the language — `instrumentation.opentelemetry.io/inject-java`, `...inject-python`, `...inject-nodejs`, `...inject-dotnet`, `...inject-go` (the Go case works differently, via eBPF, and carries stricter requirements) — plus optionally which `Instrumentation` resource to use. The webhook adds an **init container** carrying the agent, mounts a shared volume, copies the agent files onto it, and injects the environment variables that make the runtime load the agent and point it at the right endpoint. The application image never changes. The consequences are worth naming: - Instrumentation becomes **cluster policy**, changeable centrally — a new exporter endpoint or a propagator change is one resource edit plus a pod restart, not a fleet-wide rebuild. - It only applies **at pod creation**, so existing pods must be restarted to pick it up. - Agent version and application runtime version must be compatible; a pinned agent image across a heterogeneous fleet will eventually meet a runtime it does not support. - The webhook is in the pod-admission path. If it is unhealthy and configured to fail closed, pod creation stalls cluster-wide — a genuine blast-radius consideration. - Auto-injection cannot instrument what the agent does not know about, and it cannot see custom business spans; it is a floor, not a ceiling. ## `OpAMPBridge` A third resource that connects managed collectors to an OpAMP server for remote configuration and health reporting. Niche, but worth naming as evidence you have read the operator's surface rather than one blog post. ## Choosing a topology The common production shape is **daemonset or sidecar for collection, deployment for the gateway**: node-local or pod-local collectors do cheap work (receive, batch, add k8s attributes) and forward to a gateway tier that does the expensive, whole-picture work such as tail sampling — which cannot be done correctly at a node that only sees part of each trace. A StatefulSet plus Target Allocator is added when the cluster is also doing scrape-based metrics collection. ## Interview framing Name both primary CRDs, give the four collector modes with a reason for each, explain the init-container injection mechanism concretely, then spend the rest on the operational consequences: restart-to-apply, webhook blast radius, agent/runtime compatibility, and why tail sampling forces a gateway tier.