Service Discovery және DNS

1) Бұл не үшін қажет

Бөлінген жүйелерде тораптар пайда болады және жоғалады, ал клиенттер сервистің жұмыс үлгілерін тез және сенімді табуы тиіс. DNS - атаулардың әмбебап қабаты; service discovery - денсаулық, салмақ және бағыттау саясатын ескере отырып, сервис атауын нақты эндпойнттарға салыстыру стратегиясы.

Негізгі мақсаттар:

эфемерлік мекенжайлардың орнына тұрақты атаулар,
дәл, бірақ шулы емес апдейт (жаңалық пен TTL арасындағы теңгерім),
толық құлдыраусыз тозу (failover/health-check),
клиентке ең аз «болжам»: таймауттар, ретраилер, кэш-саясат.

2) service discovery модельдері

2. 1 Клиенттік (client-side)

Клиенттің өзі атауды эндпойнттар жиынтығына рұқсат етеді және теңгерімдейді (round-robin, EWMA, кілт бойынша хеш). Дереккөз - DNS (A/AAAA/SRV), сервис-тізілім (Consul/Eureka), статикалық тізім.

Артықшылықтары: орталық SPOF аз, икемді алгоритмдер.
Кемшіліктері: клиенттердің біртекті еместігі, логиканы жаңарту қиынырақ.

2. 2 Серверлік (server-side)

Клиент front/LB-ге барады (L4/L7, gateway/ingress). Теңгерім және health-checking - прокси/теңгеруші жағында.

Артықшылықтары: саясаттың бірыңғай орны, бақылау.
Кемшіліктері: қол жетімділігі жоғары периметр (N + 1, multi-AZ) қажет.

2. 3 Гибрид

DNS кіру нүктелерінің жиынтығын (аймақтық LB) береді, одан әрі - L7/mesh теңгерім.

3) DNS: негіздері, жазбалары және TTL

3. 1 Негізгі түрлері

A/AAAA - IPv4/IPv6 мекенжайлар.
CNAME - басқа атаудағы алиас (apex емес).
SRV — `_service._proto. name '→ хост/порт/салмақ/артықшылық (gRPC/LDAP/SIP және т.б.).
TXT/HTTP/HTTPS - метадеректер/көрсеткіштер (соның ішінде HTTP-discovery үшін).
NS/SOA - жіберу және аймақ төлсипаттары.

3. 2 TTL және кэш-каскад

Кэш бар: ОС резолвері, жергілікті stub-резолвері, тораптар (NodeLocal DNS/CoreDNS), провайдер, аралық рекурсорлар және кітапхана клиентінде. Нақты жаңалық = min (TTL, клиенттің саясаты). Теріс кэш (NXDOMAIN) де 'SOA бойынша кэшеленеді. MINIMUM`/`TTL`.

Ұсынымдар:

Прод - динамикалық жазбалар үшін TTL 30-120s, тұрақты үшін 300-600s.
Қайта қосу үшін (фейловер) «өрт кезінде» емес, алдын ала төмендетілген TTL дайындаңыз.
Sticky-кэшін (Java/Go/Node) ескеріңіз - қажет болған жағдайда рантайм ішіндегі TTL кескінін теңшеңіз.

4) DNS-теңгерім және істен шығуға төзімділік саясаты

Weighted RR - A/AAAA/SRV салмағы.
Failover - бірінші/екінші жиынтық (сыртынан health-check).
Geo/Latency - «жақын» РОР/өңірге жауап.
Anycast - әр түрлі POP (BGP) бір IP; өңірлік іркілістерге төзімді.
Split-horizon - VPC/он-прем ішіндегі және интернеттегі әртүрлі жауаптар.
GSLB - health-тексерулері және саясаты бар жаһандық теңгерімдеуші (latency, гео, capacity).

5) Health-checks және жаңалық

DNS өзі «ақымақ»: ол бэкендтердің денсаулығын білмейді. Сондықтан:

Немесе сыртқы health-checker жазбаларды/таразыларды басқарады (GSLB, Route53/Traffic-policy, external-dns + сынамалар).
Немесе клиент/mesh көптеген эндпойндардан белсенді outlier-ejection және retry жасайды.

6) Kubernetes: қораптан discovery

Сервистік атаулар: 'svc. namespace. svc. cluster. local`.
ClusterIP: тұрақты виртуалды IP + kube-proxy/ebpf.
Headless Service ('clusterIP: None'): A жазбаларын pod's (немесе олардың астыңғы доменінде), порттар үшін SRV береді.
EndpointSlice: Эндпойнттардың масштабталатын тізімі (Endpoints алмастыру).
CoreDNS: кластердің DNS резолвері; rewrite/template/forward/cache плагиндері; 'kube-dns' аймағы.
NodeLocal DNSCache: тораптағы жергілікті кэш → аз latency және апстрим-резолвер проблемаларын ұстап алу.

Мысал: 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. local '(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 name-resolution дегенді азайтады және apstrim-DNS «флапынан» қорғайды.

7) Service discovery сыртында K8s

