Service Discovery и DNS
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-ті қадағалаңыз. Сонда сіздің атыңыз қызметтің өзі сияқты сенімді актив болады.