Kubernetes CoreDNS 无法解析外网域名的问题

2024-09-04 19:28
文章标签 问题 kubernetes 无法 解析 域名 coredns

本文主要是介绍Kubernetes CoreDNS 无法解析外网域名的问题，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

k8s master机器环境
  • 宿主机resolv.conf
# cat /etc/resolv.conf
nameserver 172.16.100.1
  • pod中的resolv.conf文件如下
$ cat /etc/resolv.conf    
# Generated by NetworkManager
nameserver 10.96.0.10        # 此ip为coredns的IP地址
排查过程

当pod需要解析一个域名时，如果域名是k8s集群内部的pod，那么coredns就会返回ip信息，至此解析结束，那如果是公网的域名呢？

比如说是www.baidu.com，那么此时coredns根据它自己的配置是无法解析的，怎么办呢？在coredns容器启动时，它会将宿主机的/etc/resolv.conf文件挂载到自己内部使用，也就是说coredns的/etc/resolv.conf文件和宿主机的是一致的，然后通过此文件指定的nameserver进行解析外网域名。

# kubectl get pod -n kube-system     # 获取到coredns-name
# kubectl edit coredns-name -n kube-system   # 查看coredns的yaml文件内容

我在coredns的yml文件中，看到了它的volumes挂载了一个名为coredns的configmap，然后使用下面的指令去查看了下这个configmap，如下：

[root@k8s-master-001 sysctl.d]# kubectl describe configmap/coredns -n kube-system
Name:         coredns  
Namespace:    kube-system  
Labels:       <none>  
Annotations:  <none>Data  
====
Corefile:  
----
.:53 {errorshealth {lameduck 5s}readykubernetes cluster.local in-addr.arpa ip6.arpa {pods insecurefallthrough in-addr.arpa ip6.arpattl 30}prometheus :9153forward . /etc/resolv.conf {max_concurrent 1000}cache 30loopreloadloadbalance
}

关于上面configmap的解释如下：

  • errors: 输出错误信息到控制台。
  • health：CoreDNS 进行监控检测，检测地址为 http://localhost:8080/health 如果状态为不健康则让 Pod 进行重启。
  • ready: 全部插件已经加载完成时，将通过 endpoints 在 8081 端口返回 HTTP 状态 200。
  • kubernetes：CoreDNS 将根据 Kubernetes 服务和 pod 的 IP 回复 DNS 查询。
  • prometheus：是否开启 CoreDNS Metrics 信息接口，如果配置则开启，接口地址为 http://localhost:9153/metrics
  • forward：任何不在Kubernetes 集群内的域名查询将被转发到预定义的解析器 (/etc/resolv.conf)。
  • cache：启用缓存，30 秒 TTL。
  • loop：检测简单的转发循环，如果找到循环则停止 CoreDNS 进程。
  • reload：监听 CoreDNS 配置，如果配置发生变化则重新加载配置。
  • loadbalance：DNS 负载均衡器，默认 round_robin。

好，我的注意点落在了loadbalance这个配置上，然后在宿主机上，使用dig指令，/etc/resolv.conf文件中的三个nameserver分别解析我们的公网域名。发现后面两个nameserver是无法解析我们的公网域名的，然后啥也不说了，把宿主机上的/etc/resolv.conf文件中指定的两个内网dns服务器干掉，就剩下一个114.114.114.114，然后删除coredns这个pod的（然后它会自动重启新的pod，相当于重启coredns了），再次进入应用pod中多次解析验证，问题解决，ok。

问题总结

宿主机本地的/etc/resolv.conf文件中有两个nameserver是指定的内网的dns，这两个dns解析不到公网域名，coredns又是以轮询的方式去找那几个nameserver的，解析记录的缓存是30s（也就是说，如果你解析到了，那么未来30s的解析都是成功的），30s后再解析，解析请求就会落到那两个内网dns服务器上，所以就出现了我这种情况

-------------------------------------------------------------------------------------------------------------------------------- 

经过上面的 ping 测试和 nslookup 测试，分析发现 k8s 集群内部 pod 解析外部域名，先走 coredns 内部域名解析，再走局域网 dns 解析。而无法解析的时候问题原因是：coredns 解析就返回报错了，定位问题为 coredns 解析外部域名存在问题。

网上查看问题，发现可能是 coredns 解析问题导致

  • 查看 coredns 的配置文件如下
apiVersion: v1
data:Corefile: |.:53 {errorshealth {lameduck 5s}readykubernetes cluster.local in-addr.arpa ip6.arpa {pods insecurefallthrough in-addr.arpa ip6.arpa}prometheus :9153forward . /etc/resolv.conf cache 30reloadloadbalance}
kind: ConfigMap
metadata:name: corednsnamespace: kube-system
其中 forward . /etc/resolv.conf 配置表示使用当coredns内部不能解析的时候，向宿主机上的resolv.conf文件中配置的nameserver转发dns解析请求，当宿主机上namserver有多个时，默认采用的时random的方式随机转发，失败后就返回错误。
  • 宿主机 /etc/resolv.conf
$ cat /etc/resolv.conf# Generated by NetworkManager
nameserver 172.16.0.50
nameserver 114.114.114.114
  • 将其 forward 的 policy 设置为 sequential
        forward . /etc/resolv.conf {max_concurrent 1000   # 新增配置policy sequential     # 新增配置}

解决方案

  • 编辑 coredns 配置文件，修改配置，并重启 POD
$ kubectl -n kube-system edit cm corednsapiVersion: v1
data:Corefile: |.:53 {errorshealth {lameduck 5s}readykubernetes cluster.local in-addr.arpa ip6.arpa {pods insecurefallthrough in-addr.arpa ip6.arpa}prometheus :9153forward . /etc/resolv.conf {max_concurrent 1000   # 新增配置policy sequential     # 新增配置}cache 30reloadloadbalance}
kind: ConfigMap
metadata:name: corednsnamespace: kube-system$ kubectl -n kube-system delete pods coredns-xxxxxx

----------------------------------------------------------------------------------------------------------------------

自己排查如下：

[root@k8s-pre-m01 ~]# kubectl logs coredns-7f8ff9c97-6tlln  -n kube-system -f
.:53
[INFO] plugin/reload: Running configuration SHA512 = 676a3d7c6fa16eff8b618d85b13f15775f15fabfbb23dbec6f9beecc102ad51e0663f9f30fd8b93736d0e9564d8e452bd51d530094547764b7e5fab04763519d
CoreDNS-1.9.3
linux/amd64, go1.18.2, 45b0a11
[ERROR] plugin/errors: 2 jmenv.tbsite.net. AAAA: read udp 10.196.129.208:42449->10.196.17.210:53: i/o timeout
failed to create fsnotify watcher: too many open files[root@k8s-pre-m01 ~]# kubectl logs coredns-7f8ff9c97-wqmw8     -n kube-system -f
.:53
[INFO] plugin/reload: Running configuration SHA512 = 676a3d7c6fa16eff8b618d85b13f15775f15fabfbb23dbec6f9beecc102ad51e0663f9f30fd8b93736d0e9564d8e452bd51d530094547764b7e5fab04763519d
CoreDNS-1.9.3
linux/amd64, go1.18.2, 45b0a11master节点和node节点对dns的访问权限是不一样的，master和node在不同网段，对10.196.17.210访问结果不一样，如果coredns调度在master上面，那么coredns就报错，如果是node节点正常。[root@k8s-pre-m01 ~]# cat /etc/resolv.conf 
# Generated by NetworkManager
nameserver 10.196.17.210[root@k8s-pre-n02 ~]# cat /etc/resolv.conf 
# Generated by NetworkManager
nameserver 10.196.17.210

这篇关于Kubernetes CoreDNS 无法解析外网域名的问题的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！


http://www.chinasem.cn/article/1136815。

相关文章

网页解析 lxml 库--实战

网页解析 lxml 库--实战

lxml库使用流程 lxml 是 Python 的第三方解析库，完全使用 Python 语言编写，它对 XPath表达式提供了良好的支 持，因此能够了高效地解析 HTML/XML 文档。本节讲解如何通过 lxml 库解析 HTML 文档。 pip install lxml lxm| 库提供了一个 etree 模块，该模块专门用来解析 HTML/XML 文档，下面来介绍一下 lxml 库
阅读更多...
好题——hdu2522（小数问题：求1/n的第一个循环节）

好题——hdu2522（小数问题：求1/n的第一个循环节）

好喜欢这题，第一次做小数问题，一开始真心没思路，然后参考了网上的一些资料。 知识点***********************************无限不循环小数即无理数，不能写作两整数之比*****************************（一开始没想到，小学没学好） 此题1/n肯定是一个有限循环小数，了解这些后就能做此题了。 按照除法的机制，用一个函数表示出来就可以了，代码如下
阅读更多...
hdu1043（八数码问题，广搜 + hash（实现状态压缩） ）

hdu1043（八数码问题，广搜 + hash（实现状态压缩） ）

利用康拓展开将一个排列映射成一个自然数，然后就变成了普通的广搜题。 #include<iostream>#include<algorithm>#include<string>#include<stack>#include<queue>#include<map>#include<stdio.h>#include<stdlib.h>#include<ctype.h>#inclu
阅读更多...
三国地理揭秘：为何北伐之路如此艰难，为何诸葛亮无法攻克陇右小城？

三国地理揭秘：为何北伐之路如此艰难，为何诸葛亮无法攻克陇右小城？

俗话说:天时不如地利，不是随便说说，诸葛亮六出祁山，连关中陇右的几座小城都攻不下来，行军山高路险，无法携带和建造攻城器械，是最难的，所以在汉中，无论从哪一方进攻，防守方都是一夫当关，万夫莫开；再加上千里运粮，根本不需要打，司马懿只需要坚守城池拼消耗就能不战而屈人之兵。 另一边，洛阳的虎牢关，一旦突破，洛阳就无险可守，这样的进军路线，才是顺势而为的用兵之道。 读历史的时候我们常常看到某一方势
阅读更多...
【C++】_list常用方法解析及模拟实现

【C++】_list常用方法解析及模拟实现

相信自己的力量，只要对自己始终保持信心，尽自己最大努力去完成任何事，就算事情最终结果是失败了，努力了也不留遗憾。💓💓💓 目录   ✨说在前面 🍋知识点一：什么是list？ •🌰1.list的定义 •🌰2.list的基本特性 •🌰3.常用接口介绍 🍋知识点二：list常用接口 •🌰1.默认成员函数 🔥构造函数（⭐） 🔥析构函数 •🌰2.list对象
阅读更多...
购买磨轮平衡机时应该注意什么问题和技巧

购买磨轮平衡机时应该注意什么问题和技巧

在购买磨轮平衡机时，您应该注意以下几个关键点： 平衡精度 平衡精度是衡量平衡机性能的核心指标，直接影响到不平衡量的检测与校准的准确性，从而决定磨轮的振动和噪声水平。高精度的平衡机能显著减少振动和噪声，提高磨削加工的精度。 转速范围 宽广的转速范围意味着平衡机能够处理更多种类的磨轮，适应不同的工作条件和规格要求。 振动监测能力 振动监测能力是评估平衡机性能的重要因素。通过传感器实时监
阅读更多...
缓存雪崩问题

缓存雪崩问题

缓存雪崩是缓存中大量key失效后当高并发到来时导致大量请求到数据库，瞬间耗尽数据库资源，导致数据库无法使用。 解决方案： 1、使用锁进行控制 2、对同一类型信息的key设置不同的过期时间 3、缓存预热 1. 什么是缓存雪崩 缓存雪崩是指在短时间内，大量缓存数据同时失效，导致所有请求直接涌向数据库，瞬间增加数据库的负载压力，可能导致数据库性能下降甚至崩溃。这种情况往往发生在缓存中大量 k
阅读更多...
Kubernetes PodSecurityPolicy：PSP能实现的5种主要安全策略

Kubernetes PodSecurityPolicy：PSP能实现的5种主要安全策略

Kubernetes PodSecurityPolicy：PSP能实现的5种主要安全策略 1. 特权模式限制2. 宿主机资源隔离3. 用户和组管理4. 权限提升控制5. SELinux配置 💖The Begin💖点点关注，收藏不迷路💖 Kubernetes的PodSecurityPolicy（PSP）是一个关键的安全特性，它在Pod创建之前实施安全策略，确保P
阅读更多...
6.1.数据结构-c/c++堆详解下篇（堆排序，TopK问题）

6.1.数据结构-c/c++堆详解下篇（堆排序，TopK问题）

上篇：6.1.数据结构-c/c++模拟实现堆上篇（向下，上调整算法，建堆，增删数据）-CSDN博客 本章重点 1.使用堆来完成堆排序 2.使用堆解决TopK问题 目录 一.堆排序 1.1 思路 1.2 代码 1.3 简单测试 二.TopK问题 2.1 思路(求最小)： 2.2 C语言代码（手写堆） 2.3 C++代码（使用优先级队列 priority_queue）
阅读更多...
K8S（Kubernetes）开源的容器编排平台安装步骤详解

K8S（Kubernetes）开源的容器编排平台安装步骤详解

K8S（Kubernetes）是一个开源的容器编排平台，用于自动化部署、扩展和管理容器化应用程序。以下是K8S容器编排平台的安装步骤、使用方式及特点的概述： 安装步骤： 安装Docker：K8S需要基于Docker来运行容器化应用程序。首先要在所有节点上安装Docker引擎。 安装Kubernetes Master：在集群中选择一台主机作为Master节点，安装K8S的控制平面组件，如AP
阅读更多...

Copyright China编程 23002807@qq.com

沪ICP备2023033072号-2