CoreDNS在Kubernetes中DNS缓存问题的深度解析

问题背景

在Kubernetes集群中使用Redis Sentinel时，当Pod被缩容后，应用程序仍然尝试连接已不存在的Pod IP地址。虽然EndpointSlice会立即移除该IP，但DNS解析结果却存在延迟更新现象。这会导致服务中断时间远超预期，特别是在使用Headless Service时更为明显。

技术细节分析

DNS TTL机制

TTL（Time To Live）是DNS记录的重要属性，它决定了客户端可以缓存DNS结果的时间。在Kubernetes环境中：

1. 默认情况下，CoreDNS为Kubernetes服务记录设置的TTL值为5秒
2. 用户可以通过CoreDNS配置中的ttl参数调整这个值
3. 设置为0理论上应该禁用缓存，但在实际测试中仍观察到5秒的TTL

CoreDNS缓存行为

CoreDNS的缓存插件有以下特点：

1. 对cluster.local域名的查询结果默认会进行缓存
2. 即使显式配置disable success cluster.local，在某些情况下仍可能缓存
3. 缓存存在最小TTL限制，这可能覆盖用户配置的更小值

解决方案探索

配置调整尝试

用户尝试了以下配置调整：

1. 将TTL显式设置为0：

kubernetes cluster.local in-addr.arpa ip6.arpa {
  pods insecure
  fallthrough in-addr.arpa ip6.arpa
  ttl 0
}

2. 禁用特定域名的缓存：

cache {
  disable success cluster.local
  disable denial cluster.local
}

3. 完全移除缓存插件

根本原因发现

经过深入排查，发现问题实际上出在node-local-dns组件上：

1. node-local-dns作为DaemonSet运行在每个节点上
2. 它作为CoreDNS的缓存层，即使Pod没有显式配置使用它，流量也可能被劫持
3. node-local-dns有自己的缓存策略，会覆盖CoreDNS的配置

最佳实践建议

对于需要快速感知Pod变化的服务（如Redis Sentinel），建议：

1. 确保整个DNS解析链路的缓存策略一致
2. 对于关键服务，考虑完全禁用DNS缓存或设置极低的TTL
3. 检查所有可能影响DNS解析的组件（如node-local-dns、操作系统resolver等）
4. 使用dig或nslookup工具验证实际的TTL值和解析结果

经验总结

Kubernetes中的DNS解析是一个多层系统，任何一层的缓存都可能导致服务发现延迟。在排查类似问题时，需要：

1. 全面检查DNS解析链路中的所有组件
2. 使用实际查询工具验证配置是否生效
3. 对于有状态服务，考虑使用更可靠的服务发现机制（如直接使用Endpoint API）
4. 在测试环境充分验证配置变更的效果

通过系统性地分析DNS解析链路，可以有效解决服务发现延迟问题，提高分布式系统的可靠性。