[RFE] Enable CONFIG_INET_DIAG_DESTROY

[adberger]

Current situation

According to https://docs.cilium.io/en/stable/network/kubernetes/kubeproxy-free/#limitations the kernel configs CONFIG_INET_DIAG, CONFIG_INET_UDP_DIAG and CONFIG_INET_DIAG_DESTROY have to be enabled in order for socket-LB to work correctly.
In flatcar CONFIG_INET_DIAG & CONFIG_INET_UDP_DIAG are already enabled, but CONFIG_INET_DIAG_DESTROY is missing:

zgrep -E 'CONFIG_INET_DIAG|CONFIG_INET_UDP_DIAG|CONFIG_INET_DIAG_DESTROY' /proc/config.gz
CONFIG_INET_DIAG=m
CONFIG_INET_UDP_DIAG=m
# CONFIG_INET_DIAG_DESTROY is not set

https://docs.cilium.io/en/stable/network/kubernetes/kubeproxy-free/#limitations:

When socket-LB feature is enabled, pods sending (connected) UDP traffic to services can continue to send traffic to a service backend even after it’s deleted.
Cilium agent handles such scenarios by forcefully terminating application sockets that are connected to deleted backends, so that the applications can be load-balanced to active backends.
This functionality requires these kernel configs to be enabled: CONFIG_INET_DIAG, CONFIG_INET_UDP_DIAG and CONFIG_INET_DIAG_DESTROY. 

Impact

• cilium works correctly when socket-LB is enabled (e.g. when using kubeProxyReplacement)
• slightly bigger image?
• slightly more attack surface?

Ideal future situation

CONFIG_INET_DIAG_DESTROY is available like CONFIG_INET_DIAG & CONFIG_INET_UDP_DIAG

Implementation options

No idea, but probably the same as the CONFIG_INET_DIAG & CONFIG_INET_UDP_DIAG?

Additional information

There is also an issue for Azure Linux, see: microsoft/azurelinux#14108.
So flatcar is not the only OS missing this.

[ader1990]

Hello,

The new config looks good, needs to be tested on the size increase part.
Here is a PR model that can be followed to enable the configuration option: https://github.com/flatcar/scripts/pull/2600/files.

Thanks.

[adberger]

Hello,

The new config looks good, needs to be tested on the size increase part. Here is a PR model that can be followed to enable the configuration option: https://github.com/flatcar/scripts/pull/2600/files.

Thanks.

Thank you :)
Like this: flatcar/scripts#3176 ?

[ader1990]

Hello,
The new config looks good, needs to be tested on the size increase part. Here is a PR model that can be followed to enable the configuration option: https://github.com/flatcar/scripts/pull/2600/files.
Thanks.

Thank you :) Like this: flatcar/scripts#3176 ?

Great, thanks! started the CI, if everything goes well, you should be able to have a downladable and tested image in ~2hours https://github.com/flatcar/scripts/actions/runs/16777223140.

[adberger]

Hmm, didn't seem to work..
Maybe it needs CONFIG_INET_DIAG_DESTROY=y instead of CONFIG_INET_DIAG_DESTROY=m?
I switched it, maybe we can do another build.

[ader1990]

Hmm, didn't seem to work.. Maybe it needs CONFIG_INET_DIAG_DESTROY=y instead of CONFIG_INET_DIAG_DESTROY=m? I switched it, maybe we can do another build.

https://cateee.net/lkddb/web-lkddb/INET_DIAG_DESTROY.html -> the CONFIG_INET_DIAG_DESTROY should have a boolean value, that s why it failed in the first place, should be good to build now. Started a new build, thanks!

[adberger]

Now I don't know what went wrong though 😅

[ader1990]

Now I don't know what went wrong though 😅

This might be a CI fluke, the image was built successfully, but some tests failed: https://github.com/flatcar/scripts/actions/runs/16786336076.

You can download the image for your local testing from the Artifacts tab from Github action page though.

Thanks.

[ader1990]

Now I don't know what went wrong though 😅

Oh, the CI errors are expected, as the github source come from a fork and there are tests that do some pulls from the main repo - and of course - the git pull fails because the git hashes are present only on your fork. My last comment stands valid, you can download the image and test it locally, as the other test cases passed.

Thanks!

[adberger]

Alright, we could successfully boot the image.
Furthermore we could verify that the kernel option is enabled by SSHing on the VM and executing sudo ss -K state established '( dport != 0 )'.
On our old VMs nothing happened, on the new built VM all connections were closed and we got kicked out from SSH.

We couldn't verify if the cilium problem is fixed, since we're currently using https://lts.release.flatcar-linux.net/amd64-usr/4081.3.1/flatcar_production_openstack_image.img. We didn't managed to run the new image as a Kubernetes Node without too much effort as we are not sure about the differences between qemu & openstack and between latest with new kernel option & 4081.3.1 (LTS)

[ader1990]

Your PR commit can be cherry-picked on another branch that bases on the LTS, and we can trigger the image build of 4081 with this cherry-pick, if you consider to be useful to test.

[adberger]

I'm not sure if the problem is with qemu vs. openstack or latest vs. 4081.3.1 (LTS).
In the end would be nice to have this kernel option in the LTS, but I totally get if not.
Up to you to decide :)

Anyway, the kernel option works with the built image from the GitHub Action.