K8s 跨集群通信的“量子糾纏”：當 DNS 黑洞吞沒你的服務請求

作者：劉俊夏 2025-03-24 00:35:00

云計算云原生

一個 ??ndots?? 參數足以引發跨集群雪崩，理解 Kubernetes DNS 解析鏈（遞歸查詢 → searchDomains 追加 → 超時控制）是關鍵。

引言

對于這種案例，你們的處理思路是怎么樣的呢，是否真正的處理過，如果遇到，你們應該怎么處理。

我想大多數人都沒有遇到過。

開始

一、現象：跨集群通信的神秘失效

某金融系統在混合云架構中部署了多套 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.conf

4. 防御體系構建

層級	工具/策略	防護能力
配置校驗	OpenPolicyAgent (OPA)	攔截無效 `searchDomains`
監控預警	Prometheus + CoreDNS 指標	實時檢測 `SERVFAIL` 率
混沌測試	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 定位異常模式，比日志更早發現問題。

責任編輯：武曉燕來源：云原生運維圈

K8s 集群通信