サービスディスカバリーDNS

1）なぜそれを必要とします

分散システムでは、ノードが表示されたり消えたりするため、顧客はサービスの作業インスタンスを迅速かつ確実に見つける必要があります。DNS-ユニバーサルネームレイヤー；サービスディスカバリ-健康、重量、ルーティングポリシーを考慮して、サービス名を実際のエンドポイントと一致させるための戦略。

主な目的：

一時的なアドレスの代わりに安定した名前、
正確ではあるが騒々しい更新（新鮮さとTTLの間のバランス）、
完全な落下なしの劣化（フェイルオーバー/ヘルスチェック）、
クライアントの最小「推測」：タイムアウト、リトレイ、キャッシュポリシー。

2）サービスディスカバリーモデル

2.1クライアント側

クライアント自身が名前を一連のエンドポイントとバランス（ラウンドロビン、EWMA、キーによるハッシュ）に解決します。ソース-DNS （A/AAAA/SRV）、サービスレジストリ（領事/Eureka）、静的リスト。

長所：より少ない中央SPOF、柔軟なアルゴリズム。
短所：顧客の異種性、ロジックを更新することはより困難です。

2.2サーバー（サーバーサイド）

クライアントはfront/LB （L4/L7 gateway/ingress）に移動します。バランシングと健康チェック-プロキシ/バランサー側。

長所：政治の単一の場所、観測可能性。
短所：高可用性の周囲（N+1、マルチAZ）が必要です。

2.3ハイブリッド

DNSはエントリポイント（地域LB）のセットを与え、バランシングをL7/meshします。

3） DNS： 基本、レコード、TTL

3.1基本的なタイプ

A/AAAA-IPv4/IPv6アドレス。
CNAME-別名のエイリアス（頂点ではありません）。

SRV-'_service。_proto。name'→host/port/weight/priority （gRPC/LDAP/SIPなど）

TXT/HTTP/HTTPS-メタデータ/ポインタ（HTTP-discoveryを含む）。
NS/SOA-ゾーンの委任と属性。

3.2 TTLとキャッシュ

キャッシュは、OS resolver、 local stub resolver、 node （NodeLocal DNS/CoreDNS）、 provider、 intermediate recurser、 library clientから利用できます。実際の鮮度=min （TTL、クライアントポリシー）。ネガティブキャッシュ（NXDOMAIN）も'SOA。MINIMUM'/'TTL'。

推奨事項：

Prod-動的記録のためのTTL 30-120s、安定したのための300-600s。
スイッチ（feilover）については「、火災中」ではなく、事前に下げられたTTLを準備してください。
ライブラリのスティッキーキャッシュ（Java/Go/Node）を考慮してください。必要に応じて、ランタイム内でリゾルバのTTLを設定します。

4） DNSバランシングとフォールトトレランスポリシー

加重されたRR-A/AAAA/SRVの重量。
フェイルオーバー-プライマリ/セカンダリ・セット（外部のヘルスチェック）。
Geo/Latency-「最寄りの」POP/regionへの応答。
Anycast-異なるPOP （BGP）の1つのIP；地域の混乱に抵抗力があります。
Split-horizon-VPC/on-prem内とインターネット上で異なる回答。
GSLBは、ヘルスチェックとポリシー（レイテンシ、地理、容量）を備えたグローバルバランサーです。

5）健康チェックと鮮度

DNS自体は「ダム」であり、バックエンドの健全性を知らない。したがって、：

または、外部ヘルスチェッカーがレコード/ウェイト（GSLB、 Route53/Traffic-policy、外部dns+サンプル）を管理します。
または、/meshクライアントはアクティブなアウトリアイジェクションを行い、多くのエンドポイントから再試行します。

6） Kubernetes： 箱から発見

サービス名： 'svc。名前空間。SVCだ。クラスタです。「ローカル」

ClusterIP：安定した仮想IP+kube-proxy/ebpf。
Headless Service （'clusterIP： None'）：ポッド（またはそのサブドメイン）にAレコードを、ポートにSRVを与えます。
EndpointSlice：拡張可能なエンドポイントのリスト（Endpointの置き換え）。
CoreDNS：クラスタDNSリゾルバ；プラグインは/template/forward/cacheを書き換えます。"kube-dns'ゾーン。
NodeLocal DNSCache：ノード上のローカルキャッシュ→アップストリームリゾルバの問題のレイテンシと傍受の減少。

例：ヘッドレス+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を解決できます。支払い。PROD。SVCだ。クラスタです。local '（SRV）とhost/port/weightsを取得します。

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の名前解像度を低減し、アップストリームのDNSフラップから保護します。

7）サービスディスカバリービジネスK8s

Consul：エージェント、ヘルスチェック、サービスディレクトリ、DNSインターフェイス（'consul'）、 KV for configs。
Eureka/ZooKeeper/etcd： JVM/legacyのレジストリ。多くの場合、サイドカー/ゲートウェイと一緒に。
Envoy/Istio： EDS/xDS （Endpoint Discovery）とSDS （Secrets）；サービスはcontrol-planeを介して宣言されます。

