Docker容器Cronjob出现getaddrinfo EAI_AGAIN错误的原因及解决方法

一、根源确认 #

getaddrinfo EAI_AGAIN是DNS解析失败的典型报错，结合SSH连不上虚拟机的情况，基本可以确定是GCE虚拟机层面的网络/DNS服务异常——容器的DNS默认继承宿主机配置，宿主机DNS挂了，容器和SSH都会受影响。你的推测方向没问题：容器启动到Cronjob执行期间，虚拟机的网络组件（比如DNS服务、网络接口）大概率出现了异常。

二、排查步骤 #

• 查GCE系统日志：在GCP控制台的Compute Engine实例详情页的日志标签里，找systemd-resolved、networkd这类网络服务的崩溃、重启记录，或者网络接口断开的日志，容器优化OS用systemd管理服务，这类日志能直接定位问题。
• 看容器日志：除了EAI_AGAIN，有没有网关连接失败、路由表异常这类报错？
• 验证DNS配置：如果能通过串行控制台连进虚拟机，先跑nslookup <第三方API域名>看能不能解析；再查/etc/resolv.conf，容器优化OS默认指向127.0.0.53（systemd-resolved），用systemctl status systemd-resolved检查服务是否正常运行。

三、预防方案 #

1. 调整Cronjob部署方式 #

• 别用容器长期驻留Cron进程：容器设计是跑单进程，长期挂着的Cron进程可能感知不到宿主机网络变化（比如DNS缓存没更新）。建议改用GCP Cloud Scheduler直接触发容器执行，或者触发GCE实例脚本启动容器跑任务，任务结束就退出——每次任务都是全新容器，会重新获取宿主机DNS配置。
• 非要用容器内Cron的话，在脚本开头加DNS验证：先跑nslookup <API域名>，失败就尝试修复容器DNS配置（比如重新挂载/etc/resolv.conf）。

2. 给GCE加自动修复机制 #

• 配置健康检查：在GCP控制台给虚拟机加TCP检查（比如监控SSH端口22），或者HTTP检查（如果有服务），检查失败时自动重启虚拟机。
• 用实例组管理虚拟机：开启自动修复功能，虚拟机异常时自动替换新实例。

3. 优化DNS配置 #

• 给GCE指定静态DNS：在虚拟机网络配置里自定义DNS服务器（比如谷歌8.8.8.8、8.8.4.4），避免依赖DHCP分配的DNS，降低解析失败概率。
• 容器启动时手动指定DNS：运行容器加--dns 8.8.8.8 --dns 8.8.4.4参数，让容器直接用公共DNS，不依赖宿主机DNS服务。

四、自动修复脚本示例 #

如果要在容器Cron脚本里加自动修复逻辑，参考下面的写法：

#!/bin/bash

API_DOMAIN="你的第三方API域名"
# 先验证DNS解析
nslookup $API_DOMAIN > /dev/null 2>&1
if [ $? -ne 0 ]; then
    # 尝试重启容器内的systemd-resolved服务
    systemctl restart systemd-resolved > /dev/null 2>&1
    sleep 2
    # 再次验证
    nslookup $API_DOMAIN > /dev/null 2>&1
    if [ $? -ne 0 ]; then
        echo "$(date) DNS解析失败，无法修复" >> /var/log/cron_job_error.log
        exit 1
    fi
fi

# 执行API调用程序
python your_api_script.py

Crontab配置：

0 12 * * * /path/to/your_script.sh >> /var/log/cron_job.log 2>&1

内容的提问来源于stack exchange，提问作者Davis Owen