K8s 跨集群通信的“量子糾纏”：當 DNS 黑洞吞沒你的服務請求
引言
對于這種案例，你們的處理思路是怎么樣的呢，是否真正的處理過，如果遇到，你們應該怎么處理。
我想大多數人都沒有遇到過。
開始
一、現象：跨集群通信的神秘失效
某金融系統在混合云架構中部署了多套 Kubernetes 集群，用于實現跨地域容災。某次業務切換演練時，發現跨集群服務發現完全失效，具體表現為：
1. 服務發現中斷：
# 在故障 Pod 中測試解析
kubectl exec -it frontend-pod -- nslookup backend-service.cluster-b.svc.cluster.local
;; Got SERVFAIL reply from 10.96.0.10, trying next server
;; connection timed out; no servers could be reached? 集群 A 的 Pod 無法通過 service-name.cluster-b.svc.cluster.local 訪問集群 B 的服務
? nslookup 返回 **SERVFAIL** 錯誤，但 CoreDNS 日志無任何異常記錄
2. 核心指標異常：
? Prometheus 監控顯示 coredns_dns_request_count_total{rcode="SERVFAIL"} 激增
? 服務網格流量統計中，跨集群請求失敗率高達 92%
二、根因分析：DNS 配置的「死亡組合」
1. ndots:5 的「量子糾纏」
問題本質：
Kubernetes 默認在 Pod 的 /etc/resolv.conf 中設置 options ndots:5。該配置要求：
? 當查詢的域名包含 少于 5 個點 時，DNS 客戶端會嘗試追加所有 searchDomains
? 對于跨集群服務域名 backend-service.cluster-b.svc.cluster.local（4 個點），觸發以下查詢鏈：
# 實際查詢順序（偽代碼）
for domain in searchDomains:
query = "backend-service.cluster-b.svc.cluster.local.{domain}"
send_to_dns_server(query)致命沖突：私有 DNS 服務器（如 AD DNS）無法處理這種帶冗余后綴的查詢，直接返回 SERVFAIL。
2. searchDomains 的「黑洞陷阱」
問題本質：/etc/resolv.conf 中殘留無效的 searchDomains，例如：
search default.svc.cluster.local svc.cluster.local cluster.local corp.legacy.com # 已廢棄的域災難鏈：
1. 客戶端先嘗試查詢 backend-service.cluster-b.svc.cluster.local.default.svc.cluster.local
2. 私有 DNS 無法解析，耗時 5 秒（默認超時）
3. 繼續嘗試下一個后綴，最終耗盡查詢時間
三、解決方案：四步破解 DNS 黑洞
1. 動態調整 ndots 配置
通過 ConfigMap 覆蓋默認 DNS 策略：
# coredns-configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: coredns-custom
namespace: kube-system
data:
Corefile: |
cluster.local:53 {
errors
health
ready
kubernetes cluster.local in-addr.arpa ip6.arpa {
pods insecure
fallthrough in-addr.arpa ip6.arpa
}
# 關鍵：調整 ndots 為 3
template IN A {
match "^([^\.]+)\.([^\.]+)\.svc\.cluster\.local$"
answer "{{ .Name }}.{{ .Match.2 }}.svc.cluster.local 5 IN A $SERVICE_IP"
fallthrough
}
forward . /etc/resolv.conf {
policy sequential
prefer_udp
}
cache 30
reload 15s
# 強制 ndots=3
loop
reload
loadbalance
}2. 清理無效 searchDomains
在 Pod 模板中注入 DNS 配置：
# deployment-patch.yaml
spec:
template:
spec:
dnsConfig:
searches: # 僅保留有效域
- cluster-b.svc.cluster.local
- svc.cluster.local
- cluster.local
options:
- name: ndots
value: "3"3. DNS 查詢鏈路驗證
使用 netshoot 鏡像進行全鏈路測試：
# 啟動診斷容器
kubectl run dns-debug --image=nicolaka/netshoot --rm -it --restart=Never -- /bin/sh
# 分步測試解析
dig +trace backend-service.cluster-b.svc.cluster.local
nslookup -debug backend-service.cluster-b.svc.cluster.local
# 檢查實際查詢順序
cat /etc/resolv.conf4. 防御體系構建
層級 | 工具/策略 | 防護能力 |
配置校驗 | OpenPolicyAgent (OPA) | 攔截無效 |
監控預警 | Prometheus + CoreDNS 指標 | 實時檢測 |
混沌測試 | Chaos Mesh 注入 DNS 延遲 | 提前發現鏈路脆弱點 |
四、核心命令速查表
# 1. 查看 Pod 的 DNS 配置
kubectl exec <pod-name> -- cat /etc/resolv.conf
# 2. 強制刷新 CoreDNS 緩存
kubectl delete pod -n kube-system -l k8s-app=kube-dns
# 3. 抓取跨集群 DNS 包
kubectl debug <pod-name> -it --image=nicolaka/netshoot -- tcpdump -i any -nn port 53
# 4. 生成 DNS 查詢拓撲圖
kubectl get svc -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.clusterIP}{"\n"}{end}' > dns-map.txt五、經驗總結
1. DNS 配置的「蝴蝶效應」：一個 ndots 參數足以引發跨集群雪崩，理解 Kubernetes DNS 解析鏈（遞歸查詢 → searchDomains 追加 → 超時控制）是關鍵。
2. 防御性編碼原則：在 CI/CD 流水線中集成 DNS 策略校驗（如 kube-score 檢查 dnsConfig）。
3. 觀測驅動運維：通過指標 coredns_dns_response_rcode_count 定位異常模式，比日志更早發現問題。
