AWS EKS中DaemonSet的Pod进入Running状态后服务延迟300秒才可访问如何排查

1. 确认容器内进程状态 #

Pod进入Running状态仅代表容器沙箱环境创建完成，不代表业务进程已成功拉起。在Pod刚进入Running状态且无日志输出时，执行kubectl exec -it <故障Pod名> -c <慢启动容器名> -- ps aux查看进程状态：

• 无对应业务进程：说明卡在容器ENTRYPOINT/CMD执行前环节，排查容器存储挂载、运行时初始化问题
• 存在业务进程但无日志输出：说明进程卡在init函数执行阶段，未到日志打印逻辑，可添加GODEBUG=syncstdout=1环境变量强制标准输出立即刷新，排除日志缓冲导致的日志延迟问题

2. 排查基础镜像与资源竞争问题 #

你的运行时镜像基于chromedp headless-shell，这类容器启动时会消耗较多CPU、临时文件和进程资源，且你的两个容器中worker固定申请了1.8核CPU，未配置资源限制的容器易出现资源抢占：

• 本地直接执行docker run <慢启动容器镜像>测试能否复现启动慢问题，若可复现，用strace -tt -f <业务二进制路径>跟踪系统调用，直接定位阻塞点
• 检查EKS工作节点的CPU、内存、文件句柄、PID上限使用情况，资源不足时内核会节流进程启动逻辑，导致长时间阻塞
• 给慢启动容器配置合理的resources.requests和resources.limits，避免跨容器资源抢占

3. 排查配置与网络阻塞问题 #

• 核对慢启动容器的环境变量：你提供的YAML中source容器的POD_IP环境变量未配置取值规则，值为空，若业务代码启动时依赖该变量初始化，会出现逻辑阻塞或循环重试
• 若进程init阶段包含TRACKER、MONITOR、API等下游地址的连接逻辑，未配置超时重试规则时会出现长时间阻塞，可添加GODEBUG=netdns=2环境变量打印Golang网络请求日志，确认是否卡在网络调用环节
• 确认你配置的HTTP_PROXY/HTTPS_PROXY对内部集群地址放通，避免内部请求走代理出现超时重试

4. 补充探针辅助观测 #

当前未配置就绪探针，无法区分容器Running和业务就绪状态，建议给慢启动容器添加就绪探针，避免流量提前打到未就绪Pod，同时方便统计准确的启动耗时：

readinessProbe:
  exec:
    command: ["pgrep", "<你的业务二进制文件名>"]
  initialDelaySeconds: 5
  periodSeconds: 10

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