Kubernetes 1.26.7集群DNS查询结果波动问题排查求助

1. 定位故障节点与CoreDNS的关联 #

先找出ping不通的CoreDNS pod（IP 192.168.253.21）运行的节点：

kubectl get pods -n kube-system -o wide | grep coredns

该pod对应的NODE列就是你提到的“特定节点”——它的网络问题是DNS波动的核心：当请求转发到这个节点的CoreDNS时会超时，转发到健康节点则正常。

2. 检查故障节点的CNI插件状态 #

kubeadm默认用flannel或calico作为CNI，先确认你使用的插件：

kubectl get pods -n kube-system | grep -E "flannel|calico"

以flannel为例，查看故障节点上的flannel pod日志：

kubectl logs -n kube-system <故障节点的flannel-pod-name>

重点排查是否有failed to create vxlan interface或subnet not allocated这类错误。同时在故障节点检查网络设备：

ip link show cni0
ip link show flannel.1

如果cni0或flannel.1不存在，直接删除flannel pod让它重建：

kubectl delete pod -n kube-system <故障节点的flannel-pod-name>

3. 排查节点间基础连通性 #

• 先ping故障节点与其他节点的主机IP，如果不通，先解决物理网络问题：检查防火墙是否开放CNI所需端口（flannel用8472，calico用4789）、节点是否在同一VLAN、路由表配置是否正常。
• 如果主机IP互通，用telnet测试VXLAN端口：

telnet <健康节点IP> 8472 # flannel场景

或在故障节点抓包查看是否能收到健康节点的VXLAN流量：

tcpdump -i flannel.1 -nn

4. 确认CoreDNS重启原因 #

查看CoreDNS重启前的日志，验证是否为网络问题导致健康检查失败：

kubectl logs -n kube-system <有重启记录的coredns-pod-name> --previous

如果日志中有大量timeout或connection refused，则直接印证网络不通是CoreDNS重启的诱因。

5. 临时规避：让CoreDNS仅调度到健康节点 #

如果暂时无法修复故障节点网络，先给它打污点禁止Pod调度：

kubectl taint nodes <故障节点名称> node-role.kubernetes.io/unschedulable=true

然后删除现有CoreDNS pod，让它们重新调度到健康节点：

kubectl delete pods -n kube-system -l k8s-app=kube-dns

这样DNS请求不会再落到故障节点的CoreDNS上，波动问题可先得到解决。

6. 检查containerd与kubelet的网络配置 #

• 检查containerd的CNI配置是否正确：

cat /etc/containerd/config.toml | grep -A 10 cni

确保conf_dir指向/etc/cni/net.d，且该目录下存在CNI配置文件（如10-flannel.conflist）。

• 检查故障节点的kubelet配置：

cat /var/lib/kubelet/config.yaml | grep network-plugin

确认配置为networkPlugin: cni，同时查看kubelet日志是否有CNI初始化错误：

journalctl -u kubelet -f

内容的提问来源于stack exchange，提问作者zozo6015