My Awesome Project

Appearance

Cloud DNS cho GKE — Private Zones, VPC Scope, và Split-Horizon ​

Tại Sao GKE Cần Cloud DNS ​

kube-dns và CoreDNS giải quyết tốt DNS trong phạm vi cluster. Nhưng enterprise production systems có nhu cầu phức tạp hơn:

  • Non-GKE clients trong VPC (GCE VMs, Cloud Run, on-premises via VPN) cần resolve cluster Service names
  • Multi-cluster environments cần DNS nhất quán giữa các clusters
  • Hybrid cloud với on-premises DNS servers cần peering với cluster DNS
  • Split-horizon DNS — same domain, different answers cho internal vs external clients

CoreDNS giải quyết những bài toán này không tốt vì nó chỉ lắng nghe trong cluster network. Cloud DNS for GKE đưa cluster DNS lên managed DNS infrastructure của Google, cho phép resolve từ bất kỳ đâu trong VPC.

Internal Model — Cloud DNS for GKE ​

Kiến Trúc Tổng Thể ​

Khi cluster được tạo với Cloud DNS for GKE (thay vì kube-dns default):

  1. GKE control plane tạo một Cloud DNS private zone được quản lý tự động cho cluster
  2. Zone này chứa DNS records cho tất cả Services và Pods trong cluster
  3. GKE controller liên tục sync Kubernetes Service/Endpoint state sang Cloud DNS zone
  4. Metadata server (169.254.169.254) trên mỗi node được cấu hình để serve DNS từ Cloud DNS
  5. Pod DNS queries đến 169.254.169.254:53 (hoặc 169.254.20.10:53 nếu NodeLocal DNSCache enabled) được routed đến Cloud DNS infrastructure

Điểm khác biệt căn bản: DNS records không sống trong cluster (như CoreDNS in-memory cache) mà sống trong Cloud DNS infrastructure của Google — globally distributed, SLA-backed, và reachable từ toàn VPC.

Automatic Zone Management ​

GKE controller tự động manage Cloud DNS zone:

  • Service được tạo → A record được thêm vào private zone
  • Service bị xóa → A record bị xóa
  • Pod IP thay đổi (với headless Services) → A records được update
  • Cluster bị xóa → Zone bị xóa

Không nên manual edit zone records — GKE controller sẽ overwrite. Đây là managed zone trong đúng nghĩa.

Cấu Trúc Zone Name ​

Zone tự động tạo cho cluster có naming convention:

gke-<cluster-name>-<hash>-dns

Zone này private — chỉ visible trong VPC (hoặc VPCs nếu cấu hình). Zone scope và visibility phụ thuộc vào DNS scope được chọn khi tạo cluster.

DNS Scope — Ba Chế Độ Hoạt Động ​

Đây là quyết định quan trọng nhất khi deploy Cloud DNS for GKE và không thể thay đổi sau khi cluster được tạo. Phải chọn đúng từ đầu.

Cluster Scope (mặc định) ​

DNS records chỉ resolvable từ nodes trong cluster

Behavior giống kube-dns: payment-service.backend.svc.cluster.local chỉ resolve được từ Pods trong cluster. External clients (GCE VMs, on-prem) không thể resolve tên này.

Dùng khi: Cluster là isolated unit, không cần external clients resolve cluster Services.

VPC Scope ​

DNS records resolvable từ toàn bộ VPC (và on-premises nếu có VPN/Interconnect)

VPC scope là thay đổi lớn: Cloud DNS private zone được gắn với toàn bộ VPC network, không chỉ với nodes của cluster. Bất kỳ client nào trong VPC — GCE VM, Cloud Run, on-premises server qua Cloud Interconnect — có thể resolve payment-service.backend.svc.cluster.local và nhận ClusterIP.

Theo tài liệu GCP: "With VPC scope, a cluster's DNS names are resolvable within the entire VPC. Any client in the VPC can resolve cluster DNS records."

Tại sao cần VPC scope:

  • Service Mesh patterns: data plane (Envoy) trên VMs cần discover in-cluster endpoints
  • Migration scenarios: applications trên GCE VMs cần reach Kubernetes services trước khi migration hoàn tất
  • Monitoring/management tools trên non-GKE nodes cần discover cluster services