8） DNSセキュリティ

DNSSEC：レコードの整合性（ゾーン署名）を保護します。パブリックドメインにとって重要です。
DoT/DoH：再帰暗号化へのチャネル（内部ポリシー、互換性）。
ACLとsplit-horizon：プライベートゾーン-VPC/VPNからのみ。
キャッシュ中毒に対する保護：ポート/IDランダム化、ダイナミクス用の短いTTL。
egressのポリシー：信頼できるリゾルバでのみDNSを許可し、ログを記録します。

9）顧客および後退の行動

TTLを尊重する：無限にキャッシュしないでください、頻繁な解像度で「無法」しないでください（再帰への嵐）。
Happy Eyeball （IPv4/IPv6）、複数のA/AAAAへの並列接続により、テールが減少します。
idempotentリクエストのみトレイ；ジッタ、予算のレトレイを制限します。

ランタイムリゾルバの微調整：

Java： 'networkaddress。キャッシュ。ttl'、'networkaddress。キャッシュ。否定的です。ttl'。
Go： 'GODEBUG=netdns=go'/'cgo'、 'Resolver。PreferGo'、'DialTimeout'。
ノード：'dns。setDefaultResultOrder （'ipv4first'）'、'lookup'-'all： true'。

10） GSLB/DNSスイッチング： 練習

スケジュールされたスイッチオーバーの前に、300→60 24-48時間からTTLを下げます。
検証のための低重量エンドポイントのカナリアセットを保持します。
Aレコードのマスアップデートを手動で行うのではなく、weighted+health-checkを使用します。
静的/エッジの場合-Anycast；API-Geo/Latency+高速L7-feiler。

11）名前のための観察可能性そしてSLO

メトリクス：

DNSクエリのレート/レイテンシ、キャッシュのヒット比、タイプ別エラー（SERVFAIL/NXDOMAIN）。
古いレスポンスを持つリクエストの割合（stale-cacheを使用している場合）。
記録変更（ビジネスSLI）に関するユーザー操作の成功。
アプリケーションでのp95/p99の解決時間。

Diagnostics：

パスを層別化：client→local cache→nodal cache→cluster resolver→provider recursion。
NXDOMAIN（名前/タイプエラー）とSERVFAIL（再帰問題/リソース制限）のスパイクを追跡します。

12）構成例

CoreDNS： 書き換えとスタブゾーン

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リフレッシュ

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/hybrid）。
基本的なTTL、 NodeLocal DNSCache、 DNSメトリックダッシュボードを有効にします。
config/codeの「hard IP」を禁止します。

8-20日

ヘッドレスサービス+gRPC用SRV；EndpointSliceが有効になっています。
外的のために重くされるGSLB/；健康チェックとカナリア。
クライアントのタイムアウト/リトレイとリトレイの予算が設定されます。

21-30日

分割地平線とプライベートエリア；ポリシーによるDoT/DoH。
切換えテスト（TTLによって）およびfeilover；ポスト分析。
Mesh/EDS、 outlier-ejectionポリシーが有効になります。

14）アンチパターン

TTL=0 prod→stormで再帰し、予測不可能な遅延。
IP/ポートハードコード、レベルのCNAME/エイリアスはありません。
ヘルスチェックやカナリアなしでレコードを「手動で」変更します。
ノードキャッシュ（ボトルネック）を持たない1つのグローバルリゾルバ。
負のキャッシュ（NXDOMAINスパイク）を無視します。
データ/feiloverレイヤーの代わりにDNS経由でデータベース障害を「修復」しようとします。

15）成熟度の指標

サービスの100％は名前を使用します。ゼロのハードIPケース。
CoreDNS/NodeLocal売上高では、キャッシュのヒット率はノードで90％を超えます。
ヘルスチェック、文書化されたTTLおよびランブックスイッチを備えたGSLB。
ステートフル/gRPC用のSRV/EndpointSlice、 20-30 ms ≤アプリケーションでのp99分解時間。
SERVFAIL/NXDOMAINとキャッシュのヒット比の低下に対するアラート。
Checks in CI： ban'：latest'とhard-IP in charts/configs。

16）結論

サービスディスカバリは、安定したネームコントラクトとキャッシュ規律です。ハイブリッドモデルを構築する：DNSは迅速かつ簡単にログイン、L7/mesh-健康とスマートポリシーを提供します。必要に応じてスマートTTL、ホストキャッシュ、ヘッドレスサービス、SRVを維持し、地域の境界にGSLB/Anycastを使用し、NXDOMAIN/SERVFAILとp99の解決時間を監視します。その後、あなたの名前はサービス自体と同じくらい信頼できる資産になります。

サービスディスカバリーDNS