当前位置：首页 > news >正文

15. CoreDNS

news 2026/5/12 5:23:04

CoreDns

什么需要服务发现？

在 Kubernetes 中，Pod 是有生命周期的，IP 会变化，因此不能直接使用 Pod IP。

Kubernetes 通过 Service 暴露一组 Pod，并提供稳定的 ClusterIP。

但是，其他应用怎么知道 Service 的 IP？

这就需要“服务发现”

服务发现方式 1：环境变量（旧方案）

原理

Pod 启动时，kubelet 将当前所有 Service 的信息（IP/端口等）注入为环境变量，例如：

NGINX_SERVICE_SERVICE_HOST=10.111.22.33
NGINX_SERVICE_SERVICE_PORT=5000

容器内即可通过环境变量访问服务。

缺点（致命）

依赖服务必须在 Pod 启动前存在
否则环境变量不会被注入。

这就导致：

先启动应用 Pod，再创建 Service → Pod 无法获取环境变量

必须保证启动顺序（使用 initContainer 或其他手段）→ 增加复杂性

因此环境变量被判定为不适合动态微服务系统。

服务发现方式 2：DNS（推荐）

DNS 是互联网使用的 IP 发现标准方式，Kubernetes 中也采用 DNS 来解决服务发现问题。

DNS 解析流程（互联网版）

DNS 递归解析过程包含以下角色：

递归解析器（Resolver）
根域名服务器（.）
顶级域名服务器（TLD，例如 .com）
权威 DNS 服务器

解析步骤概述：

浏览器向递归解析器查询
解析器问根服务器
根服务器返回 TLD 服务器地址
解析器问 TLD
TLD 返回权威服务器地址
解析器问权威服务器
返回该域名的 IP

K8s 的 DNS 服务：CoreDNS

Kubernetes 通过 CoreDNS 提供集群内部的 DNS 解析，用于：

Service 名称 → ClusterIP
Headless Service → Pod IP 列表
Pod 名称 → Pod IP

CoreDNS 由 Deployment + Service（ClusterIP）构成，一般地址为：
10.96.0.10

由 kubelet 配置给每个 Pod：

clusterDNS:
- 10.96.0.10
clusterDomain: cluster.local

K8s 中 Service 的域名规则

普通 Service

生成 DNS 域名：

servicename.namespace.svc.cluster.local

在 Pod 内部简写方式：

写法	说明
servicename	同 namespace
servicename.namespace	不同 namespace
servicename.namespace.svc.cluster.local	完整 FQDN

示例

访问 nginx-service（端口 5000）：

curl nginx-service:5000
curl nginx-service.default.svc
curl nginx-service.default.svc.cluster.local

Headless Service（clusterIP: None）

返回 Pod IP 列表：

A 记录：pod1_IP  
A 记录：pod2_IP

可用于负载均衡或自定义服务发现机制（如 gRPC、StatefulSet）。

也可通过以下方式访问具体 Pod：

podname.servicename.namespace.svc.cluster.local

CoreDNS 默认配置（解释重要插件）

插件	作用
kubernetes	Service/Pod DNS 解析核心插件
forward	非集群域名转发到宿主机 DNS
cache	DNS 缓存
log	输出解析日志
reload	动态加载配置
health / ready	健康检查
loadbalance	返回记录时随机排序

常用 CoreDNS 扩展方式

1. 启用日志功能

log

2. 特定域名使用自定义 DNS 服务器

example.com:53 {forward . 10.10.0.10
}

自定义 hosts 映射

hosts {127.0.0.1 www.example.comfallthrough
}

内外统一域名 rewrite

将 foo.example.com → foo.default.svc.cluster.local

rewrite stop {name regex foo.example.com foo.default.svc.cluster.localanswer name foo.default.svc.cluster.local foo.example.com
}

禁止 AAAA（IPv6）解析加速 DNS 查询

template IN AAAA .

验证 CoreDNS 是否正常工作

创建测试 Pod:

image: cnych/jessie-dnsutils
command: ["sleep", "infinity"]

查看 DNS 配置：

cat /etc/resolv.confnameserver 10.96.0.10
search default.svc.cluster.local svc.cluster.local cluster.local
# 注意 search 域决定了 DNS 查询顺序。

DNS 查询效率问题：curl s 与 curl s.default

curl s
# DNS 会依次尝试：
# s.default.svc.cluster.local
# s.svc.cluster.local
# s.cluster.local
curl s.default
# DNS 会先查询： s.default.<search-domain>
# 因为 curl s.default 比 curl s 多一次失败查询，因此效率稍低。

ndots / DNS 查找行为（要点）

ndots 是 resolv.conf 的一个选项，控制“是否把一个查询名视为可能的绝对（FQDN）”的阈值。

规则（常见 resolver 行为）：

若查询名中 . 的数量 ≥ ndots，则先把该名字当作绝对（带 . 结尾的 FQDN）进行解析（即直接查询 name.）。
如果绝对解析失败，才会尝试使用 search 列表逐项追加后缀再次解析。
若查询名中 . 的数量 < ndots，则先用 search 一项项追加后缀去解析（例如 name.ns.svc.cluster.local），全部失败后才以绝对名再试一次（name.）。

