Service Discovery и DNS

1）为什么需要它

在分布式系统中，节点出现并消失，客户端必须快速可靠地找到服务的工作实例。DNS是通用名称层；服务发现-将服务名称映射到实际尾部的策略，同时考虑到健康，重量和路由策略。

主要目标：

稳定名称而不是临时地址，
准确但不嘈杂的升级（新鲜度和TTL之间的平衡），
没有完全下降的降解（failover/health-check），
客户端"猜测"的最低限度：taymouts, retrais,缓存策略。

2）服务发现模型

2.1个客户端（client-side）

客户端本身将名称解析为一组尾声并平衡（round-robin，EWMA，按键哈希）。资料来源-DNS（A/AAAA/SRV），服务注册表（Consul/Eureka），静态列表。

优点：更少的中央SPOF、灵活的算法。
缺点：客户异质性,更难更新逻辑。

2.2服务器端（服务器端）

客户前往前线/LB（L4/L7，网关/ingress）。平衡和健康检查-在代理/平衡器侧。

优点：一个单一的政策位置，可观察性。
缺点：需要高可用性外围（N +1, multi-AZ）。

2.3溷合动力车

DNS提供了一组入口点（区域LB），然后是L7/mesh平衡。

3）DNS： 基础，记录和TTL

3.1基本类型

A/AAAA-IPv4/IPv6地址。
CNAME是其他名称（不在apex上）的alias。
SRV — `_service._proto.name '→主机/端口/重量/优先级（适用于gRPC/LDAP/SIP等）。
TXT/HTTP/HTTPS-元数据/指针（包括HTTP-discovery）。
NS/SOA-区域委派和属性。

3.2 TTL和缓存级联

缓存有： OS resolver，本地stub resolver，节点（NodeLocal DNS/CoreDNS），提供商，中间资源管理器和库客户端。实际新鲜=min（TTL，客户策略）。负缓存（NXDOMAIN）也通过'SOA缓存。MINIMUM`/`TTL`.

建议：

Prod-用于动态记录的TTL 30-120 s，用于稳定记录的300-600 s。
对于切换（failover），提前准备降低的TTL而不是"在火灾中"。
考虑库的sticky缓存（Java/Go/Node）-根据需要在rantime中配置resolver TTL。

4） DNS平衡和容错策略

重量RR-重量A/AAAA/SRV。
Failover-主/次要套件（外部健康检查）。
Geo/Latency是对"最近"ROR/地区的响应。
Anycast是不同POP（BGP）中的单个IP；抵御区域干扰。
Split-horizon是VPC/on-prem内部和互联网上不同的答案。
GSLB是具有健康检查和策略（后坐力，地理，能力）的全球平衡器。

5）健康检查和新鲜

DNS本身"愚蠢"：它不知道后端的健康状况。因此：

或外部健康检查器控制记录/权重（GSLB，Route53/Traffic-policy，外部dns+样品）。
或者，客户端/mesh会从多个尾部进行主动的outlier-ejection和retry。

6）Kubernetes： 开箱即用

服务名称： 'svc。namespace.svc.cluster.local`.

ClusterIP：稳定虚拟IP+kube-proxy/ebpf。
无头服务（"clusterIP： None"）：为pod（或其子域）提供A条目,为端口提供SRV。
EndpointSlice：可扩展的endpoints列表（替代Endpoints）。
CoreDNS：群集的DNS解析器；rewrite/template/forward/cache； 'kube-dns'区域插件。
NodeLocal DNSCache：节点上的本地缓存→少延迟并拦截apstream resolver问题。

示例： 无头+SRV

yaml apiVersion: v1 kind: Service metadata: { name: payments, namespace: prod }
spec:
clusterIP: None selector: { app: payments }
ports:
- name: grpc port: 50051 targetPort: 50051

客户端可以反击'_grpc._tcp。payments.prod.svc.cluster.本地'（SRV）,并获得主机/端口/重量。

CoreDNS （ConfigMap片段）

yaml apiVersion: v1 kind: ConfigMap metadata: { name: coredns, namespace: kube-system }
data:
Corefile:
.:53 {
errors health ready cache 30 loop forward. /etc/resolv. conf prometheus:9153 reload
}

NodeLocal DNS（想法）：

DaemonSet在'169上带有本地救助器。254.20.10`;kubelet指定此点。
降低p99名称分辨率并保护apstrim-DNS免受"flap"的影响。

7) Service discovery вне K8s

Consul：代理人，健康检查，服务目录，DNS接口（".consul"），KV for configs。
Eureka/ZooKeeper/etcd：JVM/legacy的注册表；通常与sidecar/网关捆绑在一起。
Envoy/Istio：EDS/xDS（端点发现）和SDS（秘密）；服务是通过control-plane宣布的。

