AKS集群中Ubuntu22.04容器内Docker守护进程启动异常问题

问题现象 #

在AKS v1.27集群中，基于Ubuntu18.04的镜像可正常运行Docker-in-Docker（DIND），切换为Ubuntu22.04镜像后出现以下异常：

• Keda ScaledJob创建的Pod中Docker服务无法自动启动成功，手动执行service docker start可正常启动
• 首次运行docker.sh脚本时抛出错误：Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?，再次执行脚本则能正常启动Docker并执行后续命令

原因分析 #

Ubuntu22.04默认使用systemd作为初始化系统，容器内执行service docker start为非阻塞命令——命令返回时Docker daemon可能仍在后台初始化，尚未完成启动并监听/var/run/docker.sock。而Ubuntu18.04中service命令会等待服务完全启动后再返回，因此不存在时序问题。首次执行docker.sh时，后续的docker version、docker ps在daemon就绪前就执行，导致连接失败；二次执行时daemon已完成启动，所以能正常运行。

修复方案 #

1. 修改docker.sh脚本，增加Docker daemon就绪等待逻辑 #

替换原docker.sh内容，通过循环等待确保Docker daemon完全启动后再执行后续命令：

#!/bin/bash
echo "DOCKER STARTS HERE"
service docker start

# 循环等待Docker daemon就绪
until docker info >/dev/null 2>&1; do
    echo "Waiting for Docker daemon to start..."
    sleep 2
done

docker version
docker ps

2. 优化镜像构建配置 #

• 移除ADO镜像中重复的Docker安装命令：基础镜像已安装Docker，ADO镜像的Dockerfile中可删除RUN apt-get install docker-ce docker-ce-cli containerd.io -y行，减少镜像体积与构建时间
• 确认ENTRYPOINT与CMD执行逻辑：若start.sh为启动ADO代理的脚本，建议将Docker启动逻辑嵌入start.sh，或在start.sh中先调用docker.sh并等待其执行完成，确保时序正确

3. 替代方案：使用Docker官方DIND镜像（可选） #

若无需自定义Ubuntu环境，可直接采用Docker官方docker:dind镜像作为基础镜像，该镜像已内置DIND启动时序处理逻辑，能更稳定地在容器内启动Docker daemon。

验证步骤 #

1. 重新构建镜像并推送到私有仓库
2. 更新Keda ScaledJob配置中的镜像版本
3. 触发ScaledJob创建新Pod，检查Pod日志确认docker.sh首次执行无连接错误

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