AKS中以DaemonSet运行的Fluent Bit无法解析Azure Log Analytics DNS问题咨询

可能原因 #

• 进程启动时机早于DNS配置加载
  当前配置开启了hostNetwork: true和dnsPolicy: ClusterFirstWithHostNet，Fluent Bit进程在Pod初始化阶段就会启动，此时节点kubelet还未将集群DNS规则写入主机/etc/resolv.conf，Fluent Bit首次加载的DNS配置不可用。且Fluent Bit运行过程中不会主动重载resolv.conf配置，因此后续一直报错DNS超时。手动进入Pod执行测试命令时，DNS配置已经完成加载，因此解析正常。
• 1.8版本Fluent Bit的DNS实现缺陷
  你使用的1.8版本Fluent Bit的内置DNS客户端存在已知问题：首次域名解析失败后会长时间缓存失败结果，不会按照TTL周期主动重试解析，即使后续DNS环境恢复正常，也不会重新发起解析请求，除非重启进程。
• DNS请求并发超过AKS限流阈值
  Fluent Bit启动时会批量读取历史存量日志，同时触发大量外部域名解析请求，超过AKS节点默认的DNS查询并发限流阈值，导致初期的DNS请求被丢弃触发超时。手动测试时请求量小，未触发限流因此解析正常。
• 节点转发规则尚未加载完成
  开启hostNetwork后，Pod的DNS请求需要通过节点的iptables/nftables规则转发到CoreDNS服务，若Fluent Bit启动时kube-proxy还未完成规则刷新，会导致初期DNS请求无法被正确转发，后续规则加载完成后手动测试即可正常解析。

验证方案 #

你可以给Fluent Bit容器增加启动延迟，验证是否为启动时机问题：

containers:
  - name: fluent-bit
    image: fluent/fluent-bit:1.8-debug
    command: ["/bin/sh"]
    args: ["-c", "sleep 10 && /fluent-bit/bin/fluent-bit -c /fluent-bit/etc/fluent-bit.conf"]

如果增加延迟后问题消失，即可确认是启动时机早于网络配置加载导致。长期建议升级Fluent Bit到1.9及以上稳定版本，同时可在SERVICE配置段增加DNS_Retries 5参数提升DNS重试次数。

内容的提问来源于stack exchange，提问作者Michael Perlin