Giới hạn VPC scope: Headless Service chỉ trả về Pod IPs (không phải ClusterIP) khi query từ VPC. External clients nhận Pod IPs nhưng traffic đến Pod IPs chỉ work nếu network routing được configure đúng (VPC-native clusters, Pod CIDR routable từ caller's subnet).

Additive VPC Scope ​

Kết hợp cluster scope + VPC scope: cluster DNS resolvable từ VPC,
đồng thời cluster vẫn có isolated cluster.local namespace

Additive VPC scope là phiên bản linh hoạt hơn: cluster DNS có thể resolve từ VPC nhưng cluster-local queries ưu tiên cluster zone (không bị conflate với các clusters khác trong VPC).

Dùng khi: Multiple clusters trong cùng VPC, muốn cross-cluster resolution nhưng tránh namespace conflicts.

Split-Horizon DNS ​

Cơ Chế ​

Split-horizon DNS cho phép cùng một domain name trả về khác nhau cho internal vs external clients:

example.com (từ internet) → 203.0.113.100 (Public IP / Load Balancer)
example.com (từ trong VPC) → 10.0.1.50 (Internal IP / Private endpoint)

Với Cloud DNS, split-horizon được implement bằng:

  1. Public zone example.com: trả về public IP cho external queries
  2. Private zone example.com: override public zone cho queries từ trong VPC

Private zone được bind với VPC network. Khi GCP DNS resolver nhận query từ trong VPC, nó ưu tiên private zone over public zone.

Use Cases Trong GKE Context ​

Scenario 1: Internal API không expose ra internet

api.company.com:
  - Public zone: không có record (domain không resolvable externally)
  - Private zone: 10.0.2.100 (ILB cho GKE Service)

Clients từ internet không resolve được api.company.com. Clients trong VPC resolve được và kết nối qua Internal Load Balancer.

Scenario 2: Dual endpoint cho internal efficiency

storage.company.com:
  - Public zone: 203.0.113.200 (Cloud Storage public endpoint)
  - Private zone: 199.36.153.4 (Private Google Access endpoint)

Applications trong VPC tự động kết nối qua Private Google Access (không ra internet), trong khi external clients dùng public endpoint. Zero code change cần thiết.

Private Zone Binding ​

Để private zone có hiệu lực cho queries trong VPC, zone phải được bind với VPC network:

bash
gcloud dns managed-zones create internal-zone \
    --dns-name="example.com" \
    --visibility="private" \
    --networks="projects/MY_PROJECT/global/networks/my-vpc"

Cloud DNS private zone chỉ responds với queries đến từ resources trong VPC network được chỉ định.

Peering Zones — Hybrid DNS Integration ​

Vấn Đề Hybrid DNS ​

Trong enterprise, on-premises DNS servers quản lý internal domains (corp.internal, prod.corp). GKE cluster cần resolve các tên này. Đồng thời, on-premises clients cần resolve tên trong cluster DNS scope.

Cấu hình forwarding đơn giản từ CoreDNS đến on-premises DNS server không bidirectional — on-premises clients vẫn không biết cluster DNS zone.

DNS Peering Zones ​

Cloud DNS peering cho phép một zone forward queries đến zone khác:

Project A (GKE cluster): private zone gke-cluster-a.cluster.local
Project B (Shared DNS): authoritative zone cho corp.internal

Peering: Project A → cho phép resolve corp.internal từ Project B's zone
bash
# Tạo peering zone trong project GKE
gcloud dns managed-zones create peering-to-shared-dns \
    --dns-name="corp.internal" \
    --visibility="private" \
    --networks="projects/gke-project/global/networks/gke-vpc" \
    --target-network="projects/shared-dns-project/global/networks/dns-hub-vpc" \
    --target-project="shared-dns-project"

Query cho server.corp.internal từ GKE Pod → Cloud DNS peering zone → forward đến shared DNS project → resolve từ authoritative zone.

Hub-Spoke DNS Architecture ​

Pattern phổ biến trong enterprise với nhiều VPCs:

DNS Hub VPC (Project: dns-hub):
├── Authoritative zones cho corp.internal, prod.corp, etc.
├── Forwarding zones đến on-premises DNS servers
└── Peering connections từ spoke VPCs

Spoke VPCs (Projects: gke-prod, gke-staging, gke-dev):
└── Peering zones trỏ về DNS Hub VPC

Mọi DNS resolution đi qua Hub. Cluster DNS zones (scope VPC) được visible trong spoke VPC và có thể peered về Hub nếu cần on-premises clients access.

Constraints Và Giới Hạn Quan Trọng ​

Không Thể Thay Đổi DNS Scope Sau Khi Tạo Cluster ​

Đây là giới hạn quan trọng nhất. DNS scope (cluster/VPC/additive-VPC) được set khi gcloud container clusters create và không thể modify sau đó. Nếu cần thay đổi scope, phải tạo cluster mới và migrate workloads.

Implication: Cần quyết định DNS scope ngay từ đầu dựa trên expected use cases. Với production clusters, VPC scope hoặc additive VPC scope thường được ưu tiên vì flexibility.

Manual Zone Modifications Bị Overwrite ​

Mọi record được thêm thủ công vào Cloud DNS zone của GKE sẽ bị overwrite hoặc xóa bởi GKE controller khi nó reconcile state. Không nên dùng GKE-managed zone cho custom records.

Giải pháp: Tạo zone riêng cho custom records, đặt cùng VPC binding. Cloud DNS sẽ resolve từ cả hai zones (GKE-managed và custom).

Headless Services Và VPC Scope Limitation ​

Với VPC scope, headless Service A records trong Cloud DNS chỉ chứa Pod IPs (không phải danh sách IPs khi query từ cluster). External clients nhận Pod IPs nhưng để kết nối được, Pod CIDR phải routable từ caller.

Trên GKE VPC-native clusters, Pod CIDR là VPC IP range — routable trong VPC. Nhưng với non-VPC-native hoặc external clients qua VPN, cần verify routing.

Service Và Port Name Length Limit ​

Cloud DNS for GKE giới hạn Service name và port name tối đa 62 ký tự. Services với tên dài hơn có thể không có SRV records được tạo đúng.

DNS Latency So Với kube-dns ​

Cloud DNS infrastructure adds overhead so với in-cluster CoreDNS:

  • kube-dns: Sub-millisecond resolution (in-memory lookup)
  • Cloud DNS: 1-5ms thêm cho metadata server round-trip

Với NodeLocal DNSCache, cache hits vẫn sub-millisecond. Cache misses chịu thêm latency từ Cloud DNS. Đối với applications sensitive về DNS latency, NodeLocal DNSCache là prerequisite.

Khi Nào Dùng Cloud DNS for GKE vs kube-dns ​

Tiêu chíkube-dns/CoreDNSCloud DNS for GKE
Multi-cluster DNSKhó implementNative với VPC scope
Hybrid DNS integrationManual forwarding configPeering zones
Non-GKE client accessKhông hỗ trợVPC scope
Split-horizon DNSCustom CoreDNS configNative Cloud DNS
DNS query latencyTốt hơn (in-memory)Acceptable với NodeLocal Cache
Operational overheadQuản lý CoreDNS configFully managed
CostIncludedCloud DNS pricing per zone/query

Với production GKE clusters trong enterprise environment, Cloud DNS for GKE thường là lựa chọn đúng vì operational benefits vượt trội over marginal latency difference (khi có NodeLocal DNSCache).

GKE-Specific Configuration ​

bash
# Tạo cluster với Cloud DNS
gcloud container clusters create my-cluster \
    --location=us-central1 \
    --cluster-dns=clouddns \
    --cluster-dns-scope=vpc \
    --cluster-dns-domain=cluster.local

# Verify Cloud DNS zone được tạo
gcloud dns managed-zones list --filter="name:gke-*"

# Inspect zone records
gcloud dns record-sets list \
    --zone=gke-my-cluster-hash-dns \
    --filter="name:*.svc.cluster.local"

# Test resolution từ VM trong cùng VPC
gcloud compute ssh vm-in-vpc -- \
    "nslookup payment-service.backend.svc.cluster.local"

# Thêm custom peering zone
gcloud dns managed-zones create on-prem-peering \
    --dns-name="corp.internal." \
    --visibility=private \
    --networks=projects/PROJECT/global/networks/VPC_NAME \
    --forwarding-targets=10.0.0.2  # On-prem DNS server IP

References ​