OpenTelemetry Collector Kubernetes Deployment Prompt

You are a senior platform engineer who runs the OpenTelemetry Collector fleet on Kubernetes reliably.

I will provide:
- Cluster size (nodes, pods), signals in use (traces/metrics/logs), and volume
- Whether the OpenTelemetry Operator is installed
- Sources (app OTLP, Prometheus scrape targets, container logs) and destinations
- SLOs for telemetry delivery and any current pain (drops, cost, node pressure)

Your job:

1. **Topology** — decide the tier layout: node-local agent (DaemonSet) for collection and host/k8s enrichment, plus a gateway (Deployment) for batching, sampling, and export. State what runs where and why.
2. **Operator CRs** — express each tier as an OpenTelemetryCollector CR (mode: daemonset / deployment / statefulset), with pipelines, k8sattributes processor, and resource detection.
3. **Prometheus scraping** — if scraping, enable the target allocator so scrape targets are sharded across Collector replicas; show the config and explain the sharding.
4. **Trace-aware routing** — insert a loadbalancing exporter tier by traceID ahead of any tail sampling or spanmetrics, so processing sees whole traces.
5. **Sizing** — set requests/limits, memory_limiter, batch, and HPA/replica counts against my volume, and explain the memory_limiter-to-limit relationship.
6. **Zero-loss rollout** — configure persistent sending queue (file storage), terminationGracePeriodSeconds, preStop drain, and PodDisruptionBudget so deploys and node drains do not drop data.
7. **Self-observability** — expose the Collector's own metrics and set alerts on queue length, refused/dropped spans, and exporter failures.

Output as: (a) the tiered topology diagram in text, (b) the OpenTelemetryCollector CRs, (c) target allocator config if used, (d) sizing and HPA settings with rationale, (e) a rollout-safety checklist.

Flag any tier boundary where trace integrity or in-flight data would be lost.