fix(tunnel): propagate half-closed TCP connections

[justfalter]

This change ensures that tunneled TCP connections propagate shut downs when they occur, allowing the opposite party to be signaled appropriately.

A TCP connection can be "half-closed" when A shuts down A->B by sending a FIN to B, and B responds with an ACK. The connection becomes "fully-closed" when the same procedure is followed for the A<-B direction. When a TCP connection is half-closed in the A->B direction, data may continue to flow in the A<-B direction.

This signaling exists as a basic function of the TCP protocol, allowing either party to indicate that they are done sending data, and that their peer can finish up as they please. Data can continue to flow in the opposite direction until they are ready to shut down their side of the connection.

When cloud-provider-kind (t) acts as a tunnel for TCP connections between A and B, we have two connections A-t and t-B, and four flows:

• A->t and t->B (representing A->B).
• A<-t and t<-B (representing A<-B).

Prior to this change, when A shut down A->t, the tunnel would not shut down t->B, leaving A-t half-closed and B-t not closed in any way. The same is true for the opposite direction, as well.

After this change, when A shuts down A->t, cloud-provider-kind immediately shuts down t->B. The same is true when B shuts down t<-B, A<-t is immediately shut down. Flow directions are maintained independently from one-another.

Note: this change effectively restricts tunneled connections to only supporting udp, tcp, tcp4, and tcp6 protocols. As far as I can tell, docker containers will not expose other protocol types (like unix domain sockets).

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: justfalter / name: Mike Ryan (701e540, e798e70)

[k8s-ci-robot]

Welcome @justfalter!

It looks like this is your first PR to kubernetes-sigs/cloud-provider-kind 🎉. Please refer to our pull request process documentation to help your PR have a smooth ride to approval.

You will be prompted by a bot to use commands during the review process. Do not be afraid to follow the prompts! It is okay to experiment. Here is the bot commands documentation.

You can also check if kubernetes-sigs/cloud-provider-kind has its own contribution guidelines.

You may want to refer to our testing guide if you run into trouble with your tests not passing.

If you are having difficulty getting your pull request seen, please follow the recommended escalation practices. Also, for tips and tricks in the contribution process you may want to read the Kubernetes contributor cheat sheet. We want to make sure your contribution gets all the attention it needs!

Thank you, and welcome to Kubernetes. 😃

[k8s-ci-robot]

Hi @justfalter. Thanks for your PR.

I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[aojea]

/ok-to-test

Thanks, just curious, how did you find out about this problem?

is envoy doing the right thing or do we also need to tune the envoy config?

[justfalter]

Thanks, just curious, how did you find out about this problem?

I have a grpc service hosted in a pod, and access it via cloud-provider-kind. I found that the client-side of a grpc server-stream was not getting an io.EOF when the service's pod was restarted. The client side of the server stream would remain connected to the tunnel without tearing down or erroring ... it'd just sit there, waiting for more server-provided messages to show up.

is envoy doing the right thing or do we also need to tune the envoy config?

I'm guessing that envoy is probably doing things properly as it has several orders of magnitude more users that cloud-provider-kind.

[aojea]

I'm guessing that envoy is probably doing things properly as it has several orders of magnitude more users that cloud-provider-kind.

I had an incidence some months ago with envoy because of problems with half closed connections, related to this istio/istio#43297 , that is why I was asking if with current fix it works for you. We solved it setting a timeout for idle connections, but if this is working for you I prefer to keep the defaults

[aojea]

/kind bug
/lgtm
/approve

Thanks

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: aojea, justfalter

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [aojea]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment