Service Discovery и DNS

Service Discovery и DNS

1) Warum es notwendig ist

In verteilten Systemen entstehen und verschwinden Knoten und Kunden müssen schnell und zuverlässig funktionierende Service-Instanzen finden. DNS - die universelle Schicht der Namen; service discovery - Eine Strategie zur Zuordnung des Dienstnamens zu realen Endpoints unter Berücksichtigung von Gesundheits-, Gewichts- und Routing-Richtlinien.

• stabile Namen statt ephemerer Adressen,
• genaue, aber nicht laute Aktualisierung (Balance zwischen Frische und TTL),
• Degradation ohne vollständigen Sturz (failover/health-check),
• minimales „Raten“ auf dem Client: Timeouts, Retrays, Cache-Richtlinien.

2) Service-Entdeckungsmodelle

2. 1 Client (Client-Seite)

Der Kunde selbst löst den Namen im Endpoint-Set auf und gleicht aus (round-robin, EWMA, Hash per Key). Quelle: DNS (A/AAAA/SRV), Dienstregister (Consul/Eureka), statische Liste.

Vorteile: weniger zentrale SPOFs, flexible Algorithmen.
Nachteile: Heterogenität der Kunden, es ist schwieriger, die Logik zu aktualisieren.

2. 2 Serverraum (Server-Seite)

Der Kunde geht zu front/LB (L4/L7, gateway/ingress). Balancing und Health-Checking sind auf der Seite des Proxy/Balancers.

Vorteile: einheitlicher Ort der Politik, Beobachtbarkeit.
Nachteile: Sie benötigen einen hochverfügbaren Perimeter (N + 1, multi-AZ).

2. 3 Hybrid

DNS gibt eine Reihe von Einstiegspunkten (regionale LBs), dann - Balancing auf L7/mesh.

3) DNS: Grundlagen, Einträge und TTL

3. 1 Grundtypen

A/AAAA - IPv4/IPv6 Adressen.
CNAME - Alias auf einem anderen Namen (nicht auf Apex).
SRV — `_service._proto. name' → Host/Port/Gewicht/Priorität (für gRPC/LDAP/SIP usw.).
TXT/HTTP/HTTPS - Metadaten/Pointer (inkl. HTTP-Discovery).
NS/SOA - Delegierung und Zonenattribute.

3. 2 TTL und Cache-Kaskade

Der Cache ist in: OS Resolver, Local Stub Resolver, Nodes (NodeLocal DNS/CoreDNS), Provider, Intermediate Recursors und im Library Client. Tatsächliche Frische = min (TTL, Kundenrichtlinie). Der negative Cache (NXDOMAIN) wird ebenfalls über 'SOA zwischengespeichert. MINIMUM`/`TTL`.

• Prod - TTL 30-120s für dynamische Aufnahmen, 300-600s für stabile Aufnahmen.
• Bei Schaltungen (Failover) vorher reduzierte TTL vorbereiten, nicht „im Brandfall“.
• Berücksichtigen Sie den Sticky-Cache der Bibliotheken (Java/Go/Node) - passen Sie bei Bedarf die TTL des Resolvers innerhalb des Rantymes an.

4) DNS-Ausgleichs- und Fehlertoleranzrichtlinien

Weighted RR - Gewichte auf A/AAAA/SRV.
Failover - primäre/sekundäre Kits (Health-Check von außen).
Geo/Latenz ist die Antwort auf die „nächste“ ROR/Region.
Anycast - eine IP in verschiedenen POPs (BGP); resistent gegen regionale Störungen.
Split-Horizon - unterschiedliche Antworten innerhalb des VPC/on-prem und im Internet.
Die GSLB ist ein globaler Bilanzierer mit Gesundheitschecks und Richtlinien (Latenz, Geo, Kapazität).

5) Gesundheitschecks und Frische

• Entweder verwaltet ein externer Health-Checker die Einträge/Gewichte (GSLB, Route53/Traffic-policy, external-dns + samples).
• Entweder Client/Mesh macht eine aktive Outlier-Ejection und Retry aus einer Vielzahl von Endpunkten.

6) Kubernetes: Entdeckung aus der Box

Service-Namen: 'svc. namespace. svc. cluster. local`.
ClusterIP: stabile virtuelle IP + kube-proxy/ebpf.
Headless Service ('clusterIP: None'): gibt A-Datensätze an Pod's (oder deren Subdomain), SRV für Ports.
EndpointSlice: Skalierbare Liste von Endpunkten (Ersatz von Endpunkten).
CoreDNS: DNS-Resolver des Clusters; plugins rewrite/template/forward/cache; 'kube-dns' zone.
NodeLocal DNSCache: Lokaler Cache auf dem Knoten → weniger Latenz und Abfangen von Upstream-Resolver-Problemen.

Beispiel: Headless + SRV

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

Der Client kann'_ grpc. _ tcp zurückrufen. payments. prod. svc. cluster. local'(SRV) und erhalten Host/Port/Gewichte.

CoreDNS (ConfigMap-Fragment)

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
}

• DaemonSet mit lokalem Resolver auf '169. 254. 20. 10`; kubelet gibt diesen Punkt an.
• Reduziert p99 name-resolution und schützt vor „flap“ upstream-DNS.

7) Service discovery вне K8s

