Operator configured service port names do not match istio convention

[frzifus]

Additional information

ServicePort names generated by the operator are not compatible with the istio naming convention. This leads to problems when using gRPC. Envoy (istio sidecar) uses the port name to determine the protocol used. For example if TLS traffic is transmitted or not. According to convention, a port handling tls traffic should have the prefix tls- or https-. Alternatively, since kubernetes 1.20 a new field appProtocol in the servicePort can be used to provide protocol information.

What is the problem?

Envoy as well as HAProxy [#902] fail the tls handshake if it is unclear what type of traffic it is. We saw the same issue on the jaeger-operator#2101 project.
authentication handshake failed: tls: first record does not look like a TLS handshake

How are port names generated?

Currently, these are generated based on the collector configuration (${receiver}-${suffix}).

# in this case, we have two ports, named: examplereceiver and examplereceiver-settings
receivers:
  examplereceiver:
    endpoint: 0.0.0.0:12345
  examplereceiver/settings:
    endpoint: 0.0.0.0:12346

In the case of otlp, it is only possible to use tls or grpc as prefix or appProtocol with a work around. Therefore the desired port name or protocol must be specified in the CR.

Example

apiVersion: opentelemetry.io/v1alpha1
kind: OpenTelemetryCollector
metadata:
  name: simplest
spec:
  mode: "deployment"
  ports:
    - name: grpc-otlp
      appProtocol: grpc
      port: 4317
  config: |
    receivers:
      otlp:
        protocols:
          grpc:
    exporters:
      logging:
    service:
      pipelines:
        traces:
          receivers: [otlp]
          processors: []
          exporters: [logging]

Possible solutions

One of the easiest ways to do this would be to reverse the orientation of the generated names.
E.g.: ${receiver}-${info} => ${info}-${receiver}
However, this would be a breaking change. Since manually created ingress entries or similar would no longer work.

In the case of otlp, the configuration provides all the necessary information to use the appProtocol field. If the insecure=false it is tls traffic. In case of insecure=true the specified protocol can be used (e.g. gRPC or HTTP). However, I am not sure that all receivers provide these configurations.

[JaredTan95]

same isssue meet in open-telemetry/opentelemetry-helm-charts#589, and I'd like to support it in otel-operator, pls assign it to me.

[pavolloffay]

@frzifus was this resolved?

[frzifus]

nope - might be a topic for the SIG call.

[jaronoff97]

@frzifus should we do this with v2?

[frzifus]

Ive to check if that is still an issue. Since we dropped v1.19 support as far as I understand appProtocol should be enough.

https://kubernetes.io/docs/concepts/services-networking/service/#application-protocol

[jaronoff97]

oh so can i close this?

[fujin]

I just hit this and used appProtocols/custom names as described in the issue via the ports spec to workaround

forgive me, but it would be nice if the port names were istio naming convention/protocol detection compatible without needing to :-)

[GeniyX]

I think that changing the port name may cause backward compatibility problems.
However, you can leave the port name unchanged and add the appProtocol field to the generator.

According to the documentation https://istio.io/latest/docs/ops/configuration/traffic-management/protocol-selection/#explicit-protocol-selection if the appProtocol value is present, the port name is ignored.