3. Kubernetes 集群 DNS 架构：CoreDNS 部署模式、Pod DNS 策略与 Service/Endpoint 映射

在 Kubernetes 集群中，DNS 是服务发现与外部域名解析的核心基础设施。理解 CoreDNS 的部署模式、Pod 的 DNS 策略以及 Service 与 Endpoint 的映射关系，是排查证书轮换引发解析失败的前提。本章从这三个维度拆解集群 DNS 架构。

3.1 CoreDNS 部署模式

Kubernetes 1.13+ 默认使用 CoreDNS 作为集群 DNS 组件，替代了早期的 kube-dns。CoreDNS 以 Deployment 形式运行，通常部署 2 个副本以保证高可用，并通过 ClusterIP Service 暴露 DNS 解析入口。

关键部署特征：
  • Pod 数量： 通常 2 副本，可通过 HPA 自动扩缩。
  • 监听端口： UDP/TCP 53（DNS 协议），以及 9153（Prometheus 指标）。
  • 配置方式： 通过 ConfigMap coredns 动态加载 Corefile 配置。
  • 网络模式： 使用 hostNetwork: false，通过 ClusterIP 暴露。

CoreDNS 采用插件化架构，核心插件包括：

插件名称 功能说明 排错关注点
kubernetes 将 Service 名称解析为 ClusterIP 检查 zone 配置是否匹配集群域名（如 cluster.local）
forward 将外部域名请求转发至上游 DNS 服务器 证书轮换后，上游 DNS 的 TLS 证书是否受信任
cache 缓存 DNS 查询结果，减少上游压力 缓存过期时间（TTL）可能导致解析延迟
loop 检测并防止 DNS 解析环路 配置错误时可能导致解析超时
health 提供健康检查端点（:8080/health） Pod 状态正常但插件异常时可能误判
排错提示： 证书轮换场景下，重点关注 forward 插件的 tls 配置段。如果上游 DNS 更换了证书，但 CoreDNS 的 Corefile 中未更新 CA 证书或未配置 tls_servername，会导致外部域名解析失败。
CoreDNS 部署架构与 DNS 请求流转 应用 Pod /etc/resolv.conf kube-dns Service ClusterIP: 10.96.0.10 coredns-0 Pod IP: 10.1.0.2 coredns-1 Pod IP: 10.1.1.3 上游 DNS 服务器 外部域名解析 请求流转说明： 1. Pod 根据 /etc/resolv.conf 中的 nameserver 指向 kube-dns Service（10.96.0.10） 2. Service 将请求负载均衡到后端 CoreDNS Pod（coredns-0 / coredns-1） 3. CoreDNS 根据 Corefile 配置：集群内部域名由 kubernetes 插件解析，外部域名由 forward 插件转发至上游 DNS 4. 证书轮换影响步骤 3 中 forward 插件与上游 DNS 之间的 TLS 握手

3.2 Pod DNS 策略

每个 Pod 可以通过 dnsPolicy 字段控制 DNS 解析行为。Kubernetes 支持四种策略，理解其差异对排错至关重要：

策略名称 行为描述 典型场景 证书轮换影响
Default Pod 继承所在节点的 /etc/resolv.conf 需要直接使用宿主机 DNS 配置 不受集群 DNS 证书影响，但可能绕过集群解析
ClusterFirst 优先使用集群 DNS（CoreDNS），外部域名通过 forward 转发 默认策略，绝大多数工作负载 直接受影响：forward 插件 TLS 握手失败导致解析中断
ClusterFirstWithHostNet Pod 使用 hostNetwork 时，仍保留 ClusterFirst 行为 网络插件 DaemonSet 等 同 ClusterFirst，但需额外检查 hostNetwork 冲突
None 完全忽略集群 DNS，使用 dnsConfig 自定义配置 需要完全自定义 DNS 解析路径 不受集群 DNS 影响，但需确保自定义配置正确
排错陷阱： 证书轮换后，如果 Pod 使用 ClusterFirst 策略，但 CoreDNS 的 forward 插件未更新上游 DNS 证书，Pod 解析外部域名会失败。此时使用 Default 策略的 Pod 可能不受影响，造成“部分 Pod 正常、部分 Pod 异常”的假象。

3.3 Service 与 Endpoint 的 DNS 映射

Kubernetes 中，Service 的 DNS 解析最终映射到后端 Pod 的 Endpoint。理解这一映射关系有助于定位“服务解析正常但访问失败”的问题。

3.3.1 映射流程

  1. Service 创建： 分配 ClusterIP，并创建对应的 DNS A/AAAA 记录（格式：<service>.<namespace>.svc.cluster.local）。
  2. Endpoint 自动生成： 根据 Service 的 Selector 匹配 Pod，生成 Endpoint 对象，记录所有后端 Pod IP。
  3. CoreDNS 响应： 当查询 Service 名称时，CoreDNS 返回 ClusterIP；当查询 headless service 时，返回 Endpoint 列表（Pod IP）。
关键区别：
  • 普通 Service： DNS 返回 ClusterIP，由 kube-proxy 转发到后端 Pod。
  • Headless Service（clusterIP: None）： DNS 直接返回所有就绪 Pod 的 IP 列表，客户端自行负载均衡。
Service 与 Endpoint DNS 映射流程 1. Service 创建 ClusterIP: 10.96.1.1 DNS: my-svc.ns.svc.cluster.local 2. Endpoint 生成 Pod IP: 10.1.0.5 Pod IP: 10.1.1.6 3. DNS 查询响应 普通: → ClusterIP Headless: → Pod IP 列表 Endpoint 与 Pod 映射关系（以普通 Service 为例）： Service (ClusterIP) Endpoint 对象 Pod A (10.1.0.5) Pod B (10.1.1.6) 排错要点：如果 Endpoint 列表为空（Selector 不匹配或 Pod 未就绪），Service DNS 解析正常但访问会失败。

3.4 架构总结与排错切入点

架构层级 组件 证书轮换影响点 排错命令
Pod 层 dnsPolicy / dnsConfig ClusterFirst 策略使 Pod 依赖 CoreDNS kubectl exec <pod> -- cat /etc/resolv.conf
Service 层 kube-dns Service ClusterIP 不变，但后端 CoreDNS Pod 可能异常 kubectl get svc -n kube-system kube-dns
CoreDNS 层 CoreDNS Pod + Corefile forward 插件 TLS 证书配置 kubectl logs -n kube-system coredns-xxx
上游 DNS 层 外部 DNS 服务器 证书更换后，CoreDNS 未更新信任链 dig @<upstream> example.com
排错黄金命令： 在 Pod 内执行 nslookup kubernetes.default.svc.cluster.local 验证集群内部解析；执行 nslookup example.com 验证外部解析。如果内部正常、外部失败，问题大概率在 CoreDNS 的 forward 插件或上游 DNS 证书。
← 上一章 📖 返回目录 下一章 →