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