AWS免实名账号 AWS EKS CoreDNS Pod 频繁 Crash 导致集群内网域名解析失败排查

这类问题我碰到最多的场景，不是“CoreDNS 代码坏了”，而是集群资源不稳、节点池太紧、VPC DNS 配置有误、账号支付或风控没处理好，最后表现成 DNS 全面不可用。

用户真正关心的通常就三件事：业务为什么突然挂、要不要重建集群、怎么避免下次再出。下面我按实际排查顺序讲，不绕概念。

一、先确认是不是账号和账单把集群间接拖垮了

很多人一上来就盯着 CoreDNS 日志，但实际根因在 AWS 账号状态：

• 新账号未完成验证：部分账号会卡在电话验证、身份信息补充、支付方式校验，EKS 创建成功不代表后续节点扩容就一定正常。
• 信用卡扣款失败：AWS 以后付费为主，卡片拒付、账单地址不一致、跨境卡风控，都会导致自动扩容失败，节点起不来，CoreDNS 就容易被挤爆。
• 账户触发风控：短时间频繁开关实例、创建多地域资源、IP 变化大，容易触发审查。轻则限制部分资源，重则影响 EC2、EKS、ECR 拉镜像。
• AWS免实名账号 预算不足但没有告警：很多集群不是“技术故障”，而是节点缩到只剩 1-2 台小规格机器，CoreDNS 和业务 Pod 抢资源，先崩的往往就是 kube-system 里的组件。

实操建议：如果你是刚开的 AWS 国际账号，先在 Billing 里确认三件事：支付方式有效、账单无欠费、预算告警已打开。否则你把 CoreDNS 修好，过两天扩容失败还是会复发。

二、CoreDNS 频繁 Crash，优先看这 4 类现场症状

现象	最常见原因	你该先查什么	处理方向
Pod 反复 CrashLoopBackOff	内存不够、OOMKilled	kubectl describe pod / logs	调高 requests/limits，给系统组件独立资源
Pod Running 但集群内网域名解析失败	Service 没 endpoints、Corefile 被改坏	kubectl get svc/endpoints coredns	恢复 Corefile，检查 kube-dns Service
只在业务高峰期出问题	节点压力大，DNS 请求被拖慢	kubectl top node / pod	增加节点、分离系统节点、限制业务 Pod 抢占
新建 Pod 全部解析失败	VPC DNS 选项不正确	VPC DNS Support / Hostnames	确认开启 enableDnsSupport、enableDnsHostnames

三、我建议的排查顺序：先定位是不是“资源问题”，再看“配置问题”

1. 看 Pod 是否真死了
   执行： kubectl -n kube-system get pod -l k8s-app=kube-dns -o wide
   如果看到 CrashLoopBackOff 或重启次数一直涨，优先看内存和日志。
2. 看是不是 OOMKilled
   执行： kubectl -n kube-system describe pod <pod名>
   如果事件里有 OOMKilled，别先怀疑网络，直接给 CoreDNS 提资源。很多集群默认配置在业务量上来后不够用。
3. 看 endpoints 是否正常
   执行： kubectl -n kube-system get endpoints kube-dns
   如果 endpoints 为空，问题不在“解析规则”，而在服务发现链路断了。
4. 从业务 Pod 里做 nslookup
   在一个普通业务 Pod 里执行： nslookup kubernetes.default
   如果连集群内部域名都不通，优先查 CoreDNS；如果内部通、外部不通，再看转发配置和 VPC 出口。

经验上，80% 以上的 CoreDNS Crash 不是重装能解决的，而是“节点太紧、系统 Pod 没有独立保护、账单/扩容受限”这几类组合问题。

四、不同报错，对应的修法不一样，别乱改 Corefile

• 报错：OOMKilled
  先把 CoreDNS 的内存 request/limit 往上调，再看是否需要把 kube-system 调度到独立节点组。
• 报错：readiness probe failed
  常见于节点压力大、DNS 请求超时。先查节点 CPU/内存，再看是否有网络抖动。
• 报错：no such host
  如果是内部服务名，检查 Service 和 Endpoints；如果是外部域名，检查 CoreDNS 的 forward 配置和 VPC DNS。
• Pod 没有崩，但一直解析慢
  多半不是 CoreDNS 本身，而是节点负载高、连接数高、或者被业务 Pod 抢资源。

AWS免实名账号 提醒：不要在没留备份的情况下直接改 Corefile。很多人把转发规则改乱后，问题从“偶发失败”变成“全站无法解析”。

五、账号购买、实名认证、支付方式：这几个点会直接影响你能不能把问题修完

如果你是从零开 AWS 国际账号，或者是刚迁移到 AWS，下面这些实际问题经常被忽略：

• 实名认证/身份校验：企业账号建议把公司名称、注册地址、联系人、账单地址一次填对。信息不一致时，后面风控审核会更慢。
• 支付方式差异：国际信用卡通常最稳；虚拟卡、来路不清的预付卡，容易在第一次扣费就失败。
• 充值续费习惯不同：AWS 不是国内云那种“先充再用”的思路，更多是后付费。你要盯的是账单提醒、扣款状态、预算报警，不是等快停服了才处理。
• 风控审核：如果你短时间内创建多个 EKS、节点组、ELB、NAT 网关，账号容易进入人工审查。审查期间最怕的就是你还在扩容修故障。
• 使用限制：新账号默认配额不高，EKS 节点数、EC2 实例、EIP、NAT 网关都可能卡住。结果就是 CoreDNS 资源不够，问题一直反复。

我的建议很直接：生产环境账号不要用“临时卡+临时信息”去跑。一旦账单或风控卡住，DNS 问题会被放大成业务中断。

六、成本怎么选：修 CoreDNS 还是加系统节点？

方案	月度增量成本	适合什么场景	我的建议
只调 CoreDNS 资源	几乎不增加	轻量集群、测试环境	可先做，但要配合监控
加一组系统专用节点	约 15-40 美元/台起，视区域而定	生产集群、业务高峰明显	最稳妥，能明显减少抢资源
多可用区分散部署	更高，受区域价格影响明显	对稳定性要求高	适合核心业务，别为了省几美元冒风险

区域价格差别很明显。一般来说，新加坡、东京、悉尼这类区域单价会高于美国部分区域；如果你的业务可以接受时延，选区对成本影响很大。很多人以为 DNS 故障是技术问题，最后发现是为了省节点费，把系统组件挤到最小规格。

七、什么时候不要继续修，应该直接升级账号权限或找 AWS 支持

下面这些情况，不建议自己硬扛：

• CoreDNS 已经重建过，还是持续 OOMKilled。
• 所有节点都正常，但 kube-dns endpoints 一直为空。
• 账号出现扣款失败、服务限制、扩容失败同时发生。
• 同一套配置在别的账号正常，在当前账号反复失败。

这类问题往往不是“再改一个参数”能解决的。更常见的处理方式是：先稳住账号支付和配额，再处理集群资源，再回头看 DNS 配置。顺序错了，修一天也可能只是暂时恢复。

最后给一个实战判断

如果你的 EKS 里 CoreDNS 频繁 Crash，先问自己三个问题：

• 账号账单和支付方式是否稳定？
• 系统组件有没有独立资源，不和业务 Pod 抢？
• VPC DNS、Service、Endpoints 这条链路有没有一个环节被改坏？

只要这三项里有一项不稳，DNS 失败大概率会反复出现。真正省时间的做法，不是盯着“崩了几次”，而是把账号、配额、节点、DNS 配置一起看。