Service Discovery და DNS

Service Discovery და DNS

1) რატომ არის ეს აუცილებელი?

განაწილებულ სისტემებში კვანძები ჩნდება და ქრება, ხოლო მომხმარებლებმა უნდა იპოვონ მომსახურების სამუშაო ნიმუშები სწრაფად და საიმედოდ. DNS - სახელების უნივერსალური ფენა; მომსახურება discovery - რეალურ ენდოინტებთან მომსახურების სახელის შედარების სტრატეგია, ჯანმრთელობის, წონის და მარშრუტიზაციის პოლიტიკის გათვალისწინებით.

• სტაბილური სახელები ეფემერული მისამართების ნაცვლად,
• ზუსტი, მაგრამ არა ხმაურიანი განახლება (ბალანსი სიახლესა და TTL- ს შორის),
• დეგრადაცია სრული ვარდნის გარეშე,
• მინიმალური „დაშვება“ კლიენტზე: ტაიმაუტები, რეტრაები, ქეშის პოლიტიკა.

2) სერვისის მოდელები

2. 1 კლიენტი (client-side)

თავად კლიენტი საშუალებას აძლევს სახელს ენდოინების ნაკრები და დაბალანსდეს (გზის რობინი, EWMA, ჰაში). წყარო - DNS (A/AAA/SRV), მომსახურების რეესტრი (Consul/Eureka), სტატიკური სია.

დადებითი: ნაკლები ცენტრალური SPOF, მოქნილი ალგორითმები.
უარყოფითი მხარეები: მომხმარებელთა ჰეტეროგენულობა, ლოგიკის განახლება უფრო რთულია.

2. 2 სერვერი (სერვერის მხარე)

კლიენტი მიდის front/LB (L4/L7, gateway/ingress). დაბალანსება და ჯანმრთელობის შემოწმება მარიონეტული/დაბალანსების მხარეზეა.

დადებითი: პოლიტიკის ერთიანი ადგილი, დაკვირვება.
უარყოფითი მხარეები: თქვენ გჭირდებათ მაღალი ხელმისაწვდომი პერიმეტრი (N + 1, multi-AZ).

2. 3 ჰიბრიდი

DNS იძლევა შესასვლელი წერტილების ერთობლიობას (რეგიონალური LB), შემდეგ - დაბალანსებას L7/mesh- ზე.

3) DNS: საფუძვლები, ჩანაწერები და TTL

3. 1 ძირითადი ტიპები

A/AAAA - IPv4/IPv6 მისამართები.
CNAME - ალიასი სხვა სახელით (არა აპექსით).
SRV — `_service._proto. Name მასპინძელი/პორტი/წონა/პრიორიტეტი (gRPC/LDAP/SIP და ა.შ.).
TXT/HTTP/HTTPS - მეტამონაცემები/მაჩვენებლები (მათ შორის HTTP დისკისთვის).
NS/SOA - ზონის დელეგაცია და ატრიბუტები.

3. 2 TTL და ქეში კასკადი

ქეშს აქვს: OS რეზერვუარი, ადგილობრივი stub რეზერვუარი, კვანძები (NodeLOCal DNS/StoreDNS), პროვაიდერი, შუალედური რეკურსორები და ბიბლიოთეკის კლიენტი. ფაქტობრივი სიახლე = min (TTL, კლიენტის პოლიტიკა). ნეგატიური ქეში (NXDOMAIN) ასევე იშლება 'SOA- ს მიხედვით. MINIMUM`/`TTL`.

• Prod - TTL 30-120s დინამიური ჩანაწერებისთვის, 300-600s სტაბილური.
• გადართვისთვის (ფეილოვერი) წინასწარ მოამზადეთ შემცირებული TTL და არა „ხანძრის დროს“.
• გაითვალისწინეთ ბიბლიოთეკების sticky ქეში (Java/Go/Node) - საჭიროების შემთხვევაში, ჩამოაყალიბეთ TTL რეზერვუარი ranthim- ის შიგნით.

4) DNS დაბალანსებისა და წინააღმდეგობის პოლიტიკის პოლიტიკა