Kubernetes 集群默认：ndots:5，目的是优先匹配集群内较长的服务名（例如 a.b.c.d.e 属于内部名字，应优先走集群 DNS），从而避免不必要地把内部名发到上游公网解析器。

举例：

假设 search 为 default.svc.cluster.local svc.cluster.local cluster.local。

ndots:5，查询 a.b.c.d.e（有 4 个 .）

4 < 5 → 先走 search：
a.b.c.d.e.default.svc.cluster.local → 若失败再试 a.b.c.d.e.svc.cluster.local → … → 最后再试 a.b.c.d.e.（绝对名）。

ndots:5，查询 a.b.c.d.e.f（有 5 个 .）

5 ≥ 5 → 先试 a.b.c.d.e.f.（绝对名）。如果失败，再按 search 列表尝试追加后缀（实现依赖解析库，但多数实现会在绝对名失败后继续尝试 search）。

如果你在名字末尾加 .，例如 youdianzhishi.com. —— 解析器直接按绝对名处理，跳过 search 列表（节省查询和延迟）。

如何查看 Pod 的 ndots / resolv.conf

kubectl exec -it <pod> -- cat /etc/resolv.conf
# 会看到类似:
# search default.svc.cluster.local svc.cluster.local cluster.local
# nameserver 10.96.0.10
# options ndots:5

你也可以在 Pod spec 中通过 dnsConfig.options 设置/覆盖 ndots：

dnsPolicy: "None"           # 或者其它策略，dnsConfig 可与任意策略一起使用（dnsPolicy: None 时必须指定 dnsConfig）
dnsConfig:options:- name: ndotsvalue: "1"

调试与抓包（常用技巧）

在 Pod 内运行 nslookup / dig 来观察 resolver 行为（是否走 search、是否为绝对名、返回的 nameserver）。
为观察 CoreDNS 日志，可在 CoreDNS 配置里启用 log 插件，观察解析请求与来源。
做抓包（tcpdump）：
- 若容器内无 tcpdump，可切到宿主机，进入目标容器的网络 namespace（用 crictl / docker 或者 kubectl debug）并在 namespace 内执行 tcpdump。
- 或用 kubectl-debug / ephemeral containers 插入调试容器来抓包。

性能与可靠性建议

保留默认 ndots:5：对于大多数 k8s 集群这是合理的，因为它降低了内部长域名被外部 DNS 误解析的概率。
对外网密集型服务可以调整为 ndots:1/2：如果应用大量访问外部短域名（如 api.example.com）且对解析延迟敏感，可为该 Pod 单独设置 ndots:1，减少 search 尝试，直接用绝对查询。
最好使用 FQDN（并在需要时加 .）：应用里尽量使用 service.namespace.svc.cluster.local（或在代码里配置），或在需要规避 search 的地方在域名末尾加 .，可避免额外的 search 查询。
减少 search 列表长度：Kubernetes 最多允许 6 个搜索域，过多的 search 域会导致更多尝试和额外延迟。尽量使 search 列表精简。
对 stateful/依赖 pod IP 的服务，使用 headless service：避免通过 DNS 轮询引入不确定性。
监控 CoreDNS 延迟与查询失败率：若看到大量超时或转发到上游的查询（尤其是 IPv6 AAAA 导致的额外延迟），考虑使用 template IN AAAA . 或优化 forward 配置。

性能优化

DNS 5s问题

核心问题：客户端（glibc/musl）并行发 A/AAAA 请求导致相同五元组的 UDP 报文在内核 conntrack 插入时竞争或被丢弃，表现为随机 5s DNS 超时（重试等待）。 Linux 内核问题。

使用TCP发送DNS请求[不推荐]

# 在 Pod 或主机的 /etc/resolv.conf 中加入：
options use-vc

Pod 中的 resolv.conf 是由 Kubelet 生成的，不允许你直接写文件，只能用 dnsConfig 注入 options。

apiVersion: v1
kind: Pod
metadata:name: test-vc
spec:containers:- name: busyboximage: busyboxcommand: ["sleep", "3600"]dnsPolicy: ClusterFirstdnsConfig:options:- name: use-vc

说明：

使用 TCP 查询 DNS
不走 UDP → 不会触发 UDP conntrack 问题
CoreDNS 端要求支持 TCP（默认支持）

缺点：

TCP 开销较大，性能比 UDP 差

避免相同五元组DNS请求的并发[不推荐]

single-request-reopen发送A类型请求和AAAA类型请求使用不同的源端口(Socket)。这样两个请求在conntrack表中不占用同一个表项，从而避免冲突。

single-request避免并发，改为串行发送A类型和AAAA类型请求。没有了并发，从而也避免了冲突。

options single-request-reopen

K8s中

