CoreDNS 企业 DNS 转发与故障定位
验证：未记录
- 适用版本
- 未记录
- 验证范围
- 尚未登记验证记录。
本文缩写（英文全称与中文含义）
| 缩写 | 英文全称／名称 | 中文含义 |
|---|---|---|
| API | Application Programming Interface | 应用程序编程接口 |
| CNI | Container Network Interface | 容器网络接口 |
| CPU | Central Processing Unit | 中央处理器 |
| DNS | Domain Name System | 域名系统 |
| EKS | Elastic Kubernetes Service | AWS 托管 Kubernetes 服务 |
| FQDN | Fully Qualified Domain Name | 完全限定域名 |
| GKE | Google Kubernetes Engine | Google 托管 Kubernetes 服务 |
| IP | Internet Protocol | 网际协议；IP 地址是网络寻址标识 |
| IPVS | IP Virtual Server | Linux IP 虚拟服务器负载均衡机制 |
| NXDOMAIN | Non-Existent Domain | DNS 响应：域名不存在 |
| PDB | Pod Disruption Budget | Pod 中断预算，约束自愿驱逐 |
| QPS | Queries Per Second | 每秒查询数 |
| SLO | Service Level Objective | 服务等级目标 |
| TCP | Transmission Control Protocol | 传输控制协议 |
| TTL | Time To Live | 存活时间；具体指缓存有效期或记录过期时间 |
| UDP | User Datagram Protocol | 用户数据报协议 |
场景：订单服务解析 Kubernetes Service、企业私域和外部云服务，DNS 可用性不依赖单节点。前置：基线、企业 DNS IP/转发权限、TCP/UDP 53 路由。CoreDNS 负责集群解析；ExternalDNS负责更新权威记录，两者不同。
先确认管理者#
kubectl -n kube-system get deployment,daemonset,configmap,service | rg 'dns'
kubectl -n kube-system get configmap coredns -o yaml
kubectl -n kube-system get pods -l k8s-app=kube-dns -o wideEKS 用 add-on configuration 的 schema 管理 Corefile/副本/PDB，避免 Helm/手工更改被覆盖；GKE 可能用 kube-dns/Cloud DNS/NodeLocal DNS，按实际模式配置，不能硬套 coredns Deployment 名。
Hands-on：自管 CoreDNS 私域转发#
下面仅针对自管 CoreDNS。先把完整 ConfigMap 和 Deployment 存到平台 Git，保留 cluster.local 的 kubernetes、health/ready、loop、reload 等插件。只追加企业域 server block，不覆盖整份 Corefile：
corp.example.com:53 {
errors
cache 30
forward . 10.20.0.10 10.20.1.10 {
policy random
max_concurrent 1000
}
}替换企业 resolver IP 并确认它们不把该域再转回集群，防止循环。max_concurrent 与 cache 值按 QPS×延迟和企业 TTL 调整；DNS TTL/负缓存影响故障恢复时间。forward 插件
保存合并后的 coredns-configmap.yaml，先在同版本预生产 CoreDNS 验证语法/转发，再应用；注意 DNS 查询日志可能包含敏感域名，不长期全量记录。
kubectl apply --dry-run=server -f coredns-configmap.yaml
kubectl apply -f coredns-configmap.yaml
kubectl -n kube-system logs deployment/coredns --since=5m
kubectl -n kube-system rollout status deployment/coredns --timeout=5m配置 reload 不一定触发 Deployment rollout，日志无解析错误和真实查询成功才是验收。自管配置至少两副本跨节点，按负载扩容，PDB 保留一个可用实例；与 DNS autoscaler 的副本管理职责分开。
从真实业务网络验证#
使用组织批准、固定 digest 的诊断镜像，在 与 orders-api 相同 NetworkPolicy 条件下创建临时诊断 Job，运行以下命令；distroless 业务镜像无需为排障添加工具：
cat /etc/resolv.conf
dig orders-api.orders.svc.cluster.local
dig db.corp.example.com
dig +tcp db.corp.example.com
dig example.com比较 Service FQDN、企业域、公网域、UDP/TCP 的结果和延迟；同时从真实 API 发起数据库连接/外部调用。查询短名产生的 search/ndots 放大需压测评估，不能统一把所有 Pod 的 ndots 改成 1。
企业故障演练#
| 现象 | 检查顺序 |
|---|---|
| 所有域失败 | Pod resolv.conf → DNS Service/EndpointSlice → CNI/NetworkPolicy → DNS Pod |
| 仅私域失败 | 条件转发配置、resolver 路由/防火墙、权威记录、转发循环 |
| 间歇超时 | CPU throttling、并发上限、conntrack、丢包、上游延迟、TCP 回退 |
| 新记录仍 NXDOMAIN | 缓存/负缓存 TTL、权威是否更新、客户端缓存 |
只在预生产阻断其中一个上游 resolver，验证另一台接管、告警触发、业务 SLO；恢复后确认延迟回落。排空一个 DNS 所在节点验证仍可解析。监控 DNS QPS、rcode、p95/p99、forward health、Pod CPU/内存和失败率。
误配恢复 Git 中完整旧 ConfigMap，必要时滚动重建 DNS Pod，不能同时重启全部副本。部署 NodeLocal DNS 要单独验证本地 IP、NetworkPolicy、iptables/IPVS 和缓存行为；EKS/GKE 按托管升级流程保留自定义配置。