2. Kubernetes DNS 架构解析：CoreDNS 工作原理、Pod DNS 解析流程、Service 与 Endpoint 关系
在 Kubernetes 集群中，DNS 是服务发现的核心基础设施。理解 CoreDNS 的工作原理、Pod 的 DNS 解析流程以及 Service 与 Endpoint 的映射关系，是进行故障域划分和 DNS 故障场景调优的前提。本节将深入剖析这三层架构，帮助你在故障发生时快速定位根因。
2.1 CoreDNS 工作原理
CoreDNS 是 Kubernetes 1.13 及之后版本的默认 DNS 组件，取代了早期的 kube-dns。它采用插件化架构，通过一组链式插件处理 DNS 查询请求。
2.1.1 核心组件与插件链
| 组件/插件 | 功能描述 | 故障影响 |
|---|---|---|
| CoreDNS Pod | 运行 CoreDNS 进程，通常以 Deployment 形式部署，默认 2 个副本 | Pod 不可用导致集群 DNS 解析失败 |
| ConfigMap (coredns) | 定义 CoreDNS 的 Corefile 配置，包括插件链、上游 DNS、重试策略等 | 配置错误导致解析异常或性能下降 |
| kubernetes 插件 | 核心插件，负责将 Service 名称解析为 Cluster IP | 插件异常导致 Service 域名无法解析 |
| forward 插件 | 将集群外域名（如 www.example.com）转发到上游 DNS 服务器 | 外部域名解析超时或失败 |
| loop 插件 | 检测 DNS 解析环路，防止无限递归 | 环路检测失败可能导致 CoreDNS 崩溃 |
| health 插件 | 提供 /health 端点，用于 Kubernetes 存活/就绪探针 | 健康检查失败导致 Pod 被重启 |
| ready 插件 | 提供 /ready 端点，指示 CoreDNS 是否准备好接收流量 | 就绪状态异常导致流量被错误路由 |
2.1.2 CoreDNS 插件链处理流程
关键点：CoreDNS 的插件链是顺序执行的，每个插件可以决定是继续传递请求、直接响应还是终止链。理解这个顺序对排查 DNS 故障至关重要。
2.2 Pod DNS 解析流程
当 Pod 中的应用程序发起 DNS 查询时，解析过程遵循以下步骤。理解每一步的故障点，有助于快速定位 DNS 问题。
2.2.1 完整解析步骤
- 本地缓存检查：Pod 内的应用进程首先检查本地 DNS 缓存（如 nscd、系统缓存）。
- resolv.conf 配置：Kubernetes 通过
dnsPolicy为每个 Pod 生成/etc/resolv.conf，其中包含：nameserver：指向 CoreDNS 的 Cluster IP（默认10.96.0.10）。search：搜索域列表，如<namespace>.svc.cluster.local svc.cluster.local cluster.local。ndots：域名中点数阈值，默认 5，影响搜索域尝试次数。
- DNS 请求发送：Pod 将 DNS 查询发送到
nameserver指定的 CoreDNS 服务。 - CoreDNS 处理：CoreDNS 根据插件链处理请求：
- 如果是集群内域名（如
my-svc.my-ns.svc.cluster.local），由 kubernetes 插件 解析为 Cluster IP。 - 如果是外部域名，由 forward 插件 转发到上游 DNS。
- 如果是集群内域名（如
- 响应返回：CoreDNS 将解析结果返回给 Pod。
2.2.2 常见故障点
| 故障点 | 现象 | 可能原因 |
|---|---|---|
| CoreDNS 不可达 | Pod 无法解析任何域名 | CoreDNS Pod 崩溃、网络策略阻断、Service 异常 |
| search 域过长 | DNS 解析延迟高，大量 NXDOMAIN 查询 | ndots 配置不当，导致多次搜索域尝试 |
| kubernetes 插件故障 | Service 域名解析失败，外部域名正常 | CoreDNS 与 API Server 连接中断、RBAC 权限不足 |
| forward 插件超时 | 外部域名解析超时或失败 | 上游 DNS 不可用、网络延迟、防火墙规则 |
| 缓存污染 | 解析到错误的 IP 地址 | CoreDNS 缓存过期策略不当、TTL 配置错误 |
调优建议：在故障域划分时，建议将 CoreDNS 的
ndots 设置为 1 或 2，减少不必要的搜索域尝试。同时，合理配置 cache 插件的 TTL，避免缓存污染。
2.3 Service 与 Endpoint 关系
Service 是 Kubernetes 服务发现的核心抽象，而 Endpoint（或 EndpointSlice）是 Service 的后端 Pod 列表。理解两者的关系，有助于排查 DNS 解析后的流量转发问题。
2.3.1 核心概念对比
| 概念 | 作用 | 数据来源 | 故障影响 |
|---|---|---|---|
| Service | 提供稳定的虚拟 IP（Cluster IP）和 DNS 名称 | 用户创建 | Service 删除或名称变更导致 DNS 解析失败 |
| Endpoint | 记录 Service 对应的后端 Pod IP 和端口列表 | 自动由 Endpoint Controller 维护 | Endpoint 为空导致流量无法转发 |
| EndpointSlice | Endpoint 的改进版，支持大规模集群，每个 Slice 最多 100 个端点 | 自动由 EndpointSlice Controller 维护 | Slice 数据不一致导致负载均衡异常 |
2.3.2 Service 与 Endpoint 的映射关系
当 CoreDNS 将 Service 域名解析为 Cluster IP 后，kube-proxy 负责将发往 Cluster IP 的流量转发到后端的 Pod IP。这一过程依赖 Endpoint 的正确性。
2.3.3 故障场景分析
常见故障：当 Service 的标签选择器与 Pod 标签不匹配，或 Pod 就绪探针失败时，Endpoint 列表可能为空。此时 DNS 解析仍然返回 Cluster IP，但流量无法到达任何后端 Pod，导致连接超时。
- Endpoint 为空：检查 Service 的
selector是否匹配 Pod 标签，以及 Pod 是否处于Ready状态。 - Endpoint 不一致：使用
kubectl get endpoints <service-name>查看实际端点，与预期 Pod IP 对比。 - EndpointSlice 数据延迟：在大规模集群中，EndpointSlice 的更新可能有延迟，导致流量路由到已终止的 Pod。
2.4 总结
Kubernetes DNS 架构的核心是 CoreDNS 插件链、Pod 解析流程以及 Service 与 Endpoint 的映射关系。在故障域划分实践中，需要重点关注：
- CoreDNS 插件链配置：确保 kubernetes 插件和 forward 插件正常工作，避免环路和缓存污染。
- Pod 解析流程优化：合理设置
ndots和search域，减少不必要的 DNS 查询。 - Service 与 Endpoint 一致性：监控 Endpoint 列表，确保后端 Pod 健康且标签匹配。