Consul: агент, health-checks, қызмет каталогы, DNS интерфейсі ('.consul'), конфигурацияларға арналған KV.
Eureka/ZooKeeper/etcd: JVM/legacy үшін тізілімдер; жиі sidecar/шлюз байланысында.
Envoy/Istio: EDS/xDS (Endpoint Discovery) және SDS (құпиялар); сервистер control-plane арқылы жарияланады.

8) DNS қауіпсіздігі

DNSSEC: жазбалардың тұтастығын қорғау (аймақ қолтаңбасы). Көпшілік домендер үшін сыни.
DoT/DoH: рекурсорға арнаны шифрлау (ішкі саясат, үйлесімділік).
ACL және split-horizon: жеке аймақ - тек VPC/VPN-тен.
Кэш-уланудан қорғау: порттарды/ID рандомизациялау, динамика үшін қысқа TTL.
egress саясаты: DNS тек сенімді қарауыштарға рұқсат етіңіз, журналдаңыз.

9) Клиенттердің мінез-құлқы және ретра

TTL-ді құрметтеңіз: шексіз кэштемеңіз, жиілікпен «шектемеңіз» (рекурсорға дауыл).
Happy Eyeballs (IPv4/IPv6), бірнеше A/AAAA параллель коннектілер tail азайтады.
Ретраялар тек идемпотенттік сұраулар кезінде ғана; джиттер, ретрайлардың 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-ді жоспарлы ауыстырып қосудан 24-48 сағат бұрын 300 → 60-тан төмендетіңіз.
Валидация үшін аз салмақты эндпойнттардың канареялық жиынтығын ұстаңыз.
Қолмен жазылған А жазбасының орнына weighted + health-check қолданыңыз.
Статика үшін/edge - Anycast; API үшін - Geo/Latency + жылдам L7-фейловер.

11) Атау үшін бақылау және SLO

Өлшемдері:

Rate/latency DNS-сұраулар, cache hit-ratio, түрлері бойынша қателер (SERVFAIL/NXDOMAIN).
Stale-жауаптары бар сұраулардың үлесі (егер stale-cache пайдалансаңыз).
Жазбаларды ауыстыру кезінде пайдаланушы әрекеттерінің табысы (бизнес-SLI).
p95/p99 resolve-time бағдарламаларында.

Диагностика:

Жолды бөліңіз: клиент → жергілікті кэш → нод кэш → кластерлік резолвер → провайдер рекурсоры.
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 (жергілікті резолвердің форсы)

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

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-/server-side/гибрид).
Негізгі TTL, NodeLocal DNSCache, DNS-метрикалық дашбордтарды қосыңыз.
Конфига/кодта «қатты IP» дегенге тыйым салу.

8-20 күн

gRPC үшін Headless-сервистер + SRV; EndpointSlice қосылған.
GSLB/weighted сыртқы үшін; health-checks және канарейка.
Клиенттердің таймауттары/ретрайлары және ретрайлардың бюджеті теңшелген.

21-30 күн

Split-horizon және жеке аймақтар; Саясат бойынша DoT/DoH.
Ауыстырып қосу тесті (TTL бойынша) және фейловер; пост-талдау.
mesh/EDS, outlier-ejection саясаты қосылған.

14) Қарсы үлгілер

Рекурсорларға TTL = 0 прод → дауыл, болжанбайтын кідірістер.
IP/порттардың хардкоды, деңгейлер үшін CNAME/алиастардың болмауы.
Жазуларды health-checks және канарейкаларсыз «қолмен» ауыстыру.
Түйіндердегі кэшсіз бір жаһандық резолвер (тар орын).
Теріс кэшті елемеу (NXDOMAIN жарқылдауы).
Деректер/фейловер деңгейінің орнына DNS арқылы ДБ істен шығуын «емдеу» әрекеттері.

15) Жетілу метрикасы

Сервистердің 100% аттарын пайдаланады; нөлдік жағдайлар hard-IP.
CoreDNS/NodeLocal өнімде, cache hit-ratio> 90% түйіндерде.
TTL және runbook ауыстырып-қосу құжатталған health-checks бар GSLB.
SRV/EndpointSlice stateful/gRPC үшін, p99 resolve-time қосымшаларда ≤ 20-30 мс.
SERVFAIL/NXDOMAIN және cache hit-ratio деградациясы бойынша алерталар.
CI тексерулері: тыйым салу ': latest' және хит/конфигурациялардағы hard-IP.

16) Қорытынды

Service discovery - бұл тұрақты ат және кэш тәртібі туралы шарт. Гибридті модельді жасаңыз: DNS жылдам және қарапайым кіріс береді, L7/mesh - денсаулық және ақылды саясаткерлер. Ақылға қонымды TTL-ді, тораптағы кэшті, headless-сервистерді және қажет жерде SRV-ді қолдаңыз, аймақтардың шекаралары үшін GSLB/Anycast-ті пайдаланыңыз, NXDOMAIN/SERVFAIL және p99 resolve-time-ті қадағалаңыз. Сонда сіздің атыңыз қызметтің өзі сияқты сенімді актив болады.

Service Discovery және DNS