cluster-api: Config requiring docker network that supports ipv6 which is not a default setting

What steps did you take and what happened?

While following the rapid iterative deployment with tilt tutorial (https://cluster-api.sigs.k8s.io/developer/tilt.html), an issue was run into with the preconfigured cluster script ./hack/kind-install-for-capd.sh as shown below

Creating cluster "capi-test" ...
 ✓ Ensuring node image (kindest/node:v1.27.3) :frame_with_picture:
 ✓ Preparing nodes :package:
 ✗ Writing configuration :scroll:
Deleted nodes: ["capi-test-control-plane"]
ERROR: failed to create cluster: failed to generate kubeadm config content: failed to get IPv6 address for node capi-test-control-plane

Work around used: editing the /hack/kind-install-for-capd.sh file and removing

networking:
  ipFamily: dual

from the script

What did you expect to happen?

I expected the preconfigured script to work without editing out the networking section. Is this a common workaround? Or are there other ways to configure docker to use IPv6 correctly?

Cluster API version

v1.4.4

Kubernetes version

No response

Anything else you would like to add?

No response

Label(s) to be applied

/kind bug One or more /area label. See https://github.com/kubernetes-sigs/cluster-api/labels?q=area for the list of labels.

About this issue

Original URL
State: closed
Created a year ago
Comments: 18 (9 by maintainers)

Most upvoted comments

Defining the needed mtu value in a docker daemon config file (/etc/docker/daemon.json) worked for me. Like so:

{
   "mtu":1280
}

Then, running the script like usual produces both the cluster and the kind network. The network supports IPv6 and has the correct mtu. You can make sure by running docker network inspect kind.

Hope this helps!

anastaruno on Jul 15, 2023

We could look if there is a way to programmatically understand if ipv6 networking is enabled in docker and it should be enabled in kind? We can always fallback to single stack, but if all the checks pass, we can enable dual stack by default on most systems?

vincepri on Jul 13, 2023

@killianmuldoon But we have it enabled in our e2e tests right? That means when we run our e2e tests against tilt we have a difference in setup if we just drop the setting?

(we could make it configurable via env var and default to the current behavior instead of just dropping the setting)

I would assume in general the current setting works if IPv6 is available. (we didn’t had any complaints before)

I hit the same issue and also used the workaround described above, btw. If it’s relevant I don’t have a functional ipv6 environment locally.

mdbooth on Jul 13, 2023