一、演练目的

为了更好保障线上业务服务的稳定性与可用性，本次尝试注入一次coredns故障，来模拟演练当线上故障后对业务服务的影响范围，及验证应急方案执行有效性，通过演练能够帮助croedns提升容错性和可恢复性。

二、演练方案

2.1 演练方案一：模拟现实节点拓机方案

NodeLocalDNS结合CoreDNS使用后，架构图如下：

演练会将CoreDNS pod所在其中一台节点模拟异常拓机，以观察对业务的影响。

当CoreDNS所在节点异常拓机时，预期的效果如下：

• k8s 集群内部的Service解析会有1/5（coredns有5个pod）的流量在30s内受到影响
• Node Local DNS上线（2022.09.14 04:30）后新启动的POD内网域名解析将不再受到影响，上线前的POD因dns配置还是coredns，内网域名解析还是会受到影响，影响面同上

风险点：

因Node Local DNS上线（2022.09.14 04:30）上线前的POD因dns配置还是coredns，内网域名解析还是会受到影响，需要对这块做相应的处理：

• 拉出清单，演练前请各个应用的负责人重启应用，以生成新的POD
• 或接受风险，观察当前状态对业务的影响

2.2 演练方案二：单节点小范围模拟拓机方案

与上一个演练方案不同，我们不再让CoreDNS POD所在的节点模拟异常拓机，而是：

1. 找一台节点，将使用coredns的POD全部驱逐，只保留使用了本地节点DNS缓存的POD
2. 通过腾讯云安全组策略，将这台节点到coredns其中一个POD的网络中断
3. 观察这台节点上的POD的服务是否正常，域名解析是否正常
4. 删除以上加的安全组策略，恢复网络正常

此方案是因当前线上有很多还在使用coreDNS的POD的现状而提出来的，可以验证NodeLocalDNS+CoreDNS方案的实际效果

三、演练过程

3.1 演练步骤

演练方案一：

演练方案二：

3.2 验证方法

• 在演练过程里查看监控和日志观察请求到注入的异常的解析是否有问题；
• 针对以下几种不同语言报错提示关键字，在应用日志里全局搜索如果，不再有对应错误日志哪就可以判定为是有效且正常状态；

类型	报错关键字	日志查询参考图
Java	UnknownHostException “Unable to resolve”
Nodejs	getaddrinfo  ENOTFOUND

四、演练总结

五、附件

5.1线上当前POD还在使用CoreDNS配置的应用清单：

当前线上所有应用pod的resolv文件里DNS IP，计算对比占线上全量应用的百分比；

POD全量数	环境	类型	DNS-IP	应用数量	应用详情列表
12901	OL	CoreDNS	10.23.252.2	3317	OL环境应用pod对应nameserver列表
Local-DNS	169.254.20.10	9556

POD全量数	环境	类型	DNS-IP	应用数量	应用详情列表
3775	QA	CoreDNS	10.252.252.2	2637	QA环境应用pod对应nameserver列表
Local-DNS	169.254.20.10	1138

5.2 参考文档

5.3 引入NodeLocalDNS后K8S集群DNS解析流程与业务连续性测试