Stephen Cirner

When the request is successful this is logged. ``` IP_ADDR [31/Jan/2022:05:04:18 +0000] TCP 200 2535 3612 0.159 IP_ADDR [31/Jan/2022:05:04:18 +0000] TCP 200 2535 3612 0.160 ``` Here's an example of...

Sorry, do you mean a typical tls terminated service? Here's an example that serves 100% of the requests as expected. ```yaml apiVersion: v1 kind: Service metadata: annotations: ingress.kubernetes.io/service-upstream: "true" labels:...

This is more of a general question, but for tls_passthrough should the kong service upstream be a resolvable dns name (`service.namespace.svc`) or a pointer to a kong upstream that has...

Last night I deployed the mockbin.org tls_passthrough to two separate k8s clusters with kong. The one cluster resolved correctly 100% of the time. Later today I'm going to start looking...

I'm attempting to get more information here.

@hbagdi Here's some added information that includes the non `tls_passthrough` TCPIngress as well. ## Resources ```yaml apiVersion: v1 kind: Service metadata: annotations: ingress.kubernetes.io/service-upstream: "true" konghq.com/protocol: tcp labels: app: service-core-bank-gateway name:...

I noticed it fails possibly 100% of the time on cold requests, for instance when there's no other requests to that upstream for longer than 30s-1m. After that request fails...

I haven't tested this again on kong newer than `2.7.0`. I ended up not leveraging this feature for now and used dedicated ingresses to route to the low number of...

I moved to rdkafka library. It seems like this library is not maintained.

The problem described here seems similar to the behavior I see with a vector sink as well https://github.com/vectordotdev/vector/issues/14932.