Logs flooded with TLS handshake error: EOF

[meljishi]

Describe the bug:

The intents operator is flooding our logs with TLS handshake error: EOF errors. We are starting to implement network policies on the cluster but they don't seem to be working. Currently not enforced, just analyzing traffic.

Logs from the intents operator Number of logs on our system

Expected behaviour:

Intents operator should just see the created clientIntents and just report them for the network mapper to show on the app dashboard

Steps to reproduce the bug:

We're just following the simples road we can. No mtls involved (supposedly), no enforcement or anything, so there should be no connection errors

Anything else we need to know?:

Not that I can think of

Environment details::

• Kubernetes version:
• 1.30
• Cloud-provider/provisioner:
• GKE
• intents-operator image version:
• otterize/intents-operator:v2.0.11
• Install method: e.g. helm/static manifests
• Helm

[l-rossetti]

shame issue here.

• kubernetes version: 1.30
• cloud provider: EKS with VPC CNI
• install method: helm
• intents-operator version: otterize/intents-operator:v3.0.0

[amitlicht]

Thank you for reporting this issue @meljishi @l-rossetti.

We have investigated this issue and concluded that other than being noisy, these EOF errors do not indicate any real problem. In our test environments, most of these reports resulted from connections from the Kubernetes control plane, which terminated abruptly without any specific reason.

That said, we agree that the noisy logging is worth fixing. We've invested time and are planning to invest more in figuring out how to make the 3rd-party dependency that's using net/http mute those errors. We will keep you posted through this thread when we have a fix.