2. DNS 基础回顾：解析流程、核心记录类型与高可用设计原则

DNS（Domain Name System）是互联网的“电话簿”，将人类可读的域名（如 api.example.com）转换为机器可读的 IP 地址（如 10.0.1.5）。在 Kubernetes 和云原生架构中，DNS 是服务发现的核心依赖。理解其解析流程、记录类型及高可用设计原则，是定位 DNS 故障、划分故障域的前提。

2.1 DNS 解析流程

一次完整的 DNS 解析通常经历“递归查询”与“迭代查询”两个阶段。以客户端访问 www.example.com 为例，流程如下：

1. 本地缓存检查：客户端（浏览器/操作系统）首先检查本地 hosts 文件及 DNS 缓存。若命中，直接返回结果。
2. 递归查询（Local DNS Server）：若未命中，客户端向配置的 Local DNS Server（如 8.8.8.8 或集群 CoreDNS）发起递归查询。
3. 迭代查询（根 → TLD → 权威）：Local DNS Server 依次向根 DNS 服务器、顶级域（TLD）DNS 服务器（如 .com）、权威 DNS 服务器（如 example.com 的 NS 记录指向的服务器）发起迭代查询，获取最终的 A/AAAA 记录。
4. 返回与缓存：权威服务器返回 IP 地址，Local DNS Server 将结果缓存并返回给客户端。

2.2 核心 DNS 记录类型

DNS 记录存储在权威服务器的区域文件中，不同类型的记录服务于不同的解析场景。以下是云原生环境中最常见的四种记录类型：

2.3 DNS 高可用设计原则

DNS 是典型的“单点故障”高敏感组件。在云原生架构中，DNS 高可用设计遵循以下四项核心原则：

• 冗余部署（消除单点）：至少部署 2 个 DNS 服务器实例（如 CoreDNS 多副本），避免单 Pod 故障导致全局解析中断。
• 多区域/多可用区分布：将 DNS 实例分散到不同的故障域（如 Kubernetes 节点、可用区），防止物理机架或数据中心级故障。
• 缓存与 TTL 策略：合理设置 DNS 记录的 TTL（Time To Live）。长 TTL（如 300s）可减轻权威服务器压力，但会延长故障切换时间；短 TTL（如 5s）可加速故障感知，但增加查询负载。
• 健康检查与自动摘除：通过 Readiness Probe 和 Liveness Probe 持续检测 DNS 实例的健康状态，自动将异常实例从 Service Endpoint 中移除。