Add SO_REUSEPORT support for EntryPoints

[aofei]

What does this PR do?

Add SO_REUSEPORT support for EntryPoints.

Motivation

Attempts to solve the problem of canary deployment against Traefik itself.

Fixes #9823

More

• Added/updated tests
• Added/updated documentation

Additional Notes

This PR only focuses on the implementation. For discussion, please move to #9823.

[mloiseleur]

I tested this PR.
It works like a charm.

[rtribotte]

Hello @aofei,

I can see that the update of the static configuration references files is missing:

• docs/content/reference/static-configuration/file.toml
• docs/content/reference/static-configuration/file.yaml

Can you please update them?

[aofei]

Hi @rtribotte!

I have just updated those two files and rebased my branch as well.

[aofei]

Also, should I change the base branch of this PR from master to v3.0?

[rtribotte]

@aofei Thanks for the changes!

Also, should I change the base branch of this PR from master to v3.0?

For now, I don't know, I'm going to raise a discussion with other maintainers on that subject and let you know.

[rtribotte]

Hello @aofei,

I came across this article mentioning limitations associated with the SO_REUSEPORT directive, especially the closing of connections by the kernel when one of the processes using the port exits:

There are a number of reasons why a listening process might exit on a busy system. Perhaps it simply crashed. But, more likely, the server is being restarted to effect a configuration change or to switch to a new certificate. Such restarts can be phased across a pool of server processes so that they don't all exit at once; that should allow incoming connections to be handled without any apparent interruption of service. But when the above-described behavior comes into the picture, users can be turned away, which tends to have an unpleasant effect on their mood. The depressive effect on the operator of the site, who may have just lost the opportunity to learn that the would-be user is in the market for a new pair of socks, can be even worse.

I'm hoping to get your insights, but so far, these limitations could be a significant concern for Traefik users, at least I think this should be documented.

[rtribotte]

Also, should I change the base branch of this PR from master to v3.0?

@aofei So, as a follow-up, yes please, if you can rebase this PR on the v3.0 branch it would be great, we would like to have it for v3.

[aofei]

@rtribotte Yes, you're right, thanks for bringing it up! It's a known bug in the SO_REUSEPORT implementation of the Linux kernel.

In case anyone else is interested, the problem mentioned by @rtribotte is that when a listening process exits, all incoming TCP connections assigned to it that are either in the middle of a 3WH (3-way handshake) or in the accept queue get closed, even if other processes could handle them. The root cause of this problem is that once the kernel assigns an incoming connection to a specific process (triggered by the arrival of the initial SYN packet of a 3WH), it won't reassign it, leading to connection failures (RST packets) when that process exits.

A common workaround is to pass the listener file descriptors between different processes without closing them. For example, Nginx does this, thanks to its concept of worker processes. Unfortunately, this doesn't work with Traefik, as Traefik is a single process.

While this is a problem, it doesn't make SO_REUSEPORT a bad feature. It's a kernel bug, until it's resolved or a workaround is found, I agree that it should be documented.

[aofei]

@rtribotte I have updated the docs/content/routing/entrypoints.md documentation file and changed the base branch of this PR from master to v3.0. The failed checks don't seem relevant to this PR. Please let me know if I've got something wrong.

[nmengin]

Hey @aofei,

It seems that you have conflicts, could you fix them?
Do you need help on it?

[aofei]

Hi @nmengin! Thanks for letting me know about the conflicts. They occurred after my last commit, so I didn't notice. They have now been fixed.

[nmengin]

Hey @aofei,

Thank you for your quick answer and action.

[kevinpollet]

Thanks for this contribution!

[nmengin]

LGTM 👏

Thank you @aofei 👍

[aofei]

@kevinpollet @rtribotte I just made the changes you requested. Please let me know if I've got something wrong.

[kevinpollet]

Thanks 👍

[rtribotte]

Thanks!

[juliens]

LGTM

[nmengin]

LGTM