Add gRPC port for jaeger-query into its Service resource

[anhdle14]

Requirement - what kind of business use case are you trying to solve?

I am trying to set up integration via GRPC with Kiali and Jaeger within an Istio-mesh K8s cluster.

• kiali – v1.37.0
• istio – v1.10.3
• jaeger-operator– v1.24.0
  • The CR is a simple AllInOne with no addtional config.

Problem - what in Jaeger blocks you from solving the requirement?

Kiali from v1.37.0 expects the communication port with Jaeger via RPC (16685). In Kiali-operator PR#370.

It was a pain to debug this but here is the list of problems:

• Pod/SVC of jaeger do not expose 16685 by default.

  NAME                      READY   STATUS    RESTARTS   AGE
  jaeger-64bf49b557-ddtlm   1/1     Running   0          89m
  
  NAME           TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)     AGE
  jaeger-query   ClusterIP   10.101.138.58   <none>        16686/TCP   88m

• The CRDs do not support adding additional ports for both SVC and Deployment of Jaeger. At least from what I can see in here: pkg.go.dev/jaegertracing/jaeger-operator
• There is no easy way to reference a full list of supported CR. And Document CR with all the options #671 should be the priority for new people to actually see what are available. And not by going through a go code.

Proposal - what do you suggest to solve the problem or improve the existing situation?

• The easiest way to fix it is: Creating another SVC to expose 16685. Although Pod do not expose 16685, but it will work.. I kind of remember that from reading the K8s docs.
• Adding more granular configuration to all the SVC, Deployment of Jaeger.
• Or support kustomize patch manifests folder with raw k8s yaml.

Any open questions to address

N/A

[jpkrohling]

We should be opening the gRPC port by default for jaeger-query.

[anhdle14]

I think it is more than just adding the query grpc port, It is about allow user to at least patch the resources via the operator. It is ok if there is already an issue for this.

[jpkrohling]

The operator owns the resources it creates, and allowing users to patch it out of band will break this premise. In this particular case, we recommend users to have their own service, managed externally to the operator.