Consul: Agent, Health-Checks, Service-Verzeichnis, DNS-Schnittstelle ('.consul'), KV für Config.
Eureka/ZooKeeper/etcd: Register für JVM/legacy; oft in Verbindung mit Sidecar/Gateway.
Envoy/Istio: EDS/xDS (Endpoint Discovery) und SDS (Secrets); Dienste werden über control-plane angekündigt.

8) DNS-Sicherheit

DNSSEC: Schutz der Integrität von Datensätzen (Zonensignatur). Kritisch für Public Domains.
DoT/DoH: Kanal-zu-Rekursor-Verschlüsselung (interne Richtlinien, Kompatibilität).
ACL und Split-Horizon: privater Bereich - nur von VPC/VPN.
Schutz vor Cache-Vergiftung: Port-Randomisierung/ID, kurze TTLs für Dynamik.
Richtlinien auf egress: DNS nur auf vertrauenswürdige Resolver zulassen, protokollieren.

9) Kundenverhalten und Retrays

Respektieren Sie TTL: Zwischenspeichern Sie nicht unbegrenzt, „zügeln“ Sie nicht durch häufige Resolve (Sturm auf den Rekursor).
Happy Eyeballs (IPv4/IPv6), parallele Anschlüsse zu mehreren A/AAAAs reduzieren das Tail.
Retrays nur bei idempotenten Anfragen; jitter, Beschränkung der Budget-Retrays.

• 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-Switching: Praxis

Senken Sie die TTL von 300→60 24 bis 48 Stunden vor dem geplanten Wechsel.
Halten Sie einen kanarischen Satz von Endpoints mit geringem Gewicht für die Validierung.
Wenden Sie weighted + health-check anstelle eines manuellen Massen-Updates von A-Einträgen an.
Für Statik/Kante - Anycast; für API - Geo/Latency + schneller L7-Failover.

11) Beobachtbarkeit und SLO für den Namen

• Rate/Latenz von DNS-Abfragen, Cache-Trefferverhältnis, Fehler nach Typ (SERVFAIL/NXDOMAIN).
• Anteil der Anfragen mit Stale-Antworten (bei Verwendung von Stale-Cache).
• Erfolg der Benutzeroperationen bei Datensatzwechsel (Business SLI).
• p95/p99 resolve-time in Anwendungen.

• Trennen Sie den Pfad: Der Client → den lokalen Cache → den Node-Cache → den Cluster-Resolver → den Rekursor des Anbieters.
• Überwachen Sie die Spitzen von NXDOMAIN (Namensfehler/Tippfehler) und SERVFAIL (Rekursorprobleme/Ressourcenlimits).

12) Beispiele für Konfigurationen

CoreDNS: rewrite und stub-zone

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 (Force of Local Resolver)

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

Envoy: dynamische DNS-Aktualisierung

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

External-DNS (Unterstützung öffentlicher Bereiche)

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

13) Checkliste Umsetzung (0-30 Tage)

0-7 Tage

Verzeichnis der Dienstnamen, Modellauswahl (client-/server-side/hybrid).
Basis-TTLs, NodeLocal DNSCache, DNS-Metrik Dashboards einschließen.
Verbot von "harten IPs' in Config/Code.

8-20 Tage

Headless-Dienste + SRV für gRPC; EndpointSlice ist aktiviert.
GSLB/gewichtet für extern; Gesundheitschecks und ein Kanarienvogel.
Kunden-Timeouts/Retrays und das Retrail-Budget sind eingerichtet.

21-30 Tage

Split-Horizon und private Bereiche; DoT/DoH zur Politik.
Schalt- (nach TTL) und Failover-Test; Post-Analyse.
Die Richtlinien mesh/EDS, outlier-ejection sind aktiviert.

14) Anti-Muster

TTL = 0 in der Produktion → Sturm auf Rekursor, unvorhersehbare Verzögerungen.
IP/Port-Hardcode, keine CNAME/Aliasse für Ebenen.
Änderung der Einträge „manuell“ ohne Gesundheitschecks und Kanarienvögel.
Ein globaler Resolver ohne Cache auf Knoten (Engpass).
Ignorieren Sie den negativen Cache (NXDOMAIN-Bursts).
Versuche, DB-Fehler über DNS anstelle der Daten-/Failover-Schicht zu „behandeln“.

15) Reifegradkennzahlen

100% der Dienste verwenden Namen; null Hard-IP-Fälle.
CoreDNS/NodeLocal in der Produktion, Cache-Trefferverhältnis> 90% auf den Knoten.
GSLB mit Health-Checks, TTL-dokumentierten und Runbook-Schaltungen.
SRV/EndpointSlice für stateful/gRPC, p99 resolve-time in Anwendungen ≤ 20-30 ms.
Alerts durch SERVFAIL/NXDOMAIN und Cache-Hit-Ratio-Degradation.
Checks in CI: Ban': latest 'und Hard-IP in den Charts/Config.

16) Schlussfolgerung

Service Discovery ist ein stabiler Namensvertrag und eine Cache-Disziplin. Bauen Sie ein Hybridmodell auf: DNS bietet einen schnellen und einfachen Einstieg, L7/mesh Gesundheit und intelligente Richtlinien. Unterstützen Sie vernünftige TTLs, Node-on-Cache, Headless-Dienste und SRVs, wo Sie müssen, verwenden Sie GSLB/Anycast für Regionsgrenzen, achten Sie auf NXDOMAIN/SERVFAIL und p99 resolve-time. Dann wird Ihr Name so zuverlässig sein wie der Service selbst.