8） DNS安全性

DNSSEC：保护记录完整性（区域签名）。对公共领域至关重要。
DoT/DoH：将通道加密到资源库（内部策略、互操作性）。
ACL和split-horizon：私人区域-仅来自VPC/VPN。
防护kesh中毒：端口/ID随机，TTL短动态。
egress上的策略：仅允许DNS用于受信任的resolver,日志。

9）客户行为和retrai

尊重TTL：不要无限期缓存，不要用频繁的垃圾箱"无法无天"（暴风雨到露天市场）。
快乐眼球（IPv4/IPv6），多个A/AAAA的并行连接减少了尾巴。
Retrai仅在等效请求下；jitter，budget retrais限制。

Rantime Resolver的微调：

Java: `networkaddress.cache.ttl`, `networkaddress.cache.negative.ttl`.
Go: `GODEBUG=netdns=go`/`cgo`, `Resolver.PreferGo`, `DialTimeout`.
Node: `dns.setDefaultResultOrder('ipv4first')`, `lookup` с `all:true`.

10） GSLB/DNS切换： 实践

在计划切换前24至48小时内将TTL从300→60降低。
保持一组金丝雀结尾的小重量验证。
应用weighted+health check代替A记录的手动质量升级。
对于静态/边缘-Anycast；对于API-Geo/Latency+快速L7-feylover。

11）名称的可观察性和SLO

度量标准：

Rate/latency DNS请求，cache命中率，类型错误（SERVFAIL/NXDOMAIN）。
带有样式响应的查询比例（如果使用样式缓存）。
更改记录（业务SLI）时用户操作的成功。
应用程序中的p95/p99 resolve-time。

诊断：

分层路径：客户端→本地缓存→ node缓存→群集解析器→提供商的资源。
监视NXDOMAIN（名称/打字错误）和SERVFAIL（资源限制问题）的爆发。

12）配置示例

CoreDNS： rewrite和stub区域

yaml
.:53 {
log errors cache 60 rewrite name suffix. svc. cluster. local. svc. cluster. local forward. 10. 0. 0. 2 10. 0. 0. 3
}

example. internal:53 {
file /zones/example. internal. signed dnssec
}

systemd-resolved（本地resolver力）

ini
[Resolve]
DNS=169. 254. 20. 10
FallbackDNS=1. 1. 1. 1 8. 8. 8. 8
Domains=~cluster. local ~internal
DNSSEC=yes

Envoy： 动态DNS-refresh

yaml dns_refresh_rate: 5s dns_failure_refresh_rate:
base_interval: 2s max_interval: 30s respect_dns_ttl: true

外部dns（公共区域支持）

yaml args:
- --source=service
- --source=ingress
- --domain-filter=example. com
- --policy=upsert-only
- --txt-owner-id=cluster-prod

13）实施清单（0-30天）

0-7天

服务名称目录,模型选择（client -/server-side/hybride）。
基本的TTL，包括NodeLocal DNSCache，dashboard DNS度量。
禁用config/代码中的"硬IP"。

8-20天

gRPC的无头服务+SRV；EndpointSlice已启用。
外部GSLB/重量；健康检查和金丝雀。
定制客户的Taymauts/Retrai和Retray预算。

21-30天

分裂地平线和私人区域；DoT/DoH政策。
开关测试（通过TTL）和操纵器；后分析。
包括mesh/EDS策略，outlier-ejection。

14）反模式

TTL=0在销售中→暴风雨到招聘人员，不可预测的延迟。
硬码IP/端口，级别没有CNAME/alias。
在没有健康检查和金丝雀的情况下"手动"更改记录。
一个没有节点缓存的全局缓存器（瓶颈）。
忽略负缓存（NXDOMAIN爆发）。
尝试通过DNS代替数据/收件人级别"治疗"DB故障。

15）成熟度量

100％的服务使用名称；Hard-IP为零。
CoreDNS/NodeLocal在销售中,cache hit-ratio> 90%在节点上。
GSLB具有健康检查，由TTL记录和运行手册切换。
SRV/EndpointSlice用于stateful/gRPC，应用程序中的p99 resolve-time ≤ 20-30毫秒。
根据SERVFAIL/NXDOMAIN和cache hit-ratio降解的Alerta。
CI检查：图表/配对中的禁令"：最新"和hard-IP。

16）结论

Service Discovery是关于缓存名称和纪律的稳定约定。构建溷合模型：DNS提供快速、简便的输入,L7/mesh健康和智能策略。支持合理的TTL、节点缓存、无头部服务和SRV在需要时,使用GSLB/Anycast进行区域边界,留意NXDOMAIN/SERVFAIL和p99 resolve-time。然后你的名字和服务本身一样可靠。

Service Discovery и DNS