Jaeger Collector and Kubernetes probes: which health-check contract is supported?

Assume a Jaeger Operator deployment using the v1 CRD API and a Jaeger 1.x collector; the exact Operator, Jaeger, and Kubernetes or OpenShift versions remain to be confirmed. The integration boundary is the collector’s health-check interface and the cluster’s probe implementation. HTTP probes, native gRPC probes, and Operator-managed probe fields are not necessarily interchangeable across releases.

The design goal is to select one documented probe contract that remains valid during a supported upgrade path. The decision must account for the collector’s gRPC service semantics, its admin HTTP interface, and the minimum cluster version supporting the selected probe type. It should also avoid coupling the deployment to an endpoint whose behavior is not covered by the relevant Jaeger release documentation.

Before implementation, the Jaeger release notes, Operator CRD schema, and target cluster documentation need to be checked for version-specific constraints. Which probe type and endpoint are supported together for the intended Jaeger and cluster versions, and which version assumptions should be recorded in the deployment design?