Change:
What happened: Deployment of node-local-dns in an ipv6-only cluster fails with the following iptables-related error Does node-local-dns support binding to IPv6 addresses? If not, can node-local-dns be used in an ipv6-only cluster? What you expected to happen: node-local-dns is up and running normally and binding to an ipv6 link-local address How to reproduce it (as minimally and precisely as possible): Create an ipv6-only cluster using nodes with single ipv6 stack Anything else we need to know?: Environment: Kubernetes version (use ): v1.18.2 Cloud provider or hardware configuration: Openstack VMs OS (e.g: ): SLES 15 SP1 Kernel (e.g. ): 4.12.14-197.45-default Install tools: kubeadm Network plugin and version (if this is a network-related bug): calico v3.12.0 Others:
/sig network
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
seems that node-local-dns only supports IPv4
looks like whatever's calling might need to have a log msg b4 it
/assign
Looks like there's already a logging statement for running iptables checks: Perhaps the log level was too low for that log message to get tripped?
hi Matt, ok so your looking at the logs? If you want you can into one of your kind nodes. Then edit run and if you wanna hack around in there, and open inside that container, which will allow you to play with the logging verbosity of Kubelet. If you decide its a good idea to surface this info then you can test there (). There are probably ways to plumb Kubelet args directly into kind also but that's just my off the cufff answer :)
/assign
/assign /assign
Not yet, node-local-dns is not supported to run on ipv6-only clusters.
/remove-triage unresolved
Thank you for letting me know, and thank you all for your efforts following through with the issue, I'll keep watch for any future updates on the feature.
I put together a patch to to make it more clear in this case what the issue is. Do you think it's worth moving forward with adding that log statement? (I know I'd have to redo the patch differently, I did it a really dumb way and sure there's a much much better way :) ) Happy to do the leg work on this! Thanks for the guidance! Edit: forgot to mention, this is only supposed to be a stopgap short-term solution before node-local-dns gets support for IPv6!
so , is what pramesh is suggesting as simple as running something in to figure out if there is an ipv4 address... and if not, ... fail ?
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale /assign I have a PR ready, but we need to update the KEP, the docs and add some testing, ... targeting 1.21

Discussion:
sleep 2 done <ins> # Basic sanity checking for (( i=0; i<${#MINION_NAMES[@]}; i++)); do # Make sure docker is installed gcutil ssh ${MINION_NAMES[$i]} which docker > /dev/null if [ "$?" != "0" ]; then echo "Docker failed to install on ${MINION_NAMES[$i]} your cluster is unlikely to work correctly" echo "Please run ./cluster/kube-down.sh and re-create the cluster. (sorry!)" exit 1 fi # Make sure the kubelet is running gcutil ssh ${MINION_NAMES[$i]} /etc/init.d/kubelet status if [ "$?" != "0" ]; then echo "Kubelet failed to install on ${MINION_NAMES[$i]} your cluster is unlikely to work correctly" echo "Please run ./cluster/kube-down.sh and re-create the cluster. (sorry!)" exit 1 fi done </ins> echo echo "Kubernetes cluster is running.  Access the master at:" echo