hack/create-kind-cluster.sh: fix DNS on IPv6-only kind clusters - #958
Draft
Yuan Gao (ygao-g) wants to merge 2 commits into
Draft
hack/create-kind-cluster.sh: fix DNS on IPv6-only kind clusters#958Yuan Gao (ygao-g) wants to merge 2 commits into
Yuan Gao (ygao-g) wants to merge 2 commits into
Conversation
IP_FAMILY selects ipv4, ipv6 or dual and becomes networking.ipFamily, leaving kind's per-family subnet defaults alone. The script also recreates a pre-IPv6 "kind" Docker network, fails fast if the daemon has IPv6 off, sets proxy_ndp alongside proxy_arp for gVisor pod-to-pod traffic, and repoints an ipv6 kubeconfig from [::1] at localhost so a client outside the Docker host can still reach the apiserver. Tested on kind with all three families: node InternalIPs, Service ClusterIPs and pod IPs land in the requested families, pod-to-pod and CoreDNS work on them, and pods still pull through the local registry.
CoreDNS runs dnsPolicy: Default and inherits the node's Docker-generated /etc/resolv.conf, which always names an IPv4 resolver -- unreachable from a v6-only pod, so every external lookup dies at "connect: network is unreachable". Behind that sits a second failure: this script wires the registry into containerd on the node, but atelet pulls actor images from its own pod netns, where kind-registry does not resolve at all. Rewrite the Corefile on IPv6-only clusters: a hosts block mapping kind-registry to the registry's GlobalIPv6Address, with fallthrough so non-registry names still reach the new IPv6 forwarder. Hard-fail if the substitution was a no-op, and probe both names from a pod rather than the node, which is dual-stack and would resolve them either way.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
On a fresh
IP_FAMILY=ipv6cluster nothing resolves from inside a pod, so no actor ever boots. Two causes:dnsPolicy: Defaultand inherits the node's Docker-generated/etc/resolv.conf, which always names an IPv4 resolver. Pods here have no IPv4 address, so every external lookup dies atconnect: network is unreachable, and anything that fetches at runtime — atelet pulling the gVisor tarball, for one — never starts.kind-registryNXDOMAINs.Two Corefile clauses fix both: a
hostsblock mappingkind-registryto the registry's IPv6 address, withfallthroughso every other name still reaches the forwarder, and aforwardto an IPv6 upstream overridable viaIPV6_DNS_UPSTREAM. The patch hard-fails if the substitution is a no-op — a silent no-op is the whole failure mode — and probes both names from a pod rather than the node, which is dual-stack and would resolve them either way.Everything is inside
if [[ "${IP_FAMILY}" == "ipv6" ]], so IPv4 and dual-stack clusters are unchanged.Stacked on #877 for the
IP_FAMILYknob. GitHub will not accept a base branch that lives only in a fork, so this targetsmainand #877's commit rides along in the diff. Do not merge before #877.Verified by the IPv6-only e2e job in #939: full control-plane install plus the
demoandnetworkingsuites on a v6-only cluster.Part of #246.