Emissary-Ingress中Ambassador容器重启后DNS解析失败问题分析

问题现象

在Emissary-Ingress项目中，当Ambassador容器发生重启（例如由于OOMKill导致）后，集群内部的DNS解析会出现异常，导致AuthService相关的请求返回503状态码，最终客户端会收到403错误。这一问题会持续影响服务，直到执行Deployment的滚动重启或手动修复容器的/etc/hosts文件。

问题根源分析

经过深入排查，发现该问题与BusyBox版本和容器内部的DNS解析配置密切相关：

1. BusyBox版本差异：Ambassador容器使用的是BusyBox v1.36.1(2023-11-06版本)，该版本存在DNS解析配置问题，而较早的v1.36.1(2023-05-18版本)和v1.28.4版本则表现正常。

2. resolv.conf配置异常：容器启动初期，/etc/resolv.conf配置正常，包含完整的search域和ndots选项。但随后会被错误地覆盖为仅包含nameserver的简化配置，导致DNS解析失败。

3. 多容器干扰：进一步调查发现，同一Pod中的其他容器可能会干扰Ambassador容器的网络配置，这也是导致resolv.conf被意外修改的原因之一。

技术背景

在Kubernetes环境中，DNS解析通常依赖于集群内部的DNS服务（如CoreDNS）。正常的resolv.conf配置应包含：

• 多个search域（包括namespace.svc.cluster.local、svc.cluster.local等）
• 正确的nameserver指向（通常为kube-dns服务的ClusterIP）
• ndots:5选项（影响域名解析的匹配规则）

当这些配置被破坏时，容器将无法正确解析集群内部的服务名称，特别是短名称（如authserver.authserver）的解析。

解决方案

针对这一问题，可以采取以下几种解决方案：

1. 临时修复：

   • 手动修改/etc/resolv.conf文件，恢复完整的search域配置
   • 在/etc/hosts中添加必要的服务IP映射

2. 长期解决方案：

   • 升级Ambassador容器使用的BusyBox版本
   • 确保Pod中的所有容器不会互相干扰网络配置
   • 考虑使用initContainer预先配置好网络设置

3. 配置优化：

   • 在Kubernetes PodSpec中明确设置dnsConfig
   • 为关键服务使用完整的FQDN（如authserver.authserver.svc.cluster.local）

最佳实践建议

为避免类似问题，建议在Emissary-Ingress部署中：

1. 监控Ambassador容器的OOM事件，预防非预期重启
2. 实施完善的健康检查机制，确保DNS解析功能正常
3. 考虑为关键服务配置冗余的解析方式
4. 定期验证容器内部的基础设施服务（如DNS）是否正常

通过以上措施，可以有效预防和解决Ambassador容器重启后的DNS解析问题，保障服务的稳定性和可靠性。