ndots 是什么
kubelet 给每个 Pod 生成 /etc/resolv.conf，默认带三个 search 域（当前命名空间、svc、cluster.local）和 options ndots:5。ndots 的含义是：名字里的点数少于这个值时，先把它当成相对名字，逐个拼上 search 域去查，全部失败后才按原名查一次。集群内部服务名因此能直接用短名访问，代价是外部域名要多绕几圈。
基本信息
| 配置位置 | Pod 的 spec.dnsConfig.options，由 kubelet 写入容器内 /etc/resolv.conf |
|---|---|
| 默认值 | ndots:5，外加集群搜索域列表 |
| 影响范围 | 使用集群 DNS 的普通 Pod；hostNetwork 的 Pod 用节点自身配置 |
| 生效时机 | Pod 创建时写入，修改 dnsConfig 需要重建 Pod |
| 常见症状 | 解析外部域名时的额外查询与首包延迟 |
查看与复现
查看与复现
kubectl exec -it web-x -- cat /etc/resolv.conf # 看 search 域与 options ndots
# 典型内容：
# search prod.svc.cluster.local svc.cluster.local cluster.local
# options ndots:5
kubectl exec -it web-x -- nslookup api.example.com # 观察是否出现多次失败查询
kubectl -n kube-system logs deploy/coredns --tail=50 | grep -i example # 服务端视角的查询记录写法与解析顺序
| 应用里的写法 | 点数 | 实际查询顺序 |
|---|---|---|
| web | 0 | 逐个拼 search 域尝试，命中集群内服务 |
| web.prod.svc.cluster.local | 4 | 仍先拼 search 域尝试，失败后才查原名 |
| api.example.com | 2 | 先按 search 域逐个试，全部失败后查原名 |
| api.example.com. | 末尾加点即绝对名 | 直接查原名，完全跳过 search 域 |
缓解手段
缓解手段
spec:
dnsConfig:
options:
- name: ndots
value: "2" # 降为 2：两个点以上的名字先按绝对名查
containers:
- name: app
image: registry.example.com/app:1.26.0典型使用场景
- 解析外部域名慢：应用日志里解析耗时远高于预期，先确认是否在做无效的 search 域尝试
- 高频外部调用：调用外部 API 的服务把 ndots 调小或用绝对名写法，减少无谓查询
- CoreDNS 压力高：大量 NXDOMAIN 查询来自 ndots 机制，观察查询类型后再决定优化方向
- 跨命名空间访问：理解 search 域顺序，才知道为什么短名默认解析到自己所在命名空间
- 排查解析异常：区分「名字写错」与「search 域顺序导致的结果不同」
写绝对名时末尾的点不能省：api.example.com. 与 api.example.com 在 ndots:5 下走的是两条完全不同的查询路径。把关键依赖改成绝对名写法，通常比改集群配置更稳妥。
判断是否真的受影响，用 CoreDNS 日志或抓包统计查询次数，不要凭感觉改配置。dnsConfig 的修改只对新创建的 Pod 生效，存量的 Pod 需要重建。