Jaeger Operator

The historical Jaeger Operator automated running Jaeger, a system for following requests across application services, from a Kubernetes custom resource. It created and maintained the components described by that resource instead of requiring operators to assemble them manually. This entry concerns the older controller for Jaeger v1, which is now deprecated. A move to Jaeger v2 needs a different deployment path and careful mapping of the generated services, storage and application exporters.

Current guidance

This resource concerns the jaegertracing.io/v1 Jaeger custom resource and its controller, not every operator capable of running Jaeger. The operator repository now explicitly marks itself deprecated and says it works only with retired Jaeger v1. Upstream directs v2 deployments toward the OpenTelemetry Operator, with a separate v2 Helm chart also documented. Keeping the old controller healthy does not provide ongoing v1 support.

Export existing Jaeger custom resources and inspect the workloads, Services, storage references, secrets and sidecars they generate. Translate those requirements into the chosen v2 deployment model; do not assume that changing a container tag makes the old custom resource compatible. In particular, identify applications using injected agents and the endpoint each exporter actually reaches.

Create a parallel candidate with deliberate ownership of its Kubernetes objects. Verify collector intake, sampling, storage writes and query access before switching clients. Preserve the old query path until historical trace access is understood. Removing a custom resource or controller can trigger deletion through owner references, so inspect that relationship before cleanup and retain independent storage backups. This guidance describes migration planning, not an automatically tested conversion of operator resources.