Chương 22: Cloud DNS & Service Discovery
DNS failure là nguyên nhân phổ biến nhất gây outage trong hệ thống microservice — không phải vì DNS phức tạp, mà vì hầu hết engineer không hiểu đúng cơ chế resolution path bên trong Kubernetes. Một "connection refused" đơn giản có thể bắt nguồn từ ndots:5 lookup storm, CoreDNS conntrack exhaustion, hay NodeLocal DNSCache miss-forwarding.
Chương này đi từ cơ chế bên trong: kubelet cấu hình /etc/resolv.conf như thế nào, ndots:5 tạo ra bao nhiêu DNS query cho một tên đơn giản, CoreDNS xử lý plugin chain ra sao, và tại sao NodeLocal DNSCache không chỉ là "cache thêm một lớp nữa" mà còn giải quyết bài toán conntrack exhaustion ở kernel level.
Cấu Trúc Chương
chapter-22-cloud-dns-service-discovery/
├── index.md ← Trang này
├── 01.pod-dns-resolution-ndots.md ← /etc/resolv.conf, ndots:5, search domains, lookup storm
├── 02.coredns-gke-plugin-chain.md ← CoreDNS plugin chain, Corefile, GKE defaults
├── 03.kubernetes-dns-spec-service-discovery.md ← DNS spec: service.ns.svc.cluster.local, SRV records
├── 04.headless-externalname-services.md ← Headless (DNS per Pod), ExternalName (CNAME)
├── 05.nodelocal-dnscache.md ← DaemonSet, 169.254.20.10, cache, fallback, conntrack
├── 06.cloud-dns-for-gke.md ← Private zones, VPC scope, split-horizon, peering
└── 07.dns-debugging-performance.md ← nslookup/dig/CoreDNS logs, cache sizing, TTL tuningCác Chủ Đề
1. DNS Resolution trong Pod — /etc/resolv.conf, ndots:5, Search Domains
Kubelet viết gì vào /etc/resolv.conf, tại sao ndots:5 tạo ra tới 5 DNS queries cho một hostname ngắn, lookup path đầy đủ, negative caching và impact đến latency. Đây là foundation để hiểu mọi vấn đề DNS khác.
2. CoreDNS trong GKE — Plugin Chain và Behavior
Kiến trúc CoreDNS: plugin chain execution model, các plugin quan trọng (kubernetes, forward, cache, health, ready), Corefile mặc định trên GKE, cách CoreDNS phân loại query và forward đến đúng upstream.
3. Kubernetes DNS Spec — Service Discovery
Specification đầy đủ cho DNS records trong Kubernetes: A/AAAA records cho Services và Pods, SRV records, format <service>.<namespace>.svc.cluster.local, hostname và subdomain fields, dnsPolicy options.
4. Headless Services & ExternalName Services
Headless Services (clusterIP: None) trả về Pod IPs thay vì ClusterIP — cơ chế DNS per-Pod, tích hợp StatefulSet. ExternalName Services tạo CNAME thay vì A record. Hai loại Service này phá vỡ giả định "Service = virtual IP".
5. NodeLocal DNSCache — Kiến Trúc và Cơ Chế
DaemonSet chạy CoreDNS ở cache mode trên mỗi node, link-local IP 169.254.20.10, tại sao NodeLocal DNSCache giải quyết được conntrack exhaustion (không chỉ giảm latency), fallback mechanism, và cách GKE tích hợp với Cloud DNS.
6. Cloud DNS cho GKE — Private Zones và VPC Scope
Cloud DNS thay thế kube-dns trong GKE: private zones tự động quản lý, ba DNS scope (cluster/VPC/additive VPC), split-horizon DNS, peering zones cho hybrid connectivity. Tại sao VPC scope là quyết định không đổi lại được.
7. DNS Debugging & Performance Tuning
Workflow debug DNS từ trong Pod ra ngoài: nslookup, dig, CoreDNS metrics và logs. Performance tuning: cache sizing, negative TTL, ndots override, connection pooling. Playbook chẩn đoán DNS latency spike và NXDOMAIN storms.
Điều Kiện Tiên Quyết
- Chương 4: Cloud DNS Architecture — managed zones, private zones, forwarding zones
- Chương 7: GKE Networking Internals — iptables, conntrack, VPC-native
- Chương 5: GKE Control Plane — CoreDNS là system component được Google quản lý
Tại Sao Chương Này Quan Trọng
DNS failure thường không hiển thị rõ ràng. Symptom phổ biến:
- "connection refused" → thực ra DNS lookup timeout sau 30s, client hiểu nhầm là connection issue
- Latency spike định kỳ → ndots:5 tạo unnecessary search domain queries
- Pod restart loops → CoreDNS conntrack table exhaustion dưới load cao
- "Service không reach được cross-namespace" → thiếu FQDN, search domain không match
Hiểu cơ chế DNS resolution path từ Pod đến upstream resolver là kỹ năng bắt buộc để debug microservice connectivity issues trên GKE.