无法在kubernetes中解析dns
Can't resolve dns in kubernetes
我使用下一个命令检查我的 k8s 中的 dns 问题:
kubectl apply -f https://k8s.io/examples/admin/dns/dnsutils.yaml
kubectl exec -i -t dnsutils -- nslookup kubernetes.default
nslookup 结果是:
;; connection timed out; no servers could be reached
command terminated with exit code 1
dnsutils.yaml:
apiVersion: v1
kind: Pod
metadata:
name: dnsutils
namespace: default
spec:
containers:
- name: dnsutils
image: gcr.io/kubernetes-e2e-test-images/dnsutils:1.3
command:
- sleep
- "3600"
imagePullPolicy: IfNotPresent
restartPolicy: Always
注意: 这是一台默认禁用所有端口的机器,所以我问我们的 IT 管理员已经根据下一个文档 check-required-ports 打开了端口,我不是确定这是否重要。
然后使用next我可以获得coredns的pod ip。
kubectl get pods -n kube-system -o wide | grep core
coredns-7877db9d45-swb6c 1/1 Running 0 2m58s 10.244.1.8 node2 <none> <none>
coredns-7877db9d45-zwc8v 1/1 Running 0 2m57s 10.244.0.6 node1 <none> <none>
这里,10.244.0.6
是我的主节点,10.244.1.8
是我的工作节点
那如果我直接指定coredns pod ip:
主节点ok:
kubectl exec -i -t dnsutils -- nslookup kubernetes.default 10.244.0.6
Server: 10.244.0.6
Address: 10.244.0.6#53
Name: kubernetes.default.svc.cluster.local
Address: 10.96.0.1
工作节点不正常:
# kubectl exec -i -t dnsutils -- nslookup kubernetes.default 10.244.1.8
;; connection timed out; no servers could be reached
command terminated with exit code 1
那么,问题缩小到为什么工作节点上的 COREDNS 不起作用?有什么需要注意的吗?
环境:
- OS: ubuntu18.04
- K8S: v1.21.0
- 集群启动命令:
kubeadm init --pod-network-cidr=10.244.0.0/16
kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml
终于找到了根本原因,这是硬件防火墙问题,参见this:
Firewalls
When using udp backend, flannel uses UDP port 8285 for sending encapsulated packets.
When using vxlan backend, kernel uses UDP port 8472 for sending encapsulated packets.
Make sure that your firewall rules allow this traffic for all hosts participating in the overlay network.
Make sure that your firewall rules allow traffic from pod network cidr visit your kubernetes master node.
- 当
nslookup client
在dns server
的同一个节点时,不会触发防火墙阻塞,所以一切正常。
- 当
nslookup client
与dns server
不在同一节点时,会触发防火墙封锁,无法访问dns服务器。
所以,打开端口后,现在一切正常。
我使用下一个命令检查我的 k8s 中的 dns 问题:
kubectl apply -f https://k8s.io/examples/admin/dns/dnsutils.yaml
kubectl exec -i -t dnsutils -- nslookup kubernetes.default
nslookup 结果是:
;; connection timed out; no servers could be reached
command terminated with exit code 1
dnsutils.yaml:
apiVersion: v1
kind: Pod
metadata:
name: dnsutils
namespace: default
spec:
containers:
- name: dnsutils
image: gcr.io/kubernetes-e2e-test-images/dnsutils:1.3
command:
- sleep
- "3600"
imagePullPolicy: IfNotPresent
restartPolicy: Always
注意: 这是一台默认禁用所有端口的机器,所以我问我们的 IT 管理员已经根据下一个文档 check-required-ports 打开了端口,我不是确定这是否重要。
然后使用next我可以获得coredns的pod ip。
kubectl get pods -n kube-system -o wide | grep core
coredns-7877db9d45-swb6c 1/1 Running 0 2m58s 10.244.1.8 node2 <none> <none>
coredns-7877db9d45-zwc8v 1/1 Running 0 2m57s 10.244.0.6 node1 <none> <none>
这里,10.244.0.6
是我的主节点,10.244.1.8
是我的工作节点
那如果我直接指定coredns pod ip:
主节点ok:
kubectl exec -i -t dnsutils -- nslookup kubernetes.default 10.244.0.6
Server: 10.244.0.6
Address: 10.244.0.6#53
Name: kubernetes.default.svc.cluster.local
Address: 10.96.0.1
工作节点不正常:
# kubectl exec -i -t dnsutils -- nslookup kubernetes.default 10.244.1.8
;; connection timed out; no servers could be reached
command terminated with exit code 1
那么,问题缩小到为什么工作节点上的 COREDNS 不起作用?有什么需要注意的吗?
环境:
- OS: ubuntu18.04
- K8S: v1.21.0
- 集群启动命令:
kubeadm init --pod-network-cidr=10.244.0.0/16
kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml
终于找到了根本原因,这是硬件防火墙问题,参见this:
Firewalls
When using udp backend, flannel uses UDP port 8285 for sending encapsulated packets.
When using vxlan backend, kernel uses UDP port 8472 for sending encapsulated packets.
Make sure that your firewall rules allow this traffic for all hosts participating in the overlay network.
Make sure that your firewall rules allow traffic from pod network cidr visit your kubernetes master node.
- 当
nslookup client
在dns server
的同一个节点时,不会触发防火墙阻塞,所以一切正常。 - 当
nslookup client
与dns server
不在同一节点时,会触发防火墙封锁,无法访问dns服务器。
所以,打开端口后,现在一切正常。