apiVersion: v1
kind: Pod
metadata:name: test-srr
spec:containers:- name: busyboximage: busyboxcommand: ["sleep", "3600"]dnsPolicy: ClusterFirstdnsConfig:options:- name: single-request-reopen

没什么必要 NodeLocal DNSCache 方案比这个好很多。

NodeLocalDNS

NodeLocal DNSCache（nodelocaldns）通过：

在每个节点运行一个本地 DNS 缓存
Pod 的解析直接访问 NodeLocalDNS（本地 169.254.20.10）
缓存不存在时再代理到 kube-dns，并强制使用 TCP

1. 获取Yaml

wget https://raw.githubusercontent.com/kubernetes/kubernetes/master/cluster/addons/dns/nodelocaldns/nodelocaldns.yaml

2. 修改 YAML 中的几个关键变量

占位符	说明
`__PILLAR__DNS__SERVER__`	kube-dns ClusterIP
`__PILLAR__LOCAL__DNS__`	NodeLocalDNS 在本机监听的 IP（一般 169.254.20.10）
`__PILLAR__DNS__DOMAIN__`	集群域名（一般 cluster.local）
`__PILLAR__UPSTREAM__SERVERS__`	外部 DNS（8.8.8.8 / 114.114.114.114 等）

# 获取 kube-dns ClusterIP
ubuntu@ubuntu:~$ kubectl get svc -n kube-system kube-dns
NAME       TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)                  AGE
kube-dns   ClusterIP   10.96.0.10   <none>        53/UDP,53/TCP,9153/TCP   77d
# NodeLocalDNS 可以是任何地址，只要该地址不和你的集群里现有的 IP 地址发生冲突即可
# 集群域名 一般 cluster.local 除非安装时指定 
# 可以执行下方去查询
ubuntu@ubuntu:~$ kubectl get cm -n kube-system kubeadm-config -o yaml

替换 YAML 内容

ubuntu@ubuntu:~$ sed \-e 's/__PILLAR__DNS__SERVER__/10.96.0.10/g' \-e 's/__PILLAR__LOCAL__DNS__/169.254.20.10/g' \-e 's/__PILLAR__DNS__DOMAIN__/cluster.local/g' \nodelocaldns.yaml | kubectl apply -f -
serviceaccount/node-local-dns created
service/kube-dns-upstream created
configmap/node-local-dns created
daemonset.apps/node-local-dns created
service/node-local-dns created
# 查看是否成功
ubuntu@ubuntu:~$ kubectl get pods -n kube-system -l k8s-app=node-local-dns -o wide
NAME                   READY   STATUS    RESTARTS   AGE    IP                NODE     NOMINATED NODE   READINESS GATES
node-local-dns-c9ktr   1/1     Running   0          104s   192.168.236.103   node2    <none>           <none>
node-local-dns-lqf85   1/1     Running   0          104s   192.168.236.101   master   <none>           <none>
node-local-dns-t5lnl   1/1     Running   0          104s   192.168.236.102   node1    <none>           <none>

开启 NodeLocalDNS（关键部分）

NodeLocalDNS 部署好之后，Pod 并不会自动使用它

你必须让 kubelet 或 Pod 的 resolv.conf 指向它。

# 查看配置
kubectl -n kube-system get configmap kube-proxy -o yaml
# 看model是啥， 空为iptables

修改默认clusterDns配置

# 修改配置 每个节点都执行
ubuntu@ubuntu:~/example/dns$ sudo sed -i 's/10.96.0.10/169.254.20.10/g' /var/lib/kubelet/config.yaml
ubuntu@ubuntu:~/example/dns$ sudo systemctl daemon-reload
ubuntu@ubuntu:~/example/dns$ sudo systemctl restart kubelet

注意：这个先去测试执行，再去生产执行。保险的话不修改默认的，手动指定 dnsnamespace。

验证 NodeLocalDNS 是否生效

创建Pod

# dns-test.yaml
apiVersion: v1
kind: Pod
metadata:name: dns-test
spec:containers:- name: testimage: busyboxargs: ["sleep", "3600"]

验证：

# 查看dns
ubuntu@ubuntu:~/example/dns$ kubectl exec -it dns-test -- /bin/sh
/ # cat /etc/resolv.conf 
search default.svc.cluster.local svc.cluster.local cluster.local
nameserver 169.254.20.10
options ndots:5
# 追踪解析
/ # nslookup www.baidu.com
Server:		169.254.20.10
Address:	169.254.20.10:53Non-authoritative answer:
www.baidu.com	canonical name = www.a.shifen.com
Name:	www.a.shifen.com
Address: 183.2.172.17
Name:	www.a.shifen.com
Address: 183.2.172.177Non-authoritative answer:
www.baidu.com	canonical name = www.a.shifen.com
Name:	www.a.shifen.com
Address: 240e:ff:e020:99b:0:ff:b099:cff1
Name:	www.a.shifen.com
Address: 240e:ff:e020:98c:0:ff:b061:c306
/ #

旧POD不会一起更新配置，请采用滚动更新的办法重启

查看全文

http://www.jsqmd.com/news/45443/