1. 項目概述為什么Kubernetes離不開自己的DNS在Kubernetes集群里服務發(fā)現是個基礎到不能再基礎卻又至關重要的問題。想象一下你部署了一個名為my-api的微服務它可能會因為擴縮容、節(jié)點故障或滾動更新其Pod的IP地址隨時都在變。如果另一個服務my-frontend需要通過IP來調用my-api那簡直就是一場運維災難你需要不斷更新配置這完全違背了云原生的彈性與自動化理念。這就是Kubernetes內置DNS服務存在的核心價值。它不是一個可選項而是集群的“神經系統(tǒng)”負責將穩(wěn)定的服務名Service Name解析為動態(tài)變化的Pod IP地址。默認情況下從Kubernetes 1.13版本開始這個“神經系統(tǒng)”的核心組件就是CoreDNS。它取代了早期的kube-dns以其更高的性能、更靈活的插件化架構成為了Kubernetes服務發(fā)現的官方標準。簡單來說沒有CoreDNSKubernetes集群內的服務間通信將退回到原始的、手動維護IP地址的“石器時代”集群的自動化管理和微服務架構的優(yōu)勢將無從談起。無論你是剛接觸k8s的開發(fā)者還是負責維護生產集群的運維工程師深入理解CoreDNS的工作原理、配置和排錯都是構建穩(wěn)定、可觀測的云原生應用的必修課。2. CoreDNS在Kubernetes中的架構與核心原理2.1 CoreDNS的核心工作流程要理解CoreDNS首先要明白它在Kubernetes集群中扮演的角色。它不是一個獨立于集群外的傳統(tǒng)DNS服務器而是一個以Pod形式運行在kube-system命名空間下的集群附加組件。其工作流程可以概括為以下幾個核心步驟監(jiān)聽與查詢接收CoreDNS Pod通過一個名為kube-dns的Service對外暴露服務其ClusterIP通常是10.96.0.10可配置。集群內所有Pod的/etc/resolv.conf文件中的nameserver都被配置指向這個IP。當Pod內的應用程序發(fā)起一個DNS查詢例如查詢my-api.default.svc.cluster.local時請求首先到達CoreDNS。插件鏈處理這是CoreDNS設計的精髓。它不像傳統(tǒng)DNS服務器那樣有固定的處理邏輯而是通過一個可配置的插件鏈Plugin Chain來處理請求。一個查詢請求會像流水線一樣依次經過配置文件中啟用的各個插件。每個插件可以決定是直接響應、修改請求、轉發(fā)請求還是將請求傳遞給下一個插件。與Kubernetes API交互對于Kubernetes集群內的域名查詢最關鍵的一個插件是kubernetes插件。當查詢的域名匹配集群內服務域名格式如.svc.cluster.local時kubernetes插件會向Kubernetes API Server發(fā)起查詢獲取對應Service、Pod或Endpoints的真實IP地址信息。響應返回kubernetes插件從API Server獲取到IP信息后將其封裝成標準的DNS響應報文沿原路返回給發(fā)起查詢的Pod。對于集群外的域名如www.example.comCoreDNS通常會配置forward插件將查詢請求轉發(fā)到上游的DNS服務器如宿主機配置的DNS或公共DNS8.8.8.8。這個流程確保了服務名的解析是完全動態(tài)的、實時的與Kubernetes的資源狀態(tài)保持嚴格一致。2.2 關鍵配置文件解析CorefileCoreDNS的所有行為都由一個名為Corefile的配置文件驅動。在Kubernetes中這個配置文件通常以一個ConfigMap的形式存在名為coredns位于kube-system命名空間。我們可以通過kubectl get configmap coredns -n kube-system -o yaml來查看其內容。一個典型的默認配置如下apiVersion: v1 data: Corefile: | .:53 { errors health { lameduck 5s } ready kubernetes cluster.local in-addr.arpa ip6.arpa { pods insecure fallthrough in-addr.arpa ip6.arpa ttl 30 } prometheus :9153 forward . /etc/resolv.conf cache 30 loop reload loadbalance } kind: ConfigMap我們來逐段拆解這個核心配置.:53這定義了一個服務器塊Server Block監(jiān)聽所有網卡.的53端口DNS標準端口。errors將錯誤日志打印到標準輸出。health提供健康檢查端點默認在http://localhost:8080/health。ready提供就緒檢查端點當所有插件加載完成后該端點返回200 OK。這對于Kubernetes的Readiness Probe很重要。kubernetes cluster.local ...這是核心插件。它告訴CoreDNS負責解析cluster.local及其子域如svc.cluster.local以及反向解析域in-addr.arpa,ip6.arpa的查詢。pods insecure啟用Pod的DNS記錄格式為pod-ip.namespace.pod.cluster.local。insecure選項意味著即使Pod沒有關聯的Service也會為其創(chuàng)建A記錄。在生產環(huán)境中出于安全考慮有時會省略此選項或使用pods verified模式。fallthrough如果查詢的域名在kubernetes插件域內但未找到記錄則將查詢“墜落”到插件鏈中的下一個插件例如forward插件處理。ttl 30為DNS記錄設置生存時間TTL為30秒。較短的TTL有助于客戶端更快地感知到后端Pod IP的變化。prometheus :9153在9153端口暴露Prometheus格式的指標方便監(jiān)控CoreDNS的性能和查詢量。forward . /etc/resolv.conf這是處理集群外域名的關鍵。它將所有未在kubernetes插件域內匹配的查詢用.表示轉發(fā)到CoreDNS Pod內/etc/resolv.conf文件中定義的上游DNS服務器。這通常是宿主機或自定義的DNS。cache 30啟用緩存緩存時間為30秒可以顯著減少對上游DNS和Kubernetes API的重復查詢壓力。loop檢測到簡單的DNS轉發(fā)循環(huán)時發(fā)出警告并停止CoreDNS進程。reload允許自動重新加載Corefile。當ConfigMap內容更改后CoreDNS會在一段時間后自動加載新配置無需重啟Pod。loadbalance對于同一個服務名有多個后端IP即Service對應多個Pod的情況以輪詢round-robin方式返回IP地址實現基本的DNS負載均衡。理解這個Corefile是掌握CoreDNS配置和故障排查的基礎。3. Kubernetes中的DNS域名解析規(guī)則詳解在Kubernetes集群內DNS解析有一套完整的命名規(guī)范。理解這些規(guī)則是進行服務調用和問題診斷的前提。3.1 完整的服務域名格式一個Service在集群內擁有一個完整的、可被DNS解析的域名Fully Qualified Domain Name, FQDN。其標準格式為service-name.namespace-name.svc.cluster.localservice-name你定義的Service資源名稱例如my-api。namespace-nameService所在的命名空間例如default。如果調用方Pod與被調用的Service在同一個命名空間可以省略命名空間及之后的部分直接使用service-name。svc.cluster.local這是Kubernetes集群的默認集群域Cluster Domain。在大多數部署中它默認為cluster.local但也可以在kubelet或kube-apiserver的啟動參數中通過--cluster-domain進行自定義。示例 假設在production命名空間下有一個名為redis-master的Service。在production命名空間內的Pod可以直接使用redis-master來訪問它。在其他命名空間如default的Pod則需要使用完整的FQDNredis-master.production.svc.cluster.local。3.2 Pod的DNS策略與解析配置每個Pod都可以通過dnsPolicy字段來指定其DNS配置策略這直接影響Pod內/etc/resolv.conf文件的生成。主要有以下幾種策略ClusterFirst默認這是最常用的策略。Pod的/etc/resolv.conf中的nameserver會被設置為集群DNS服務CoreDNS的ClusterIP。任何不匹配cluster.local后綴的DNS查詢都會被CoreDNS轉發(fā)到上游DNS服務器。apiVersion: v1 kind: Pod metadata: name: busybox spec: dnsPolicy: ClusterFirst # 默認值通常無需顯式指定 containers: - name: busybox image: busybox:1.28 command: [sh, -c, sleep 3600]ClusterFirstWithHostNet對于使用主機網絡hostNetwork: true的Pod如果希望它仍然使用集群DNS則需要指定此策略。因為使用主機網絡的Pod默認會繼承宿主機的/etc/resolv.conf。DefaultPod直接從其運行的節(jié)點上繼承DNS配置。即Pod內的/etc/resolv.conf文件與節(jié)點上的文件一致。這通常意味著Pod會使用宿主機配置的公共DNS或企業(yè)內網DNS而無法解析集群內的Service域名。None此策略允許你通過dnsConfig字段完全自定義Pod的DNS配置。它提供了最高的靈活性。apiVersion: v1 kind: Pod metadata: name: custom-dns-pod spec: dnsPolicy: None dnsConfig: nameservers: - 8.8.8.8 - 1.1.1.1 searches: - ns1.svc.cluster.local - my.dns.search.suffix options: - name: ndots value: 2 - name: edns0nameservers自定義DNS服務器列表。searchesDNS搜索域列表。當查詢的主機名不是FQDN時系統(tǒng)會依次嘗試附加這些搜索域。Kubernetes默認會為Pod添加namespace.svc.cluster.local、svc.cluster.local和cluster.local等搜索域。optionsDNS解析器選項。其中ndots尤為重要它指定了一個域名中必須包含的點號.數量少于這個數量的查詢會先嘗試附加搜索域。默認值為ndots:5在Kubernetes環(huán)境下過高的ndots值可能導致不必要的搜索域查詢影響解析效率。有時為了優(yōu)化會將其設置為2或3。3.3 Headless Service與StatefulSet的特殊解析對于無頭服務Headless Service即spec.clusterIP: None和StatefulSetDNS解析行為有所不同這對于有狀態(tài)應用至關重要。Headless Service當查詢一個Headless Service的域名時CoreDNS返回的不是一個單一的ClusterIP而是該Service后端所有Pod的IP地址列表。這允許客戶端直接與Pod通信常用于實現自定義的負載均衡或主從選舉等場景。StatefulSetStatefulSet管理的Pod擁有穩(wěn)定的、可預測的網絡標識。其Pod主機名的格式為statefulset-name-ordinal。同時每個Pod會獲得一個唯一的DNS記錄pod-name.service-name.namespace.svc.cluster.local。這使得在StatefulSet的Pod之間可以通過固定的DNS名稱相互發(fā)現例如在Redis Sentinel或MongoDB副本集中非常有用。4. CoreDNS的部署、配置與優(yōu)化實操4.1 部署與基礎檢查在通過kubeadm等工具部署的Kubernetes集群中CoreDNS通常是默認安裝的。你可以通過以下命令檢查其狀態(tài)# 檢查CoreDNS的Deployment和Pod狀態(tài) kubectl get deployment coredns -n kube-system kubectl get pods -l k8s-appkube-dns -n kube-system -o wide # 檢查CoreDNS的Service kubectl get svc kube-dns -n kube-system # 查看CoreDNS的配置ConfigMap kubectl get configmap coredns -n kube-system -o yaml # 查看CoreDNS Pod的日志排查啟動或運行時錯誤 kubectl logs -f deployment/coredns -n kube-system如果CoreDNS沒有運行或者你想自定義部署可以參考官方提供的部署清單。但更常見的操作是修改其ConfigMap來調整行為。4.2 自定義CoreDNS配置常見場景場景一添加自定義域名解析如解析內網服務假設公司內網有一個數據庫域名為internal-db.corp.comIP為10.10.10.100。我們希望集群內所有Pod都能通過這個域名訪問它。我們可以修改CoreDNS的ConfigMap添加hosts插件。編輯ConfigMapkubectl edit configmap coredns -n kube-system在Corefile的服務器塊中添加hosts插件。注意插件順序通常hosts插件應放在kubernetes插件之前以確保優(yōu)先使用靜態(tài)映射。Corefile: | .:53 { errors health ready # 添加hosts插件定義靜態(tài)映射 hosts { 10.10.10.100 internal-db.corp.com # 可以添加更多映射 fallthrough } kubernetes cluster.local in-addr.arpa ip6.arpa { pods insecure fallthrough in-addr.arpa ip6.arpa } prometheus :9153 forward . /etc/resolv.conf cache 30 loop reload loadbalance }fallthrough指令表示如果hosts插件中沒有找到匹配項則繼續(xù)執(zhí)行插件鏈中的下一個插件即kubernetes或forward。場景二配置上游DNS服務器默認情況下CoreDNS使用Pod內的/etc/resolv.conf通常是宿主機的DNS配置作為上游轉發(fā)器。如果你想指定特定的上游DNS比如使用8.8.8.8和114.114.114.114可以修改forward插件forward . 8.8.8.8 114.114.114.114 { max_concurrent 1000 prefer_udp }這里max_concurrent限制了最大并發(fā)查詢數prefer_udp表示優(yōu)先使用UDP協(xié)議。場景三啟用日志記錄以調試DNS查詢在排查DNS問題時啟用查詢日志非常有用?？梢蕴砑觢og插件log這會將所有經過CoreDNS的查詢日志打印到標準輸出。在生產環(huán)境中為了避免日志量過大可以結合filter插件或僅在有問題的Pod上臨時啟用。4.3 性能優(yōu)化與監(jiān)控調整緩存時間cache插件的TTL值默認30秒可以根據集群服務變更頻率調整。對于極其穩(wěn)定的服務可以適當增加緩存時間如300秒以減少API Server壓力。對于頻繁變更的服務保持較低TTL。監(jiān)控CoreDNS利用其內置的prometheus插件暴露的指標進行監(jiān)控是關鍵。你需要部署Prometheus并配置抓取kube-system命名空間下CoreDNS Pod的9153端口。需要關注的指標包括coredns_dns_request_count_total總請求數按類型A AAAA SRV等和區(qū)域zone區(qū)分。coredns_dns_request_duration_seconds請求延遲分布。coredns_dns_response_rcode_count_total響應碼計數NOERROR NXDOMAIN SERVFAIL等SERVFAIL增多通常意味著上游或API Server問題。coredns_panic_count_totalCoreDNS進程崩潰次數。資源請求與限制確保為CoreDNS的Deployment設置合適的資源請求和限制防止其因資源不足被驅逐或OOMKilled。通常建議內存從128Mi起步根據負載調整。resources: limits: memory: 256Mi cpu: 200m requests: memory: 128Mi cpu: 100m副本數與反親和性對于生產集群至少運行2個CoreDNS Pod副本以確保高可用。并配置Pod反親和性讓它們調度到不同的節(jié)點上避免節(jié)點故障導致DNS服務完全中斷。spec: replicas: 2 strategy: type: RollingUpdate affinity: podAntiAffinity: preferredDuringSchedulingIgnoredDuringExecution: - weight: 100 podAffinityTerm: labelSelector: matchExpressions: - key: k8s-app operator: In values: - kube-dns topologyKey: kubernetes.io/hostname5. 常見DNS問題排查與修復實錄在實際運維中DNS問題是導致Pod網絡連通性故障的常見原因。下面是一個系統(tǒng)性的排查流程和常見問題案例。5.1 系統(tǒng)性排查流程當遇到服務間無法通過域名通信時可以按照以下步驟排查檢查Pod本身網絡與DNS配置# 進入出問題的Pod或啟動一個臨時調試Pod如busybox kubectl exec -it problem-pod-name -- sh # 檢查DNS配置 cat /etc/resolv.conf # 正常應看到 nameserver 指向集群DNS IP (如 10.96.0.10) # 測試基礎網絡連通性 ping 10.96.0.10 # 測試是否能ping通CoreDNS Service IP nc -zv 10.96.0.10 53 # 測試53端口是否可達 # 使用nslookup或dig進行DNS查詢測試 nslookup kubernetes.default.svc.cluster.local # 或安裝dig后使用 dig 10.96.0.10 kubernetes.default.svc.cluster.local short檢查CoreDNS服務狀態(tài)# 確認CoreDNS Pod是否Running且Ready kubectl get pods -n kube-system -l k8s-appkube-dns # 查看CoreDNS Pod日志是否有錯誤 kubectl logs -n kube-system deployment/coredns --tail50 # 確認kube-dns Service是否存在且Endpoints正常 kubectl get svc kube-dns -n kube-system kubectl get endpoints kube-dns -n kube-system檢查Kubernetes網絡插件CNIDNS依賴底層網絡。確保Calico、Flannel等CNI插件工作正常Pod IP分配和路由沒有問題。檢查Node節(jié)點DNS配置CoreDNS的forward插件依賴節(jié)點DNS。檢查節(jié)點/etc/resolv.conf確保上游DNS服務器可達且沒有配置錯誤。5.2 典型問題案例與解決方案案例一Pod內/etc/resolv.conf的ndots值過高導致解析延遲癥狀應用調用內部服務域名時偶爾出現超時但直接使用完整FQDN如service.namespace.svc.cluster.local則正常。 原因分析Pod內/etc/resolv.conf默認options ndots:5。當應用查詢一個包含少于5個點如redis-master的域名時解析器會依次嘗試附加所有搜索域如redis-master.default.svc.cluster.localredis-master.svc.cluster.localredis-master.cluster.local等直到成功或全部失敗。這會增加不必要的查詢次數和延遲。 解決方案在Pod或Deployment的dnsConfig中降低ndots值或鼓勵應用使用完整的FQDN。spec: dnsPolicy: None dnsConfig: options: - name: ndots value: 2案例二CoreDNS Pod內存不足OOMKilled癥狀CoreDNS Pod頻繁重啟kubectl describe pod顯示原因為OOMKilled。 原因分析查詢量過大、緩存設置不當或存在內存泄漏的插件可能導致內存使用量激增。 解決方案增加CoreDNS Pod的內存限制limits.memory。檢查并優(yōu)化Corefile配置例如減少不必要的日志輸出log插件調整緩存大小。監(jiān)控內存使用趨勢排查是否有異常的查詢流量如DNS放大攻擊。案例三無法解析集群外域名如公網域名癥狀Pod內可以解析kubernetes.default.svc.cluster.local但無法解析www.baidu.com。 排查步驟進入Pod嘗試dig 10.96.0.10 www.baidu.com。如果失敗說明CoreDNS的上游轉發(fā)有問題。檢查CoreDNS ConfigMap中的forward插件配置確認其指向的上游DNS服務器如/etc/resolv.conf或指定的IP是否可達且正確。登錄到CoreDNS Pod所在節(jié)點檢查節(jié)點的網絡連通性和DNS配置。檢查網絡策略NetworkPolicy是否阻止了CoreDNS Pod或節(jié)點向上游DNS服務器53端口的出口流量。案例四Headless Service解析返回多個IP但連接失敗癥狀通過nslookup查詢Headless Service域名能返回所有Pod IP但應用連接其中某些IP時失敗。 原因分析DNS只負責解析不檢查Pod的健康狀態(tài)。返回的IP中可能包含處于NotReady狀態(tài)的Pod。 解決方案應用端需要實現連接重試和健康檢查機制?；蛘呖紤]使用readinessProbe并結合publishNotReadyAddresses: false的Service此配置控制不健康的Pod IP是否從Service的Endpoints中移除從而影響DNS解析結果。5.3 調試工具箱準備一些常用的調試鏡像和命令能極大提升效率# 1. 啟動一個包含dig, nslookup, curl等工具的臨時調試Pod kubectl run dns-debug --imagebusybox:1.28 --restartNever --rm -it -- sh # 2. 在Pod內進行DNS查詢 nslookup kubernetes.default.svc.cluster.local dig dns-service-ip service-name.namespace.svc.cluster.local A # 3. 從集群外部測試Service需要kubectl端口轉發(fā)或Ingress # 通常用于測試ClusterIP類型的Service是否工作正常 # 4. 檢查CoreDNS的Prometheus指標 # 假設已配置Prometheus可以在Grafana中查看或直接查詢 # 例如查詢最近5分鐘SERVFAIL錯誤率 sum(rate(coredns_dns_response_rcode_count_total{rcodeSERVFAIL}[5m])) by (pod) / sum(rate(coredns_dns_response_rcode_count_total[5m])) by (pod)DNS問題排查往往需要耐心從Pod內部到CoreDNS自身再到上游和底層網絡逐層縮小范圍。掌握CoreDNS的原理和這些排查工具能讓你在遇到服務發(fā)現故障時快速定位并解決問題保障集群的穩(wěn)定運行。