hack: IPv6-only kind clusters resolve a stale registry address #1049
Copy link
Copy link
Open
Labels
Description
On IP_FAMILY=ipv6, hack/create-kind-cluster.sh writes the registry's IPv6
address into the CoreDNS Corefile as a hosts entry, read once from
docker inspect at cluster-create time. The script recreates the registry
container whenever its port mapping does not match, and Docker hands the new
container a different address. Every cluster created before that point then
resolves kind-registry to an address nothing is listening on.
The symptom is worse than a missing entry: the name still resolves, so image
pulls fail with connection refused rather than a lookup error, and a
single-cluster dev loop never sees it. The entry is added by #958.
Reactions are currently unavailable
Activity
ygao-g commentedon Aug 20, 2026
An alternative that would close this rather than track it: pin the registry's address when it joins the
kindnetwork, instead of recording whatever Docker assigned.Step 4's bare
docker network connect kind kind-registrybecomesdocker network connect --ip6 <addr>, so a recreated registry container comes back on the same address and an older cluster's Corefile entry stays valid. The address needn't be hardcoded — the v6 subnet is readable fromdocker network inspect kind, and taking a high host address keeps it clear of Docker's sequential assignment from the low end.Two wrinkles. The connect is guarded by an "already connected?" check, so a registry attached by an earlier run keeps its dynamic address until it is disconnected and reattached. And if the pinned address is unavailable the connect fails outright — a better place to find out than a failing image pull.
BenTheElder commentedon Aug 20, 2026
addresses change on reboot. this is why we use DNS
hack: fix DNS on IPv6-only kind clusters
hack: fix DNS on IPv6-only kind clusters
hack: fix DNS on IPv6-only kind clusters
hack: fix DNS on IPv6-only kind clusters