2

I see there is a DestinationRule - specific config in regards to the tcp keepAlive setting.

I have deployed my app broken down in several microservices in an istio- based k8s infrastructure.

Since in my DestinationRule I have not set up any of the above configs, my question is how will the tcp keepAlive behaviour be laid out at the end of the day?

Will there be no keepAlive functionality?

Will (any) main-container keepAlive workings be able to perform end-to-end over all the connection path and actually enforce the keepAlive in tcp level somehow?

edit: Perhaps I misinterpreting the docs, but what I get from the attached screenshot, is that in the absence of ConnectionPoolSettings.TCPSettings, the keepAlive functionality is not set.enter image description here

pkaramol
  • 16,451
  • 43
  • 149
  • 324
  • From what I see in both [envoy](https://www.envoyproxy.io/docs/envoy/latest/api-v2/api/v2/core/address.proto#core-tcpkeepalive) and [istio](https://istio.io/latest/docs/reference/config/networking/destination-rule/#ConnectionPoolSettings-TCPSettings-TcpKeepalive) docs, it seems like the default for both is 2 hours, so even without destination rule it still should be created with default values, if you create destination rule then these values should be overridden. So there should be `keepAlive` functionality. Let me know if that answer your question or is there anything else bothering you. – Jakub Jan 11 '21 at 14:25
  • pls check my edit since I couldn't upload an image in a comment; on the other hand, what is the difference between the `envoy` keepalive setting and the one configured via `ConnectionPoolSettings.TCPSettings` ? – pkaramol Jan 11 '21 at 18:12
  • I'm sorry @pkaramol, yes, you're correct, you've to add at least the `tcpKeepalive` part to enable the keepalive socket. And there are the default values specified in above docs, unless you specify them, then it's gonna be overridden with your specified values. There is no difference as is the same, istio uses envoy keepalive setting. I'm wondering what is the exact issue of your microservices going down? How long your tcp connections take? Maybe it's the same issue as [here](https://stackoverflow.com/questions/63843610)? – Jakub Jan 12 '21 at 11:07
  • Actually I am in the middle of investigating a series of `Cloudflare` `EdgeResponseStatus=520` incidents whose cause is still unknown, and I am trying to rule out at least the case where `istio` is closing `tcp` connection somewhere in the middle; the link you cited most likely is not my case, since we don't have 1-h long idle connections – pkaramol Jan 12 '21 at 16:55
  • @pkaramol did you find the cause of your HTTP 520 from Cloudflare? – mirobertod Nov 21 '22 at 16:57

0 Answers0