-
Notifications
You must be signed in to change notification settings - Fork 4.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
hyperkit: external DNS resolution fails: conflict with DNS server running on host #3036
Comments
I have exactly the same issue
|
Same here, had that issue a couple month ago alrady and just tried again after upgrading all components it is still there:
|
Interesting - it sounds like kube-dns is effectively broken within minikube. https://kubernetes.io/docs/tasks/administer-cluster/dns-debugging-resolution/ has some tips on how to debug internal DNS service issues. Do you mind sharing the output of: kubectl get svc --namespace=kube-system
kubectl get ep kube-dns --namespace=kube-system
kubectl logs --namespace=kube-system $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name | head -1) -c kubedns
kubectl logs --namespace=kube-system $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name | head -1) -c dnsmasq
kubectl logs --namespace=kube-system $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name | head -1) -c sidecar Thanks! |
Also, please check if the host (Mac OS) has anything listening on port 53 already, or specifically, if dnsmasq is running. |
In my case, I have something listening on Update, fix to my issue:
Note: If My
|
Yep, I am using dnsmasq on local host, it is neccesary for routing *.kube hosts to minikube |
It seems there is progress ongoing .. there is an open PR with a workaround: https://github.com/kubernetes/minikube/pull/3003/files |
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
https://github.com/kubernetes/minikube/blob/master/docs/drivers.md#hyperkit-driver there is a problem with the current solution, dnsmasq will fail to start when minikube is not running, 192.168.64.1 does not exist finally I decided to stop my dnsmasq when running minikube, this is a easy way |
I am using minikube using the hyperkit driver on macOS and experiencing the same problems with dnscrypt-proxy, which listens on 127.0.0.1:53 (udp+tcp). This binary is part of the Cisco Umbrella (corporate OpenDNS) roaming client. I cannot modify the configuration used by dnscrypt-proxy. The dnsmasq.conf changes linked are insufficient to resolve the issue for others. Is there no way to apply a persistent DNS configuration change to minikube and the system pods?
|
I've upped the priority based on the number of votes. Help wanted! |
I imagine a lot of people will have this type of problem now that the docker desktop issue is forcing our hands. Here's my error to add to the list; hope its helpful. It seems like its' saying the same thing everyone else is saying. ❌ Exiting due to K8S_INSTALL_FAILED: updating control plane: downloading binaries: downloading kubeadm: download failed: https://storage.googleapis.com/kubernetes-release/release/v1.23.2/bin/linux/amd64/kubeadm?checksum=file:https://storage.googleapis.com/kubernetes-release/release/v1.23.2/bin/linux/amd64/kubeadm.sha256: getter: &{Ctx:context.Background Src:https://storage.googleapis.com/kubernetes-release/release/v1.23.2/bin/linux/amd64/kubeadm?checksum=file:https://storage.googleapis.com/kubernetes-release/release/v1.23.2/bin/linux/amd64/kubeadm.sha256 Dst:/Users/kobebryant/.minikube/cache/linux/v1.23.2/kubeadm.download Pwd: Mode:2 Umask:---------- Detectors:[0x70f4bb8 0x70f4bb8 0x70f4bb8 0x70f4bb8 0x70f4bb8 0x70f4bb8 0x70f4bb8] Decompressors:map[bz2:0x70f4bb8 gz:0x70f4bb8 tar:0x70f4bb8 tar.bz2:0x70f4bb8 tar.gz:0x70f4bb8 tar.xz:0x70f4bb8 tar.zst:0x70f4bb8 tbz2:0x70f4bb8 tgz:0x70f4bb8 txz:0x70f4bb8 tzst:0x70f4bb8 xz:0x70f4bb8 zip:0x70f4bb8 zst:0x70f4bb8] Getters:map[file:0xc001177190 http:0xc000435900 https:0xc000435920] Dir:false ProgressListener:0x70b6540 Insecure:false Options:[0x5452be0]}: invalid checksum: Error downloading checksum file: bad response code: 404 |
In my case I had unused bind9 aside dnsmasq coming with NetworkManager To solve it, did: sudo apt purge bind9
sudo systemctl restart network-manager
sudo systemctl restart Network-Manager |
looks like in my case it's |
As a workaround, following change on running
Instead of Update: above workaround looks temporary, more persistent workaround here: #13497 (comment) |
I was having the same issue on OS X running
|
@nikolay-te Discovered that pf is angry if you don't put the rule in the right order:
So I:
sudo pfctl -f /etc/pf.conf I'm on a Mac that's smothered with Cisco Umbrella sauce. BTW, I can't run minikube AT ALL unless I disconnect from my corporate VPN This allowed my minikube VM to hit my corporate private registry url via Umbrella's DNS I also have dnscrypt-proxy running:
|
Can someone on this thread that doesn't have "Cisco Umbrella sauce" (sadly, that includes me) do a In particular, I'm wondering if minikube's DNS server, whatever that is, is trying to bind to all interfaces, instead of just the bridge. If I'm looking at this right, I'm wondering why there should be a conflict here: Umbrella only binds to |
Can make this work with driver 'hyperkit' on MAC
Post that in the minikube /etc/resolv.conf we will see a new entry of nameserver 8.8.8.8 along with 192.168.64.1 $ cat /etc/resolv.conf | grep name NOTE : If we directly edit file "/etc/resolv.conf" with 8.8.8.8, It will revert back to old setting since its been maintained by the systemd-resolved.service .
|
Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG REPORT
Please provide the following details:
Environment: MacOS High Sierra
Minikube version (use
minikube version
): 0.25.0 and abovecat ~/.minikube/machines/minikube/config.json | grep DriverName
): hyperkitcat ~/.minikube/machines/minikube/config.json | grep -i ISO
orminikube ssh cat /etc/VERSION
): .minikube/cache/iso/minikube.25.0.0.isoWhat happened: dns in minikube does not work. DNS cluster can not start, because can not download images from registry. 192.168.64.1 - it is my host IP
What you expected to happen: DNS works. If I change DNS server in minikube to 8.8.8.8, it works.
How to reproduce it (as minimally and precisely as possible):
Output of
minikube logs
(if applicable):Anything else do we need to know:
The text was updated successfully, but these errors were encountered: