[转帖]CoreDNS loop 插件异常问题
- https://zhuanlan.zhihu.com/p/476611162
背景
最近有遇到一个客户集群,发现集群中的 CoreDNS 老是异常 (loop 插件检测到有回路后进行 panic),因此怀疑是 K8S 集群在交付或者初始化过程中做了一些额外的动作,为了查明真相我们对客户环境进行一次排查和状况模拟,顺便来一起学习一下在 CoreDNS 中 loop 插件的相关知识。
问题现象
在查看 coredns pod 启动日志时,发现有如下对应异常:
$ kubectl get pods -n kube-system | grep dns
coredns-bdbc5564-8qldp 0/1 CrashLoopBackOff 8 22m
$ kubectl logs -n kube-system coredns-bdbc5564-8qldp
[INFO] plugin/kubernetes: Watching Endpoints instead of EndpointSlices in k8s versions < 1.19
.:53
[INFO] plugin/reload: Running configuration MD5 = 045400f7bc8c9f6aaf8ca5dade224266
CoreDNS-1.8.4
linux/amd64, go1.16.4, 053c4d5
[INFO] 127.0.0.1:34652 - 36041 "HINFO IN 2066162189351134310.8810881223121065474. udp 57 false 512" NOERROR - 0 6.002536937s
[ERROR] plugin/errors: 2 2066162189351134310.8810881223121065474. HINFO: read udp 127.0.0.1:48503->127.0.0.53:53: i/o timeout
[FATAL] plugin/loop: Loop (127.0.0.1:48066 -> :53) detected for zone ".", see https://coredns.io/plugins/loop#troubleshooting. Query: "HINFO 2066162189351134310.8810881223121065474."
看到该异常时,第一时间想到的是 客户应该在集群中做了一些 dns 的自定义配置 (因为我们交付模版中并没有为 CoreDNS 开启 loop 插件),而配置后又触发了一些冲突,进而导致服务异常。
虽然基本已经确定了是客户自行修改的配置导致的异常,但为何或者具体如何出现的该问题呢?我们继续往下看。
问题排查和处理
其实对于 CoreDNS 这种开源界比较优秀的软件,对异常的处理以及修复都已经做的特别好了,比如上述的日志中已经明显提示,对于这种错误如何进行 troubleshooting 了。
我们跟随官方文档,其实就可以知道,对于相关问题已经说的比较明白,我在这里总结以下几点:
1. loop 插件的作用:
- 该插件会检测简单转发环路,并且当发现回路时会使服务器
停止
2. 回路的影响:
- 当 CoreDNS 转发中存在环路时,会不断向自己转发,如此形成死循环,会导致资源无穷占用,最终导致主机 OOM
3. 为何会导致回路:
- CoreDNS 直接将请求转发给自己,比如通过 127.0.0.1, ::1, 或者 127.0.0.53
- CoreDNS 将请求转发到上游服务器,后者再将请求转发回 CoreDNS
4. loop 插件生效的条件:
- 回路必须在 coredns 启动时出现
- 回路必须出现在一个
HINFO
类型的查询
如上四个点,看完之后,基本上就知道为何 coredns 启动失败了,此时查看了 coredns 的配置项并无异常,核心配置如下:
# coredns 中的核心配置,可以看到是开启了loop 配置的
.:53 {
errors
health {
lameduck 5s
}
ready
kubernetes cluster.local in-addr.arpa ip6.arpa {
fallthrough in-addr.arpa ip6.arpa
}
log . {
class all
}
prometheus :9153
forward . /etc/resolv.conf {
max_concurrent 1000
}
cache 30
loop
reload
loadbalance
}
如上配置可以看到,CoreDNS 的确开启了 loop 插件,并且没有显式声明会讲请求转发到 127.0.0.1
或者 127.0.0.53
之类的本地地址。
但是我们也观察到会将请求转发到 /etc/resolv.conf
,而一般情况下,在 K8S 集群中的 workload 的 dnsPolicy
通常为 Default
,也就是当 CoreDNS pod 调度到哪个节点,将会转发到节点的 /etc/resolv.conf
配置中,因此接下来可以去查看节点的配置。
# 查看coredns 被调度到的节点上的resolv.conf 配置
# cat /etc/resolv.conf | grep -v ^#
nameserver 127.0.0.53
options edns0
nameserver 183.60.83.19
nameserver 183.60.82.98
此时,对于上面 coredns 异常的原因就已经大概清楚了,就是节点上的 /etc/resolv.conf
配置了 127.0.0.53
。
按照 loop
插件的说法,就是启动了 loop
模块,并成功检测到了回路,那此时,把回路清理掉,应该就可以恢复正常,我们可以尝试把对应节点上的 nameserver 127.0.0.53
删除掉。
# 此时修改节点的的配置后删除pod发现可以重新启动了
$ kubectl delete pods -n kube-system coredns-bdbc5564-8qldp
pod "coredns-bdbc5564-8qldp" deleted
$ kubectl get pods -n kube-system | grep dns
coredns-bdbc5564-j6nwl 1/1 Running 0 100s
根因和解决方案
目前,客户的问题已经解决,但是客户反馈自己没有修改过节点上的配置,并且依然认为是 K8S 集群交付和初始化方做了动作,希望能够找到节点上的 127.0.0.53
是如何来的。
作为平台方,在新增节点或者交付集群时,的确会进行初始化节点,但对于在 /etc/resolv.conf
中增加 127.0.0.53
是肯定不会做的。
最终通过不断查询相关资料,发现客户用的是 Ubuntu
的操作系统,而在 Ubuntu
的操作系统中,默认会使用到 systemd-resolved
进行管理 dns server,并且会设置一个 127.0.0.53
的地址用于本地 dns 缓存。
经过测试的确是发现 Ubuntu
的操作系统会增加该 name Server ,到这里也就基本上清楚了,节点上的 127.0.0.53
记录的来源。
那看到这里要如何解决呢?
根据该问题,个人认为会有如下方案可供选择:
1. CoreDNS 关闭 loop
插件,这也是最粗暴直接的
2. 继续开启 loop
插件,但是尝试对 HINFO
类型的请求做干预
3. 手动修改节点上的 /etc/resolv.conf
配置,确保没有 nameserver 127.0.0.53
4. 修改 coredns 的亲和性和凡亲和性策略,仅调度到非 Ubuntu 节点
对于如上四种方案,前两者选择对 CoreDNS 的配置进行直接干预,来整体影响 CoreDNS 的功能。
而后两种方案则是通过人工干预集群节点和默认的调度行为。
但是,对于 K8S 集群而言,如果不设置特殊的规则 (比如 label,affinity,nodeSelector) 去影响默认的调度策略,默认是无法根据 OS 信息去影响调度的,并且对于开放的 k8s 集群,也不应该禁止用户使用 Ubuntu 操作系统。
那为了最小化的改动并且能够最大限度支撑现有需求,我们可以选择方案 2 进行问题的兜底。
我们可以使用如下配置来对 HINFO
的请求,强制返回 NXDOMAIN
,如此一来也就不回直接产生 HINFO
的异常请求
$ kubectl edit -n kube-system cm coredns
....
.:53 {
template ANY HINFO . {
rcode NXDOMAIN
}
}
....
....
# 对 HINFO 类型查询做了干预后,可以查看具体的请求
$ dig +short @172.16.0.80 kubernetes.default.svc
$ dig +short @172.16.0.80 kubernetes.default.svc HINFO
# 对应coredns pod 的查询日志如下:
2022-03-05T06:08:39.299Z [INFO] 10.0.1.80:45430 - 60055 'A IN kubernetes.default.svc. udp 63 false 4096' NXDOMAIN qr,aa,rd,ra 115 0.000093025s
2022-03-05T06:09:03.685Z [INFO] 10.0.1.80:35006 - 61274 'HINFO IN kubernetes.default.svc. udp 63 false 4096' NXDOMAIN qr,aa,rd 40 0.000109837s
总结
至此,我们也算是找到了问题的根因,并且给出了比较合适的解决方案。
同时,也学习到了 CoreDNS 这种比较优秀的开源软件的设计,针对于一些风险检测的规避和和默认行为,能够忍我们更早的发现系统的风险和问题。
[转帖]CoreDNS loop 插件异常问题的更多相关文章
- JMeter中添加dubbo相关插件异常问题解决
从网上下载了一个dubbo的插件,然后放到JMeter的/lib/ext目录下: 然后启动直接异常 发现启动不了,然后下载了一个全新的JMeter3.2将dubbo插件放到同样的目录,启动,没有问题: ...
- 工作采坑札记:3. Spark中es-hadoop插件异常解决
1. Es-Hadoop异常: org.elasticsearch.hadoop.EsHadoopException: Could not write all entries [615/300864] ...
- Ecplise-SVN插件异常: 由于目标计算机积极拒绝,无法连接。
在Ecplise中,选择team->share project时,出现以下异常 由于目标计算机积极拒绝,无法连接. svn: Unable to connect to a repository ...
- [转帖] 安装Eclipse插件长时间卡在 calculating requirements and dependencies
把"Contact all update sites during install to find required software"前面的勾去掉,然后点击下一步,这样之后问题迎 ...
- 使用 CoreDNS 来应对 DNS 污染
原文链接:https://fuckcloudnative.io/posts/install-coredns-on-macos/ CoreDNS 是 Golang 编写的一个插件式 DNS 服务器,是 ...
- Xcode插件筛选
Xcode高效插件推荐 好像很多iOS开发的同学都不知道Xcode有插件这么一说,所以整理了一下自己用的Xcode高效插件,分享给大家 下列插件在Xcode 7.0.1 版本做测试通过可以使用 在Xc ...
- PL/SQL 编程(一)基础,变量,分支,循环,异常
SQL和PL/SQL: SQL 结构化查询语言(Structural Query Language),是用来访问和操作关系型数据库的一种标准通用语言,属于第四代语言(4GL).可以方便的调用相应语句来 ...
- CoreDNS配置kubernetes作为后端
概述 coredns之所以如此名声大噪,就是因为从kubernetes1.9开始引入,作为kubernetes内部服务发现的默认dns.毫无疑问kubernetes是coredns的后端之一,所以我们 ...
- Istio多集群(1)-多控制面
Istio多集群(1)-多控制面 参考自官方文档. 目录 Istio多集群(1)-多控制面 复制控制面 要求 在每个集群中部署Istio控制面 配置DNS 配置应用服务 配置用例服务 卸载 FAQ 复 ...
- Ubuntu1804下k8s-CoreDNS占CPU高问题排查
1.背景: 最近在ubuntu804上适配k8s的时候,部署到业务pod的时候,出现了服务器卡死,top查看发现负载很高,进行CPU排序发现如下信息,可知是CoreDNS服务导致. 2. 分析排查: ...
随机推荐
- PHP中的反序列化漏洞理解
序列化serialize() 序列化说通俗点就是把一个对象变成可以传输的字符串,比如下面是一个对象: class S{ public $test="pikachu"; } $s=n ...
- k8s主要概念大梳理!
k8s已经成为了绝对热门的技术,一个上点规模的公司,如果不搞k8s,都不好意思出去见人.安装k8s要突破种种网络阻碍,但更大的阻碍还在后面... 我发现,很多k8s的文章,根本不说人话,包括那要命的官 ...
- .NET技术分享日活动-202104
2021年4月27日下午,个人组织举办了山东地区的山东.NET技术分享日活动.围绕互联网技术.大数据.机器学习.业务实践等方向进行创新技术的实践分享. 本次技术分享日活动面向了山东地区广大的.NET ...
- 昇腾实践丨ATC模型转换动态shape问题案例
本文分享自华为云社区<ATC模型转换动态shape问题案例>,作者:昇腾CANN. ATC(Ascend Tensor Compiler)是异构计算架构CANN体系下的模型转换工具:它可以 ...
- 能够让机器狗学会灭火, ModelArts3.0让AI离我们又近一步
摘要:训练.标注成本节省90%!华为云自动化AI开发平台ModelArts 3.0发布,从训练数据到模型落地一站式打通. 今年的华为,着实遭遇了不小的困难. 尤其是供应链,包括芯片方面的打击,让华为轮 ...
- 【一行代码秒上云】Serverless六步构建全栈网站
摘要:Serverless怎么玩?听一千道一万不如亲手来实践,跟着我们以华为云Serverless实践FunctionGraph来免费体验一下六步构建全栈网站吧 前言: Serverless怎么玩?听 ...
- 如何应对Spark-Redis行海量数据插入、查询作业时碰到的问题
摘要:由于redis是基于内存的数据库,稳定性并不是很高,尤其是standalone模式下的redis.于是工作中在使用Spark-Redis时也会碰到很多问题,尤其是执行海量数据插入与查询的场景中. ...
- 统一元数据,数据湖Catalog让大数据存算分离不再是问题
摘要:为了解决现阶段大数据存算分离痛点问题,华为云大数据推出重量级数据湖Catalog服务. 1 背景 随着5G.IoT等技术的发展,企业积累了越来越多的数据,需要激发更多的数据价值变现.传统大数据平 ...
- Linux IPTables:如何添加防火墙规则
摘要:本文介绍了如何使用"iptables -A"命令添加 iptables 防火墙规则. 本文分享自华为云社区<Linux IPTables:如何添加防火墙规则(使用允许 ...
- 提升源代码安全性的C#和Java深度混淆工具——IpaGuard
提升源代码安全性的C#和Java深度混淆工具--IpaGuard 摘要 Ipa Guard是一款功能强大的IPA混淆工具,通过对iOS IPA文件进行混淆加密,保护其代码.资源和配置文件,降低破解反编 ...