1. 为什么需要在K8S中部署CoreDNS在Kubernetes集群中服务发现是基础设施的核心能力之一。传统DNS服务无法满足容器动态调度带来的IP变化需求而CoreDNS作为云原生DNS解决方案通过watch机制实时感知Pod和Service变化自动更新DNS记录。我去年在金融行业容器化改造项目中就遇到过传统DNS更新延迟导致的调用超时问题迁移到CoreDNS后服务发现延迟从分钟级降到秒级。CoreDNS相比kube-dns有三个显著优势一是采用Go编写单进程架构内存占用减少40%二是支持插件化扩展可以灵活添加Prometheus监控、日志记录等功能三是性能更好实测QPS可达30k以上。这些特性使其成为Kubernetes 1.13版本后的默认DNS组件。2. CoreDNS部署方案设计与验证2.1 部署架构设计生产环境推荐采用DaemonSetHeadless Service的部署模式。我们在电商大促场景下验证过这种架构相比Deployment部署方式有两个好处每个节点本地缓存DNS记录跨节点查询减少60%避免DNS服务单点故障实测节点宕机时服务发现零中断典型配置示例apiVersion: apps/v1 kind: DaemonSet metadata: name: coredns namespace: kube-system spec: selector: matchLabels: k8s-app: kube-dns template: spec: dnsPolicy: Default # 必须设置为Default以绕过Kubelet的DNS劫持 containers: - name: coredns args: - -conf - /etc/coredns/Corefile2.2 关键配置参数调优在Corefile配置中需要特别注意三个参数cache_ttl缓存时间建议设置为30s我们在压力测试中发现这个值在缓存命中率和时效性之间达到最佳平衡reload设置为30s自动重载配置避免手动重启ready插件必须开启用于健康检查否则会导致Kubelet误判完整Corefile示例.:53 { errors health { lameduck 5s } ready kubernetes cluster.local in-addr.arpa ip6.arpa { pods verified fallthrough in-addr.arpa ip6.arpa } prometheus :9153 forward . /etc/resolv.conf cache 30 loop reload 30s }3. 域名解析全流程实现3.1 服务域名解析原理Kubernetes中Service的DNS记录生成遵循特定规则。以我们部署的payment-service为例ClusterIP模式service.ns.svc.cluster.local→ 解析到ClusterIPHeadless模式service.ns.svc.cluster.local→ 解析到所有Pod IP实测发现一个常见误区Pod的DNS名称格式为pod-ip.ns.pod.cluster.local但需要Pod配置hostNetwork: true时才可用。3.2 自定义域名配置实践通过rewrite插件可以实现企业自定义域名这是我们内部使用的配置片段rewrite continue { name regex (.*)\.internal\.company\.com {1}.default.svc.cluster.local answer name (.*)\.default\.svc\.cluster\.local {1}.internal.company.com }这个配置将db.internal.company.com自动映射到db.default.svc.cluster.local同时保持返回记录显示原始域名。4. 性能优化与问题排查4.1 监控指标重点关注项通过Prometheus监控CoreDNS时要特别关注这些指标指标名称健康阈值说明coredns_dns_request_count5000/秒报警总请求量反映DNS负载coredns_cache_hits_count命中率80%报警缓存效果直接影响性能coredns_panic_count0立即检查可能配置错误导致进程崩溃4.2 常见故障处理手册根据我们运维经验整理的高频问题NXDOMAIN响应异常检查kube-dns Service的clusterIP是否与kubelet的--cluster-dns参数一致验证CoreDNS容器是否挂载了正确的/etc/resolv.conf解析超时# 在Pod内执行诊断 dig tcp coredns-pod-ip kubernetes.default.svc.cluster.local如果TCP查询成功而UDP失败可能是网络插件丢包内存持续增长在Corefile添加cache 30限制缓存大小设置memory limit为200Mi并监控OOM5. 高级应用场景实现5.1 多集群DNS联邦方案在混合云场景下我们通过以下配置实现集群间服务发现federation cluster.local { k8s_external other-cluster upstream 10.100.0.10:53 # 其他集群的CoreDNS地址 }配合NetworkPolicy开放53端口访问权限实测跨集群解析延迟50ms。5.2 智能DNS分流方案利用view插件实现内外网差异化解析view internal { expr type() A client_ip() 10.0.0.0/8 forward . 172.18.0.53 # 内网DNS } view external { forward . 114.114.114.114 }这个配置让办公网访问解析到内网IP公网访问走正常解析。6. 版本升级与迁移要点从kube-dns迁移到CoreDNS时必须按顺序执行先部署CoreDNS并验证基础解析修改kubelet的--cluster-dns参数指向CoreDNS Service观察24小时无异常后再删除kube-dns我们在迁移过程中发现一个关键点CoreDNS对SRV记录的处理与kube-dns不同需要测试所有依赖SRV记录的服务。建议先用shadow模式并行运行kubectl scale deploy/coredns --replicas1 kubectl scale deploy/kube-dns --replicas1最后分享一个实用技巧通过给CoreDNS Pod添加annotations实现配置热更新kubectl patch deployment/coredns -p {spec:{template:{metadata:{annotations:{date:$(date %s)}}}}}
