我们在AWS EKS上部署了一个kubernetes集群，并且在CoreDNS pod上遇到了间歇性超时，通常在5分钟左右的时间内以5-15个失败查询为一组进行集群。在集群中，所有查询都使用相同的主机名。
CoreDNS吐出这样的日志：
[ERROR] plugin/errors: 2 example.com. A: read udp [coreDNSpodIP]:39068->172.16.0.2:53: i/o timeout集群部署在CIDR为172.16.0.0/16的VPC中，无法判断172.15.0.2下是什么
它们不时出现，我们无法重现触发它们的事件，也无法与集群上的任何事件相关联。coreDNS pods工作正常，同时也很好地服务于其他查询。可能是什么原因和解决方案来修复该行为？
2条答案
按热度按时间hujrc8aj1#
您可能会达到一个限制，超过该限制后，所有请求都将被限制。
我想到两件事
disho6za2#
对于CoreDNS，弹性网卡级别有一个硬限制，即1024包/秒（PPS）。
现在让我们假设正在进行的DNS查询突然涌入，并且PPS接近1024的硬限制。我们将开始看到DNS节流，并且我们将不知道问题的根本原因，因为自然的故障排除直觉是关注CoreDNS pod而不是ENI指标。此弹性网卡级别硬限制会影响在该特定工作节点上运行的所有微服务，因此必须不断监控此指标以避免中断。在这篇博客文章中，我们将向您介绍一个解决方案，该解决方案将帮助监控可能在弹性网卡级别发生的丢包，以确定是否存在DNS节流问题。
相关问题：
i/o timeout登录CoreDNS解决方案：
监测：
ethtool使用linklocal_allowance_exceeded度量对DNS节流进行故障排除，有关详细信息，请参阅Monitoring CoreDNS for DNS throttling issues using AWS Open source monitoring services来源：