Kubernetes DNS 架构基础：CoreDNS 工作原理、Pod DNS 解析流程、Service 与 DNS 记录

在 Kubernetes 集群中，DNS 是服务发现的核心基础设施。理解 CoreDNS 的工作原理、Pod 的 DNS 解析流程以及 Service 与 DNS 记录的映射关系，是诊断和规避 DNS 故障的前提。本节将拆解这三层结构，为后续的故障域划分提供理论支撑。

2.1 CoreDNS 工作原理

CoreDNS 是 Kubernetes 1.13 及之后版本的默认 DNS 组件，以 Deployment 形式运行在 kube-system 命名空间下，通常由两个副本构成高可用对。它通过 插件链（Plugin Chain） 处理 DNS 查询请求，每个插件负责一个独立的逻辑功能。

CoreDNS 的默认 Corefile 配置如下：

.:53 {
    errors
    health {
        lameduck 5s
    }
    ready
    kubernetes cluster.local in-addr.arpa ip6.arpa {
        pods insecure
        fallthrough in-addr.arpa ip6.arpa
        ttl 30
    }
    prometheus :9153
    forward . /etc/resolv.conf {
        max_concurrent 1000
    }
    cache 30
    loop
    reload
    loadbalance
}

2.2 Pod DNS 解析流程

Pod 内的 DNS 解析行为由 dnsPolicy 字段控制，默认值为 ClusterFirst。解析流程分为以下步骤：

1. 本地 resolv.conf 构造：kubelet 在创建 Pod 时，根据 dnsPolicy 和 dnsConfig 生成 /etc/resolv.conf 文件。
2. 查询发起：Pod 内进程调用 gethostbyname 或 getaddrinfo，向 nameserver（即 CoreDNS 的 Cluster IP）发起 DNS 查询。
3. CoreDNS 处理：CoreDNS 根据查询域名后缀决定由 kubernetes 插件处理（集群内域名）还是由 forward 插件转发（集群外域名）。
4. 响应返回：CoreDNS 将解析结果返回给 Pod，Pod 内的 nscd 或应用层缓存可能对结果进行二次缓存。

不同 dnsPolicy 的对比：

2.3 Service 与 DNS 记录

Kubernetes 为每个 Service 自动创建 DNS 记录，格式遵循 RFC 1123 规范。DNS 记录的命名规则决定了 Pod 如何通过域名访问 Service。

除了标准的 Service 记录，CoreDNS 还会为 Pod 生成 DNS 记录（当 pods insecure 或 pods verified 开启时）：

# Pod DNS 记录格式（需开启 pods 插件）
10-244-1-5.default.pod.cluster.local → 10.244.1.5

Service 的 DNS 记录生命周期与 Service 资源绑定：

• 创建：Service 创建后，CoreDNS 在 30 秒（默认 TTL）内自动添加 A 记录。
• 更新：Service 的 Cluster IP 或 Selector 变更时，CoreDNS 自动更新记录。
• 删除：Service 删除后，CoreDNS 在 TTL 过期后移除记录。
• 故障：CoreDNS 与 API Server 连接中断时，DNS 记录停留在最后一次同步状态，可能导致“DNS 缓存污染”。