Wighted RR - წონა A/AAA/SRV.
Failover არის პირველადი/მეორადი ნაკრები.
Geo/Latency - პასუხი „უახლოეს“ ROP/რეგიონში.
Anycast - ერთი IP სხვადასხვა POP (BGP); მდგრადია რეგიონალური ჩავარდნების მიმართ.
Split-horizon არის სხვადასხვა პასუხები VPC/on-prem და ინტერნეტში.
GSLB არის გლობალური დაბალანსება, რომელსაც აქვს ჯანმრთელობის შემოწმებები და პოლიტიკები (latency, geo, capacity).

5) ჯანმრთელობის შემოწმებები და სიახლე

• ან გარე health-checker აკონტროლებს ჩანაწერებს/მასშტაბებს (GSLB, Route53/Traffic-policy, external-dns + ნიმუშები).
• ან კლიენტი/mesh აკეთებს აქტიურ outlier-ejection და retry მრავალი endpoint- დან.

6) Kubernetes: ყუთის დისკო

მომსახურების სახელები: 'svc. namespace. svc. cluster. local`.
ClusterIP: სტაბილური ვირტუალური IP + kube-proxy/ebpf.
Headless Service ('clusterIP: None'): აძლევს A- ჩანაწერებს pod's (ან მათი ქვე-დომენი), SRV პორტებისთვის.
EndpointSlice: Endpoints- ის მასშტაბური სია (Endpoints- ის ჩანაცვლება).
CoreDNS: DNS კასეტა რეზერვერი; lagines rewrite/template/forward/cache; 'kube-dn' ზონა.
NodeLocal DNSCache: კვანძზე ადგილობრივი ქეში უფრო ნაკლებია, ვიდრე ლატენტობა და გამაძლიერებელი რეზინის პრობლემების მოსაგვარებლად.

მაგალითი: 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

კლიენტს შეუძლია რეზინის '_ grpc. _ tcp. payments. prod. svc. cluster. ადგილობრივი '(SRV) და მიიღე მასპინძელი/პორტი/წონა.

ConfigMap (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
}

• DaemonSet ადგილობრივი რეზერვუარით '169. 254. 20. 10`; kubelet მიუთითებს ამ წერტილზე.
• ამცირებს p99 name-resolution და იცავს Apple-DNS- სგან.

7) Service discovery გარეთ K8s

კონსული: აგენტი, ჯანმრთელობის შემოწმებები, სერვისის კატალოგი, DNS ინტერფეისი ('.consul'), KV კონფისკაციისთვის.
Eureka/ZooKeeper/etcd: რეესტრები JVM/legacy; ხშირად sidecar/კარიბჭესთან ერთად.
Envoy/Istio: EDS/xDS (Endpoint Discovery) და SDS (საიდუმლოებები); სერვისები გამოცხადებულია საკონტროლო თვითმფრინავის საშუალებით.

8) DNS უსაფრთხოება

DNSSEC: ჩანაწერების მთლიანობის დაცვა (ზონების ხელმოწერა). კრიტიკულია საჯარო დომენებისთვის.
DoT/DoH: არხის დაშიფვრა რეკურსორისთვის (შიდა პოლიტიკა, თავსებადობა).
ACL და split-horizon: პირადი ზონა - მხოლოდ VPC/VPN- დან.
ქეშისგან მოწამვლისგან დაცვა: პორტების/ID რანდომიზაცია, მოკლე TTL დინამიკისთვის.
პოლიტიკები egress: დაუშვეთ DNS მხოლოდ სანდო რეზერვუარებზე, ჟურნალები.

9) მომხმარებელთა ქცევა

პატივს სცემთ TTL- ს: ნუ ქეშავთ უსასრულოდ, ნუ „არასწორად“ ხშირი რეზერვებით (ქარიშხალი რეკურსორის მიმართ).
ბედნიერი Eyeballs (IPv4/IPv6), პარალელური კონექტორები რამდენიმე A/AAAA- სთვის ამცირებს tail.
Retries მხოლოდ idempotent მოთხოვნით; ჯიტერი, budget რეაგირების შეზღუდვა.

• 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 გადართვა: პრაქტიკა

შეამცირეთ TTL 300-დან 60-მდე დაგეგმილი გადართვამდე 24-48 საათით ადრე.
შეინარჩუნეთ ენდოინტის კანარის ნაკრები, რომელსაც აქვს დაბალი წონა.
გამოიყენეთ შაბათ + ჯანმრთელი შემოწმება ხელით A- ჩანაწერების მასიური ადაპტაციის ნაცვლად.
სტატიკისთვის/edge - Anycast; API- სთვის - Geo/Latency + სწრაფი L7 ფეილოვერი.

