解读

在国内面试场景里，Alpine 镜像因体积小被广泛使用，但musl libc 与 glibc 差异、国内网络环境对 UDP 53 的干扰、企业内网 DNS 劫持三大因素，导致“容器内 ping 不通域名”的故障率远高于 Debian 系列。面试官想确认你能否在无图形、无跳板机的纯命令行环境下，5 分钟内定位根因并给出可在生产复现的修复方案，同时体现对镜像体积、安全、CI/CD 流水线的综合权衡。

知识点

1. Alpine 使用 musl libc，其 resolver 实现与 glibc 在 search 域、ndots 默认 5、EDNS0 包大小等方面行为不同。
2. Kubernetes 集群 CoreDNS 与宿主机 systemd-resolved 共存时，Alpine 先走 search 域拼接，易触发 NXDOMAIN 回退延迟。
3. 国内云厂商 VPC 对 UDP 53 限速或丢包，导致大于 512 字节的 DNS 响应被截断，musl 不会自动 fall back to TCP。
4. Docker 默认嵌入的 iptables 规则可能丢弃了 conntrack 状态为 INVALID 的 DNS 应答包。
5. /etc/resolv.conf 的 options single-request-reopen 在 musl 中无效，需改用 resolv.conf 的 options ndots:0 或 显式安装 bind-tools 做对比测试。
6. 最小镜像原则下，Alpine 默认无 drill/dig，需通过 apk add --no-cache bind-tools 临时调试，调试后可在多阶段构建中移除。
7. 安全视角：修复方案不得引入 setuid 程序，不得额外开放 53 以外端口，非 root 用户容器仍需能解析。

答案

“我遇到 Alpine DNS 异常时，按三层六步法排查，全程在容器内完成，不依赖宿主机图形工具，3 分钟定位、2 分钟修复，并给出可在 CI 固化到镜像的终态方案。

第一步：确认现象
exec 进入容器，先 nslookup kubernetes.default 与 ping -c1 114.114.114.114，若 IP 通域名不通，可锁定 DNS 而非网络层。

第二步：抓包定位
apk add --no-cache tcpdump tshark，在容器内执行
tcpdump -i eth0 -n port 53 -w /tmp/dns.pcap &
再次 nslookup，30 秒内停抓包。用 tshark -r /tmp/dns.pcap -Y "dns.flags.rcode != 0" 过滤，若看到 FORMERR、Truncated、NXDOMAIN 占比高，即可判断是 musl 与上游 DNS 不兼容或 UDP 包被截断。

第三步：比对差异
在同一 Pod 内临时起 debian sidecar 容器，cat /etc/resolv.conf 发现 search 域多达 7 条，ndots 5，而 Alpine 会顺次拼接导致 7×5=35 次查询。debian 因 glibc 有 ndots timeout 回退机制感知快，Alpine 则累积超时。

第四步：快速验证
在 Alpine 容器内 echo "options ndots:0 timeout:1 attempts:2" >> /etc/resolv.conf，再次 nslookup，若延迟从 5 s 降至 100 ms 以内，即可确认根因。

第五步：生产修复

1. Dockerfile 层固化：
   FROM alpine:3.19
   RUN echo "options ndots:0 timeout:1 attempts:2" > /etc/resolv.conf.head
   COPY fix-resolv.sh /docker-entrypoint.d/10-fix-resolv.sh
   其中 fix-resolv.sh 在运行时把 /etc/resolv.conf.head 内容追加到 /etc/resolv.conf，保证 Pod 级 resolv.conf 被 kubelet 重写后仍生效。
2. Kubernetes 层：给 Pod 加 dnsConfig 字段，ndots:0，searches: []，强制使用集群 DNS 的 ClusterFirst 策略，避免宿主机 search 域干扰。
3. 如 UDP 包被截断，在 CoreDNS 配置里强制 force_tcp，或在 node 级开启 DNSCache DaemonSet 做 TCP 回退，不改动业务镜像。

第六步：回归验证
在 CI 流水线里加 drill -t 3s @10.96.0.10 kubernetes.default，断言 RTT < 200 ms 且 NOERROR，失败即阻塞镜像晋级，保证后续任意节点、任意云厂商复现率 0。

以上方案已在国内阿里云、腾讯云、华为云 VPC 双栈环境验证，镜像体积仅增加 1 KB，无额外特权，符合等保 2.0 非 root 容器要求。”

拓展思考

1. 若企业内网使用 自建 DNS over HTTPS，Alpine 容器如何无侵入接入？可在 sidecar 注入 Envoy，监听 127.0.0.1:53 做 UDP to DoH 转发，业务容器零改造。
2. 多架构镜像场景下，Alpine arm64 版本 musl 1.2.x 之前存在 big-endian 解析 bug，CI 如何通过 QEMU + gitlab-ci buildx 做交叉验证 DNS 用例？
3. 服务网格环境中，istio-proxy 拦截 53 端口导致 Alpine 再次超时，如何结合 istio dnsCapture 与 dnsConfig 实现 0 查询延迟？
4. 安全加固视角：非 root 用户容器无法写 /etc/resolv.conf，如何在 ENTRYPOINT 以 readOnlyRootFilesystem=true 方式通过 tmpfs 挂载可写层并保证 resolv.conf 修复脚本仍生效？