Reintroduce K0smotronNetworks in tests

[juanluisvaladas]

Description

Custom docker networks were removed in #3602 because the custom networks were revealing issues in our test suite.

This effectively means k0smotron cannot bump the k0s dependency to a newer version.

This is a partial revert of 57b5560 getting only the minimum subset that we require for k0smotron.

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation update

How Has This Been Tested?

• Manual test
• Auto test added

Checklist:

• My code follows the style guidelines of this project
• My commit messages are signed-off
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules
• I have checked my code and corrected any misspellings

[twz123]

Did you check if custom networks still affect CoreDNS? It used to be crash-looping when they were used, because of the different DNS setup in Docker containers that are part of custom networks.

[juanluisvaladas]

Did you check if custom networks still affect CoreDNS?

Not yet, I have to test this both in k0s and k0smotron. Once I have that done I will make the PR ready to review.

[juanluisvaladas]

@twz123 I have reployed a few tests and I haven't seen coredns restarting at all. Is there any specific test or action I need to do to reproduce? or can I assume that if check-basic doesn't show restarts it's OK?

[twz123]

I double-checked, and when a k0s worker is run in a bootloose container that's attached to a custom network, CoreDNS will still crash:

.:53
[INFO] plugin/reload: Running configuration SHA512 = a0c06adb3aa41fc5baa9a525a356d4f8e0206ad810f6a0d1f005e63150f4cd85bb682bac617e725b3996ba493aee5bd94a076b3ff9c64726e7e00a033b2ab1ba
CoreDNS-1.11.3
linux/amd64, go1.22.2, a7ed346585e30b99317d36e4d007b7b19a228ea5
[FATAL] plugin/loop: Loop (127.0.0.1:43890 -> :53) detected for zone ".", see https://coredns.io/plugins/loop#troubleshooting. Query: "HINFO 409862789636816999.9009059066361446310."

Integration tests will probably only reliably detect this if they use both a custom network and check for CoreDNS readiness via WaitForCoreDNSReady. A full revert of 57b5560 showed this when running the inttests.

A solution to this is to apply the DNS tweaks from the k0s Docker image's entrypoint in the bootloose image, as well. However, as the k0s inttests themselves don't use any custom networks, nothing will break here. But maybe have an eye on this on the k0smotron side.

[twz123]

See also:

• Add a PodDisruptionBudget for CoreDNS #3585 (comment)

[juanluisvaladas]

Close in favor of k0sproject/k0smotron#712