11) სახელისთვის დაკვირვება და SLO

• DNS მოთხოვნების შეფასება/ანალიზი, cache hit-ratio, ტიპის შეცდომები (SERVFAIL/NXDOMAIN).
• მოთხოვნის წილი ფოლადის პასუხებით (თუ stale-cache იყენებთ).
• მომხმარებლის ოპერაციების წარმატება ჩანაწერების შეცვლაში (ბიზნეს SLI).
• p95/p99 resolve დრო პროგრამებში.

• დაგეგმეთ გზა: კლიენტი - ადგილობრივი ქეში - ღამის ქეში - კასეტური რეზოლვერი - პროვაიდერის რეკურსორი.
• თვალყური ადევნეთ NXDOMAIN (სახელების/ტიპების შეცდომები) და SERFAIL (რეკურსორის/რესურსის ლიმიტის პრობლემები).

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 (ადგილობრივი რეზინის ღერძი)

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

ენვოი: დინამიური DNS-refresh

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

external 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/სერვერის მხარე/ჰიბრიდი).
ძირითადი TTL, ჩართეთ NodeLocal DNSCache, DNS მეტრის დაშბორდები.
„მკაცრი IP“ - ის აკრძალვა კონფისკაციაში/კოდში.

8-20 დღე

Headless სერვისები + SRV gRPC- სთვის; EndpointSlice ჩართულია.
GSLB/ყოველკვირეული გარე; ჯანმრთელობის შემოწმებები და კანალიზაცია.
შედგენილია მომხმარებელთა ტაიმაუტები/რეტრაილები და რეკრეაციული ბიუჯეტი.

21-30 დღე

Split-horizon და პირადი ზონები; DoT/DoH პოლიტიკის შესახებ.
გადართვის ტესტი (TTL- ის მიხედვით) და ფეილოვერი; შემდგომი ანალიზი.
ჩართულია mesh/EDS პოლიტიკები, outlier-ejection.

14) ანტი შაბლონები

TTL = 0 გაყიდვაში - ქარიშხალი რეკურსორებისთვის, არაპროგნოზირებადი შეფერხებები.
IP/პორტების ჰარდკოდი, CNAME/ალიასის დონის არარსებობა.
ჩანაწერების „ხელით“ შეცვლა ჯანმრთელობის შემოწმებისა და კანარის გარეშე.
ერთი გლობალური რეზოლვერი კვანძებზე ქეშის გარეშე (ვიწრო ადგილი).
უარყოფითი ქეშის უგულებელყოფა (NXDOMAIN ადიდებული).
DNS- ის საშუალებით BD- ს უკმარისობის „მკურნალობის“ მცდელობები მონაცემთა დონის/ფეილოვერის ნაცვლად.

15) სიმწიფის მეტრიკა

სერვისების 100% იყენებს სახელებს; ნულოვანი შემთხვევები hard-IP.
MoreDNS/NodeLocal გაყიდვაში, cache hit-ratio> 90% კვანძებში.
GSLB ჯანმრთელობის შემოწმებებით, დოკუმენტირებული TTL და runbook გადართვა.
SRV/EndpointSlice stateful/grRPC, p99 resolve დრო აპლიკაციებში 20-30 ms.
Alerta of SERVFAIL/NXDOMAIN და cache hit-ratio დეგრადაცია.
შემოწმებები CI- ში: აკრძალვა ': latest' და hard IP ჩარტებში/კონფისკაციებში.

16) დასკვნა

Service discovery არის ქეშის სტაბილური სახელისა და დისციპლინის ხელშეკრულება. ააშენეთ ჰიბრიდული მოდელი: DNS იძლევა სწრაფ და მარტივ შესასვლელს, L7/mesh - ჯანმრთელობას და ჭკვიან პოლიტიკებს. შეინარჩუნეთ გონივრული TTL, კვანძების ქეში, headless სერვისები და SRV, სადაც საჭიროა, გამოიყენეთ GSLB/Anycast რეგიონების საზღვრებისთვის, დააკვირდით NXDOMAIN/SERVFAIL L L L- ს და PE E E ED DEEAD D D DD D D DDDEIEED D D D DEe შემდეგ თქვენი სახელი იქნება იგივე საიმედო აქტივი, როგორც თავად მომსახურება.