Changing service cidr range breaks DNS resolution #5727
Labels
area/networking
networking issues
co/service
issues related to the service feature
help wanted
Denotes an issue that needs help from a contributor. Must meet "help wanted" guidelines.
kind/bug
Categorizes issue or PR as related to a bug.
priority/backlog
Higher priority than priority/awaiting-more-evidence.
Comments
|
@jgoeres thanks for creating this issue ! this does seem to be a bug. I would love minikube to be able to create service in CIDR ranges that works well for everyone including corp networks ! I would be happy to review any PR to fix this issue ! |
medyagh
added
priority/backlog
sharifelgamal
added
the
help wanted
|
I was able to repro this with in January with v1.6.2: minikube start --keep-context --kubernetes-version=1.16.6 --memory=2536mb --service-cluster-ip-range=10.64.0.0/16 --vm-driver=vmware -p newerkubekubectl run my-shell --rm -i --tty --image cosmintitei/bash-curl -- bashbash-4.4# cat /etc/resolv.conf
nameserver 10.96.0.10
search default.svc.cluster.local svc.cluster.local cluster.local
options ndots:5 |
|
Same issue here on macOS with the latest version. |
vijaykatam
added a commit
to vijaykatam/minikube
that referenced
this issue
Feb 3, 2020
Removed hardcoded `cluster-dns` IP 10.96.0.10, this allows kubelet to use `clusterDNS` configured by kubeadm in `/var/lib/kubelet/config.yaml` Tested by starting minikube with `--service-cluster-ip-range=100.64.0.0/13` and verifying DNS resolution works. /etc/systemd/system/kubelet.service.d/10-kubeadm.conf ``` [Unit] Wants=docker.socket [Service] ExecStart= ExecStart=/var/lib/minikube/binaries/v1.17.0/kubelet --authorization-mode=Webhook --bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --cgroup-driver='cgroupfs' --client-ca-file=/v ar/lib/minikube/certs/ca.crt --cluster-domain=cluster.local --config=/var/lib/kubelet/config.yaml --container-runtime=docker --fail-swap-on=false --hostname-override=minikube --kubeconfig=/e tc/kubernetes/kubelet.conf --node-ip=192.168.64.7 --pod-manifest-path=/etc/kubernetes/manifests [Install] ``` DNS resolution test ``` kubectl run -i --tty --rm busybox --image=busybox --restart=Never -- sh If you don't see a command prompt, try pressing enter. / # nslookup kubernetes.io Server: 100.64.0.10 Address: 100.64.0.10:53 Non-authoritative answer: Name: kubernetes.io Address: 147.75.40.148 ``` Fixes: kubernetes#5727
vijaykatam
added a commit
to vijaykatam/minikube
that referenced
this issue
Feb 5, 2020
Removed hardcoded `cluster-dns` IP 10.96.0.10, this allows kubelet to use `clusterDNS` configured by kubeadm in `/var/lib/kubelet/config.yaml` Tested by starting minikube with `--service-cluster-ip-range=100.64.0.0/13` and verifying DNS resolution works. /etc/systemd/system/kubelet.service.d/10-kubeadm.conf ``` [Unit] Wants=docker.socket [Service] ExecStart= ExecStart=/var/lib/minikube/binaries/v1.17.0/kubelet --authorization-mode=Webhook --bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --cgroup-driver='cgroupfs' --client-ca-file=/v ar/lib/minikube/certs/ca.crt --cluster-domain=cluster.local --config=/var/lib/kubelet/config.yaml --container-runtime=docker --fail-swap-on=false --hostname-override=minikube --kubeconfig=/e tc/kubernetes/kubelet.conf --node-ip=192.168.64.7 --pod-manifest-path=/etc/kubernetes/manifests [Install] ``` DNS resolution test ``` kubectl run -i --tty --rm busybox --image=busybox --restart=Never -- sh If you don't see a command prompt, try pressing enter. / # nslookup kubernetes.io Server: 100.64.0.10 Address: 100.64.0.10:53 Non-authoritative answer: Name: kubernetes.io Address: 147.75.40.148 ``` Fixes: kubernetes#5727 fix lint errors
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Our company intranet uses large parts of the 10.0.0.1/8 subnet. Alas, the default service CIDR range used by minikube (resp. kubeadm?) is 10.96.0.*. To avoid problems, I wanted to change pod and service CIDR range with these two options passed to minikube start:
--service-cluster-ip-range='172.20.0.0/14' --extra-config=kubelet.pod-cidr=172.16.0.0/14
The VM seemed to startup fine, but after deploying our application, I noticed that the DNS names of services could not be resolved by our pods, e.g.
I checked /etc/resolv.conf inside the pod, and indeed, it still pointed to the default IP of the kubedns service, i.e., 10.96.0.10. I would expect that changing the service CIDR range would also take care of that.
Looking for a workaround, I tried using extra-config also for the service-cidr range, i.e.,
Now the minikube start would fail cause kubelet wouldn't start:
.
The text was updated successfully, but these errors were encountered: