CoreDNS 生产配置、性能优化与 DNS 故障排查
CoreDNS 通过插件链处理DNS请求，在Kubernetes中通常负责Service与Pod域名解析，并将外部域名转发至上游。DNS看似只是基础组件，但缓存、转发、搜索域、并发和上游抖动会放大为全应用超时。排障必须从客户端查询行为、Corefile插件顺序、CoreDNS容量和上游DNS四层同时观察。
本文面向需要把系统真正交付到生产、承担值班和恢复责任的运维人员。示例用于解释方法，版本、参数和命令在执行前应与当前官方文档及测试环境核对。建议先阅读架构和基线，再将监控、故障与检查清单改造成符合本单位环境的运行手册。
一、建设目标与适用边界
- 理解Server Block、Zone和插件链的执行顺序，避免配置能加载但行为错误
- 测算QPS、缓存、并发和副本数，为突发发布与故障重试预留容量
- 掌握Kubernetes Service发现、外部转发、负缓存和NodeLocal DNSCache
- 建立SERVFAIL、超时、循环转发、高延迟和域名偶发失败的排障路径
选型时先写清业务目标、SLO、RPO/RTO、数据敏感级别、维护窗口和团队能力。如果问题可以由更简单的组件解决，不应为了“先进”引入复杂平台。试点阶段要选择可回退、影响可控的业务，并从第一天建立负责人和退出机制。
二、核心架构与数据流
- kubernetes插件从API读取Service、EndpointSlice和Pod信息并回答集群域查询
- cache减少API与上游压力，但正负缓存TTL需要结合变更速度设置
- forward把非权威域转发给明确的上游，健康检查与并发控制决定故障表现
- loop用于发现简单转发环路，reload支持配置平滑加载，prometheus暴露指标
- NodeLocal DNSCache可缩短路径并减少conntrack压力，但仍依赖上游CoreDNS和节点网络
架构评审时要画出客户端到入口、控制面、数据面、外部依赖和持久化存储的完整路径，并标注协议、端口、认证方式、超时和重试。任何“自动发现”或“平台托管”都应能够解释其失败表现，不能成为运行手册中的黑盒。
故障域至少包括进程、节点、机架、交换机、存储、可用区、身份源和人员操作。冗余组件若共享同一电源、网络、数据库或密钥，仍可能同时失效。容量和灾备设计应按失去一个关键故障域后的剩余能力计算。
三、生产配置基线
- Corefile纳入版本控制，变更先用独立Pod或测试环境验证解析和插件顺序
- 至少两个副本并配置反亲和或拓扑分散，PDB与滚动升级参数避免同时不可用
- 为Pod设置明确requests/limits，避免CPU节流造成DNS尾延迟
- 上游地址不要形成systemd-resolved或本机resolv.conf回环，转发路径必须可解释
- 合理设置ndots与搜索域，短名称便利性不能以大量无效查询和超时为代价
- 对日志采样而非长期记录全部查询，避免DNS恢复后被日志IO再次拖慢
配置基线应保存在版本库，并通过自动化部署。参数需要注明来源、默认值、选择理由和适用规模；不要复制互联网上的“最佳参数”后永久不变。每次扩容、升级或业务模型变化后重新验证并更新基线。
四、容量规划与上线前压测
容量规划不能只按当前平均值。至少收集两到四周峰值数据，并分别估算正常增长、版本发布、批量任务、节点故障和灾难恢复期间的资源需求。计算时保留明确的安全余量，并记录假设、数据来源和失效日期。只给出“CPU 还有很多”不足以支持上线决策。
上线前压测应覆盖稳态、突发、单节点故障和依赖变慢四种情况。压测环境的节点规格、网络、数据规模和安全策略应尽量接近生产；无法一致时，应说明外推方法。观察的不只是吞吐，还包括尾延迟、错误率、队列、GC、磁盘、连接池以及故障恢复时间。压测后要清理测试账户、临时数据和放宽的限流规则。
容量评审至少回答：当前瓶颈是什么；失去一个故障域后能否承载峰值；扩容从申请到生效需要多久；磁盘或队列到达多少水位开始处理；恢复期间额外流量是否会压垮生产。把这些答案写入运行手册，比单一的规格表更有价值。
五、安全与权限边界
生产访问遵循身份可追踪、权限最小化、密钥短期化和操作可审计。人和机器使用不同身份；读取、变更、审批和审计角色尽量分离。服务账户只获得所需命名空间、数据源或接口权限，禁止因为排障方便长期保留管理员权限。
管理端口只允许受控网络访问，外部入口经过统一认证、TLS和限流。配置文件、命令历史、诊断包、日志和备份都可能包含凭据，采集与分享前需要脱敏。发生泄露时，处置顺序是吊销、轮换、确认影响范围、修复来源和复盘，而不是只删除页面或日志。
每季度检查闲置账号、长期Token、过期证书、例外策略和未关闭的临时权限。对于平台级系统，运维自身的身份源、密钥系统和备份系统不应全部依赖同一个故障域，否则生产故障时可能连恢复入口都无法使用。
六、可观测性与告警设计
可观测性要覆盖用户体验、控制面、数据面和依赖。仪表盘按“服务是否可用—请求是否健康—资源是否接近极限—依赖是否异常”组织，避免只堆积进程指标。所有告警都要有负责人、严重级别、持续时间、处置入口和静默规则。
建议采用多窗口告警：短窗口发现快速恶化，长窗口识别持续消耗。容量类告警使用预测到达时间而不只是固定阈值；队列、磁盘和证书同时显示当前值、增长速度和剩余时间。告警恢复也要通知，并记录自动恢复还是人工操作。
日志必须包含时间、实例、请求或任务标识、错误类别和必要上下文，但不记录明文凭据。指标、日志和追踪使用一致的服务名、环境和版本标签，便于从告警跳转到变更记录和调用链。对高基数标签制定准入规则，防止观测系统先于业务被拖垮。
七、变更、升级与回滚
变更前必须明确目的、影响对象、前置检查、观察指标、停止条件和回滚动作。配置与部署文件进入版本控制，自动化流水线执行语法检查、策略检查和最小功能测试。紧急变更可以缩短审批，但不能省略记录和事后复盘。
升级遵循“兼容性阅读—备份—预生产验证—小范围发布—观察—逐步扩大”。涉及元数据或协议变更时，先确认旧版本能否读取新数据、数据库迁移是否可逆、客户端和插件是否兼容。回滚不等于简单换回旧镜像；数据格式、Schema和外部副作用都要单独验证。
发布后至少观察一个完整业务周期。检查成功率、尾延迟、资源、队列、错误类别和依赖端压力，并与发布前基线比较。若达到停止条件，应优先止损，而不是在生产现场连续叠加未经验证的修复。
八、备份、恢复与灾备演练
高可用解决运行中单点故障，备份解决误删、损坏、错误变更和安全事件，两者不可替代。备份范围包括业务数据、元数据、配置、证书、加密密钥、权限策略和恢复脚本。每项都要定义RPO、RTO、保留期、加密、异地位置和负责人。
备份成功只代表文件被写出，不代表能够恢复。恢复演练应在隔离环境从零开始，记录实际耗时、依赖、人工步骤和校验结果。至少验证抽样恢复、单组件恢复和完整灾难恢复，并确认恢复后的身份、时间、DNS、证书和监控都能工作。
灾难发生时先保护现场和证据，再判断恢复点是否可信。不要把可能已损坏或已入侵的数据立即复制到所有环境。恢复后进行一致性检查、业务验收和新的完整备份，最后再逐步开放流量。
九、标准故障处理流程
- 确认影响范围：哪些用户、区域、功能和时间窗口受影响。
- 冻结高风险变更，保存事件、日志、指标和最近发布记录。
- 从入口到依赖逐层定位，先区分容量、配置、网络、数据和外部依赖。
- 优先执行可逆的止损动作，例如限流、隔离故障实例、切换只读或回滚。
- 每个动作记录时间、执行人、预期和结果，避免多人重复操作。
- 恢复后核对积压、重复任务、数据一致性和告警恢复，不以页面能打开作为结束。
- 复盘输出根因、促成因素、发现缺口、恢复缺口和有负责人及期限的改进项。
十、上线检查清单
- [ ] 架构图、数据流、端口、依赖和故障域已经登记。
- [ ] 生产与测试隔离，默认配置、示例账号和不安全入口已清理。
- [ ] 资源请求、上限、磁盘水位和扩容阈值经过压测验证。
- [ ] 身份、权限、证书、Token和网络策略符合最小权限。
- [ ] 核心指标、日志、告警、静默和通知链路已经演练。
- [ ] 备份覆盖数据、配置与密钥，并完成隔离恢复验证。
- [ ] 升级、回滚、节点故障和依赖不可用场景有操作手册。
- [ ] 值班人员能够在不依赖单一专家的情况下完成首轮处置。
- [ ] 文档标明适用版本、最后验证日期和下一次复核日期。
- [ ] 上线后观察窗口、验收指标和停止条件已经明确。
十一、关键监控指标
- 请求QPS、按rcode划分的NOERROR/NXDOMAIN/SERVFAIL数量
- 请求P50/P95/P99时延和每个上游的转发时延
- forward健康失败、连接缓存命中、最大并发拒绝
- cache命中、未命中、驱逐和缓存条目数量
- CoreDNS CPU节流、内存、重启、就绪状态和网络丢包
- Kubernetes插件编程延迟、API错误和EndpointSlice变化
为每个关键指标定义正常区间、预警阈值、严重阈值和持续时间。阈值应结合业务峰值与历史分位数，而不是照搬示例。每个严重告警至少关联一段验证命令和一个可逆止损动作。
十二、典型故障与处置顺序
| 现象 | 优先判断 | 处置顺序 |
|---|---|---|
| 集群内域名正常外网失败 | kubernetes域成功、forward超时 | 直接查询上游，检查路由、防火墙、SNAT和转发并发 |
| 偶发SERVFAIL | 上游健康失败或副本负载不均 | 按Pod拆分指标，检查CPU节流、丢包和上游延迟，勿先扩大缓存掩盖 |
| 查询数量暴涨 | NXDOMAIN和搜索域查询增加 | 定位客户端与ndots配置，检查重试风暴和错误短域名 |
| CoreDNS启动失败 | Corefile解析错误或loop退出 | 回滚配置，使用coredns -conf在隔离环境验证，并修正转发环路 |
故障处置时避免同时修改多个变量。每完成一步就观察用户影响、核心指标和错误类型是否变化。若证据不足，先采集现场；如果止损动作可能造成数据丢失或双写，应升级决策而不是由单人临场尝试。
十三、常用检查命令
kubectl -n kube-system get deploy,pod -l k8s-app=kube-dns -o wide
kubectl -n kube-system get configmap coredns -o yaml
kubectl exec <pod> -- cat /etc/resolv.conf
dig +tries=1 +time=2 kubernetes.default.svc.cluster.local
dig +trace example.com
命令只是证据入口，不是结论。执行前确认目标环境、权限和输出影响；包含删除、迁移、强制选主或恢复含义的操作必须经过审批。本节命令优先用于只读检查，具体参数以当前版本帮助和官方文档为准。
十四、运行手册应长期维护什么
- 组件与负责人、服务目录、域名、证书、端口、数据目录和依赖台账。
- 每日、每周、每月巡检项，以及异常结果的闭环记录。
- 容量趋势、扩容提前量、采购或资源申请周期和最近压测结论。
- 发布、升级、证书轮换、密钥轮换、节点替换和退役步骤。
- 告警解释、首轮检查、止损动作、升级联系人和业务确认方式。
- 备份范围、恢复顺序、最近演练证据以及未解决的恢复风险。
- 适用版本与差异。系统升级后先修订文档，再宣布新的运行基线生效。
参考资料
- CoreDNS 手册：https://coredns.io/manual/toc/
- CoreDNS 插件：https://coredns.io/plugins/
- Kubernetes DNS 调试：https://kubernetes.io/docs/tasks/administer-cluster/dns-debugging-resolution/