Allow overriding interface used by Flannel and refactor network creation in example Terraform configs for Hetzner #3152
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What this PR does / why we need it:
This PR is introducing two distinct changes to improve the Hetzner integration.
Overriding Canal/Flannel interface
For a long time, we had a problem that Hetzner clusters are using the public interface to communicate between nodes. That's a huge problem both from the efficiency side (bandwidth consumption) and from the security side. It can also make problems with some other components, such as CCM and CSI.
The reason why this happens is that Hetzner servers are configured with a default route that uses the public interface. Canal/Flannel are using that default route to determine what network interface should be used for communications between nodes and VXLAN.
This can be mitigated by forcing Flannel to use another interface in two ways:
FLANNELD_IFACE
environment variable or the--iface
flagFLANNELD_IFACE_REGEX
environment variable or the--iface-regex
flagKubeOne didn't fully support any of those mechanisms. Even though it is already possible to edit the
canal-config
ConfigMap and setcanal_iface
which is used as a value for theFLANNELD_IFACE
environment variable, that change would be overridden on the first subsequentkubeone apply
run.This problem is solved by introducing a new parameter for the Canal CNI addon called
IFACE
which can be used like this:However, this requires knowing the interface name and this is not always possible. Instead, it might be better to use the regex to match the interface name or the interface's IP address. This is possible thanks to the
FLANNELD_IFACE_REGEX
option and it's exposed to KubeOne users via theIFACE_REGEX
parameter:Note: using apostrophes is required when passing regex via YAML.
Randomly generating network subnet for Hetzner
We have been using the same subnet for all Hetzner clusters (
192.168.0.0/16
). There are multiple problems:/16
subnet is quite large especially if we want to run multiple E2E tests in parallelTo mitigate this, this PR refactors how we handle networks in the example Terraform configs for Hetzner. We are now randomly generating
/24
subnets in the10.100.0.0/16
range, similar to what are we doing for AWS. This is a breaking change and existing users will have to take additional steps if migrating to the new Terraform configs.What type of PR is this?
/kind feature
Does this PR introduce a user-facing change? Then add your Release Note here:
Documentation:
/assign @kron4eg