K8s 集群内的 DNS 解析是怎么工作的？ndots:5 有什么影响？

结论：集群内 DNS 由 CoreDNS 提供，Service 创建后自动获得域名 service.namespace.svc.cluster.local，同命名空间可直接用短名。Pod 的 /etc/resolv.conf 由 kubelet 注入（nameserver 指向 CoreDNS Service IP），默认带 ndots:5——名字中点号少于 5 个时，先按 search 域列表（默认 4 条：本 ns、svc、cluster.local 等）逐条补全查询，全部失败才按绝对域名查。

展开：ndots:5 的实际影响：解析 api.example.com（3 个点 < 5）会先产生 4 次无效的内部查询（api.example.com.default.svc.cluster.local 等），每个 NXDOMAIN 后才走真实外部解析——延迟放大且 CoreDNS 压力倍增，QPS 翻倍都不稀奇（A 和 AAAA 各查一遍）。优化手段：1）FQDN 末尾加点——api.example.com. 直接按绝对域名查，零浪费，是访问外部服务的推荐写法；2）对重度外呼应用定制 dnsConfig 降低 ndots（如 ndots:2）；3）NodeLocal DNSCache 在每节点跑本地缓存，减少跨节点查询与 conntrack 压力。易错点：Alpine 镜像的 musl libc 对 search 域并行查询且不支持部分 DNS 选项，曾造成大量玄学解析问题，生产镜像慎选 Alpine；headless Service（clusterIP: None）解析直接返回后端 Pod IP 列表，用于有状态服务的成员发现。

dnsConfig:
  options:
    - name: ndots
      value: "2"

追问方向：CoreDNS 的 rewrite/forward 插件机制、GSLB/多集群 DNS（Submariner、Karmada 场景）的解析链路。