CoreDNS簡單除錯:解決你遇到的一般問題

閱讀時間約 15 分鐘

最近在部署一些解決方案時,碰到了關於名稱解析上的一些問題,雖然有時候不難解決,但我發現如果清楚K8S有關於名稱解析的概念,會對除錯的時間與過程有很大的幫助。

raw-image

透過本篇文章,除了幫自已留下問題查找的過程,同時也希望利用文章來整理自已對CoreDNS元件的一些觀念,同時也可以分享給大家參考。

以下是本文所將提到的章節:

  1. 基本架構與如何運作
  2. Kube-DNS & CoreDNS
  3. 問題的處理過程與方式
  4. 結論

本文為心得記錄,內容比較長,感謝大家願意花時間觀看。


1. 基本架構與如何運作

首先不免俗的還是來一個官方的說法:

CoreDNS也是DNS server的一種,用Go語言開發。

與其他DNS(ex. BIND)不同,它非常彈性、並且幾乎所有的功能都全部都被放成Plugin的型式。
這些Plugin可以各別運行或是全部放在一起運行來實現DNS的功能。

透過官方的說法,我們可以利用CoreDNS的特性來選擇與組合這些Plugin(CoreDNS Plugin API),變成自訂版本的DNS解決方式。預設的CoreDNS安裝完就會帶有約30個Plugin一起安裝進系統。其他額外的Plugin可以到以下網址去找到自已需要的:

https://coredns.io/explugins/?source=post_page-----71d255e39548--------------------------------

簡短說完CoreDNS的來歷,接下來說明kubernetes中,如何解析domain name的。

在K8S內,如果Pod在訪問在同一個Namespace下的Service,只要執行:

# curl aa-svc

可是如果訪問的對象在不同的namespace呢? 此時就要再加上domain的部分,如下:

# curl aa-svc.domain

由此可知,只要離開自已的namespace範圍時,就會需要做名稱解析了。

不管是不是在K8S cluster內,基本上DNS解析基本上會使用到:

  • /etc/host.conf
  • /etc/hosts
  • /etc/resolv.conf
raw-image


在訪問時,Pod會先查找/etc/resolv.conf的內容,裡面就是指定DNS server的位置,而內容則是由設定好dnspolicy: ClusterFirst的情況下,自動生成出來。裡面nameserver的IP則是DNS service的cluster IP。所以這個Pod內所有的解析都會與這個cluster IP傳送(不管是不是同一個namespace)。




預設的search domain(搜尋時會依序進行查找):

  • namespace.svc.cluster.local
  • svc.cluster.local
  • cluster.local

最後簡單說明K8S的DNS Policies,一共有以下四種:

  • ClusterFirstWithHostNet => 如果Pod使用hostnetwork: true時,會直接套用Node上的resolv.conf內容,如果要用Pod內自已的內容,就要用這個策略。
  • ClusterFirst => Pod內的DNS優先使用K8S內的DNS服務(此處指CoreDNS)
  • Default => 直接讓kubelet來決定用那種,預設是用Node內的resolv.conf的內容。
  • None => 都不指定,直接使用dnsconfig的內容來自定義。

2. Kube-DNS & CoreDNS

本章節簡單說明二者的不同。

(1) Kube-DNS: 同樣提供DNS名稱解析的功能,但K8S 1.21版之後,kubeadm移除了對Kube-DNS的支援,只支援CoreDNS。而以下圖為Kube-DNS的基本架構圖:

From: https://feisky.gitbooks.io/kubernetes/content/components/kube-dns.html

From: https://feisky.gitbooks.io/kubernetes/content/components/kube-dns.html

以下簡單說明主要的三個元件:

  • kubeDNS : 用來監聽K8S內的service與endpoint的變化
  • dnsmesq : 區分domain是內部還是外部,內部的話發往10053 Port做Cache
  • sidecar : 對kubedns與dnsmesq進行health check與監控指標收集

(2) CoreDNS: 請參閱上述內容,就不重覆內容。

From: https://livewyer.io/blog/2018/05/31/a-brief-look-at-coredns/

From: https://livewyer.io/blog/2018/05/31/a-brief-look-at-coredns/

(3) 優缺點:

※ Kube-DNS

  • 優點:有dnsmesq,效能上有一定確保
  • 缺點:dnsmesq如果重啟,會先殺掉process才重新帶起服務,中間可能會出現查詢失敗。確認檢查內部檔案時,如果數量過多或太頻繁更新,有可能反而會導致dnsmesq必須要重新啟動。

※ CoreDNS

  • 優點:可以根據需求使用自訂的Plugin。1.21版後預設支援的DNS。記憶體佔用的情況比Kube-DNS好。
  • 缺點:Cache的效率沒有dnsmesq好,內部解析沒有kube-dns快。

3. 問題的處理過程與方式

#---------------------------------------------
# S3-1. 部署dnsutils
#---------------------------------------------
[master]# vim dnsutils.yaml
apiVersion: v1
kind: Pod
metadata:
name: dnsutils
namespace: default
spec:
containers:
- name: dnsutils
image: registry.k8s.io/e2e-test-images/jessie-dnsutils:1.3
command:
- sleep
- "infinity"
securityContext:
capabilities:
add:
- NET_RAW
imagePullPolicy: IfNotPresent
restartPolicy: Always

[master]# kubectl create -f dnsutils.yaml -n default
[master]# kubectl get podils.yaml -n default

[master]# kubectl get pod
raw-image
#----------------------------------------------------
# S3-2. Ping
#----------------------------------------------------
[master]# kubectl exec -it dnsutils /bin/sh
/# ping kubernetes.default
/# ping default.svc.cluster.localster.local
raw-image
#----------------------------------------------------
# S3-3. 確認是否有將namespace的svc內容打入環境變數
#----------------------------------------------------
[master]# kubectl exec -it dnsutils -n default -- env | grep KUBERNETESRNETES
raw-image
#----------------------------------------------------
# S3-4. nslookup
#----------------------------------------------------
/# nslookup kubernetes.default
/# nslookup default.svc.cluster.local

;; connection timed out; no servers could be reachedbe reached
#----------------------------------------------------
# S3-5. 確認coredns pod status
#----------------------------------------------------
[master]# kubectl get pods -l k8s-app=kube-dns -n kube-system
=> 均為Running狀態unning狀態
raw-image
#----------------------------------------------------
# S3-6. 確認coredns pod logs
#----------------------------------------------------
[master]# for p in $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name); do kubectl logs --namespace=kube-system $p; done

=> 沒有錯誤訊息
=> 以下會出現較多訊息的原因是在"kubectl edit configmap coredns -n kube-system" 加入log參數 加入log參數
raw-image
#----------------------------------------------------
# S3-7. 確認endpoint and pod binding
#----------------------------------------------------
[master]# kubectl get pods -l k8s-app=kube-dns -n kube-system -o wide
[master]# kubectl get endpoints kube-dns -n kube-systeme-system
raw-image
#----------------------------------------------------
# S3-8. 確認是否為"Pod本身解析" or "Pod ok,但請求送到kube-dns無法轉發"
# 直接修改/etc/resolv.conf的nameserver換成別的
#----------------------------------------------------
Pod /etc/resolv.conf => 指向10.86.0.10 (Service “kube-dns” 的 cluterIP)

[lb01]# kubectl exec -it dnsutils /bin/sh
/# vi /etc/resolv.conf
nameserver 8.8.8.8
/# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: seq=0 ttl=56 time=2.774 ms
64 bytes from 8.8.8.8: seq=1 ttl=56 time=2.571 ms
64 bytes from 8.8.8.8: seq=2 ttl=56 time=2.625 ms
64 bytes from 8.8.8.8: seq=3 ttl=56 time=2.512 ms

/# ping www.google.com
ping: bad address 'www.google.com'address 'www.google.com'
#----------------------------------------------------
# S3-9. 確認kube-proxy是否有問題
#----------------------------------------------------
[master]# kubectl logs kube-proxy-6kdj2 --tail=5 -n kube-system
=> 確認是否有error是否有error
raw-image

根據以下流程圖,可以發現Pod會先往CoreDNS(10.96.0.10)查詢,然後再轉送到外部進行解析。

From: https://ci-jie.github.io/2021/02/07/Kubernetes-CoreDNS/

From: https://ci-jie.github.io/2021/02/07/Kubernetes-CoreDNS/

#--------------------------------------------
# S3-10. 確認Pod是否可以正確轉送到外部解析
#--------------------------------------------
[master]# kubectl exec -it nginx-quic-deployment-c5f8b8b44-8hwm9 -- bash
/# yum updatem update
raw-image

最後請注意,在Pod內能Ping的IP不能是Service的Cluster IP,它是Virtual IP,如果要Ping其他服務IP時,請照以下方式:

master]# kubectl describe pod <pod_name> => find IP
[master]# kubectl exec -it nginx-quic-deployment-c5f8b8b44-8hwm9 -- bash
/# ping 192.168.35.935.9
raw-image
raw-image

4. 結論

終於完成關於DNS解析的文章,當初看了非常多文件來了解到底Kubernetes內部名稱解析在做些什麼事,從以上文章可以了解到許多服務之間的溝通真的非常依賴CoreDNS,所以了解CoreDNS的運作方式,對於想要管理K8S cluster的管理者是至關重要的。

最後如果現在是使用Kube-dns方案的Cluster,官方在升級K8S時提供一個轉換成CoreDNS的支援,參考網址如下:

https://kubernetes.io/docs/tasks/administer-cluster/coredns/?source=post_page-----71d255e39548--------------------------------


References:



avatar-img
15會員
40內容數
記錄IT社畜的自我學習筆記,如同專題名稱,主要是怕自已忘記自已做過什麼、學到什麼。索性就分享我自已在學習Kubernetes這條路上的各種測試、學習心得。
留言0
查看全部
avatar-img
發表第一個留言支持創作者!
超健忘閒人的沙龍 的其他內容
今天來分享在建置完K8S後的基本工作之一 : 監控。 只要是任何會”運作”的物件(Object),不管平台、服務、軟體、硬體,為了要提供最高的可用性,就會需要透過大大小小的監控元件來幫助我們了解所有的狀態,以便在問題發生時能做到最快速的反應。
延續上篇的內容,在了解了MetalLB的基本概念之後,我們就進入實際上部署的動作,還沒看過的可以到以下連結先有個基本概念: 本篇針對部署一個最基本的MetalLB的做法,共分成四個部分來進行說明:
今天跟大家分享在地端資料中心內建立Kubernetes叢集之後,如何針對網路進行更進一步的優化。除了CNI(容器網路接口)的設定,實務上我還會再另行建立Loadbalancer的機制。
在現今快速發展的數據應用環境之下,Kubernetes已經成為部署和管理容器化應用的首選平台。但是隨著應用服務愈來愈複雜、被攻擊的風險也愈來愈高。為了保護Kubernetes環境的安全性,跟大家介紹一個針對Kubernetes安全合規掃描的工具,幫助確保您的 Kubernetes 叢集設置和應用程序
接續上一篇文章,本文再深入一點關於ETCD基本操作以及在其他文章中關於ETCD節點資料不一致情況的除錯內容分享
建立Kubernetes cluster時,ETCD 是必不可少的元件,事實上Kubernetes所有資料都會存進ETCD store中,如果要讓Kubernetes的運行效能更好,其中一種方法是在部署之前對ETCD的性能進行優化設計。
今天來分享在建置完K8S後的基本工作之一 : 監控。 只要是任何會”運作”的物件(Object),不管平台、服務、軟體、硬體,為了要提供最高的可用性,就會需要透過大大小小的監控元件來幫助我們了解所有的狀態,以便在問題發生時能做到最快速的反應。
延續上篇的內容,在了解了MetalLB的基本概念之後,我們就進入實際上部署的動作,還沒看過的可以到以下連結先有個基本概念: 本篇針對部署一個最基本的MetalLB的做法,共分成四個部分來進行說明:
今天跟大家分享在地端資料中心內建立Kubernetes叢集之後,如何針對網路進行更進一步的優化。除了CNI(容器網路接口)的設定,實務上我還會再另行建立Loadbalancer的機制。
在現今快速發展的數據應用環境之下,Kubernetes已經成為部署和管理容器化應用的首選平台。但是隨著應用服務愈來愈複雜、被攻擊的風險也愈來愈高。為了保護Kubernetes環境的安全性,跟大家介紹一個針對Kubernetes安全合規掃描的工具,幫助確保您的 Kubernetes 叢集設置和應用程序
接續上一篇文章,本文再深入一點關於ETCD基本操作以及在其他文章中關於ETCD節點資料不一致情況的除錯內容分享
建立Kubernetes cluster時,ETCD 是必不可少的元件,事實上Kubernetes所有資料都會存進ETCD store中,如果要讓Kubernetes的運行效能更好,其中一種方法是在部署之前對ETCD的性能進行優化設計。
你可能也想看
Google News 追蹤
Thumbnail
在這篇教學文章中,我們將展示如何使用 Node.js 建立一個簡單的伺服器,並解決常見的跨來源資源共享(CORS)問題,確保伺服器能夠接收並處理來自不同來源的資料。
Thumbnail
這篇文章將提供一個完整的Kubernetes安裝指南,包括控制平面節點和工作節點的安裝過程。文章中還會提及一些參考資料和解決常見錯誤的方法。
在現今數位化的時代,網路攻擊頻率持續上升,其中又以DDoS攻擊最為常見且具破壞性。面對這種威脅,企業如何保護自身的網路資源成為了一大挑戰。CDN(內容傳遞網絡)作為一種有效的防禦工具,不僅能提升網站的性能與用戶體驗,還能大幅降低DDoS攻擊的風險。
DNS 和 SEO 緊密相關,擁有一個載入速度更快的網站將為您的訪客帶來卓越的用戶體驗,Google 也更喜歡快速載入的網域,閱讀本文了解更多關於 DNS 的小知識! DNS(網域名稱系統)是什麼? 全名為 Domain Name System,是一種分散的分層結構,DNS 將網域名稱(電腦、服
Thumbnail
內容交付網路(CDN)是一種網路架構,旨在提高用戶訪問網站內容的速度和效能。其基本原則是將網站內容分佈在全球的伺服器節點上。當使用者訪問網站時,CDN會根據使用者的地理位置和網路狀況,自動從最近的節點傳送內容,降低數據傳輸。
Thumbnail
安裝環境需求 64位元Linux,核心版本為3.1以上,且能滿足Ducker安裝環境。 機器之間要能夠互通。 外部存取權限。 硬體資源:兩核心CPU、8G記憶體、硬碟30GB以上。 安裝Kubeadm與Ducker Kubeadm是Kubernetes的一鍵部署工具。 增加Kube
Thumbnail
在實際生產中,容器化技術開始走向「容器編排技術」,如:Kubernetes。因為Docker無法獨立支撐大規模容器化部署。 Kubernetes起源於Borg系統,所以在大規模的叢集管理,優於其他容器編排技術。它提供拉取映像檔、拉取執行容器、路由閘道、水平擴充、監控和備份等,除外還可以自動化處理容
Thumbnail
本文介紹如何在GCP上使用Terraform建立CloudFlare DNS解析和模組化。通過閱讀本文,可以瞭解如何設置Terraform建立CloudFlare DNS解析以及取得GCS上的Terraform state file並透過Terraform建立CloudFlare DNS解析的步驟。
Thumbnail
在開發前後端分離架構時,使用兩個不同網域所遇到跨域請求問題。特別是在POST請求時行為差異大,揭示了「簡單請求」與「預檢請求」的關鍵差異。簡單請求不需預檢,但application/json會觸發預檢請求,需透過特定設定解決。分享這篇文章希望幫助開發者有效處理跨域問題。
Thumbnail
前言 上次我們針對 Docker 這樣容器化技術做了一點介紹,今天我們要來講解 Docker 架構,你是否發現在每次程式上伺服器的流程很麻煩呢 ? 是否發現你寫的程式在別的作業系統不能用呢 ? 如果你遇到這些問題,Docker 都可以幫助你解決這些問題 Docker 架構 在 Docker 這
Thumbnail
在這篇教學文章中,我們將展示如何使用 Node.js 建立一個簡單的伺服器,並解決常見的跨來源資源共享(CORS)問題,確保伺服器能夠接收並處理來自不同來源的資料。
Thumbnail
這篇文章將提供一個完整的Kubernetes安裝指南,包括控制平面節點和工作節點的安裝過程。文章中還會提及一些參考資料和解決常見錯誤的方法。
在現今數位化的時代,網路攻擊頻率持續上升,其中又以DDoS攻擊最為常見且具破壞性。面對這種威脅,企業如何保護自身的網路資源成為了一大挑戰。CDN(內容傳遞網絡)作為一種有效的防禦工具,不僅能提升網站的性能與用戶體驗,還能大幅降低DDoS攻擊的風險。
DNS 和 SEO 緊密相關,擁有一個載入速度更快的網站將為您的訪客帶來卓越的用戶體驗,Google 也更喜歡快速載入的網域,閱讀本文了解更多關於 DNS 的小知識! DNS(網域名稱系統)是什麼? 全名為 Domain Name System,是一種分散的分層結構,DNS 將網域名稱(電腦、服
Thumbnail
內容交付網路(CDN)是一種網路架構,旨在提高用戶訪問網站內容的速度和效能。其基本原則是將網站內容分佈在全球的伺服器節點上。當使用者訪問網站時,CDN會根據使用者的地理位置和網路狀況,自動從最近的節點傳送內容,降低數據傳輸。
Thumbnail
安裝環境需求 64位元Linux,核心版本為3.1以上,且能滿足Ducker安裝環境。 機器之間要能夠互通。 外部存取權限。 硬體資源:兩核心CPU、8G記憶體、硬碟30GB以上。 安裝Kubeadm與Ducker Kubeadm是Kubernetes的一鍵部署工具。 增加Kube
Thumbnail
在實際生產中,容器化技術開始走向「容器編排技術」,如:Kubernetes。因為Docker無法獨立支撐大規模容器化部署。 Kubernetes起源於Borg系統,所以在大規模的叢集管理,優於其他容器編排技術。它提供拉取映像檔、拉取執行容器、路由閘道、水平擴充、監控和備份等,除外還可以自動化處理容
Thumbnail
本文介紹如何在GCP上使用Terraform建立CloudFlare DNS解析和模組化。通過閱讀本文,可以瞭解如何設置Terraform建立CloudFlare DNS解析以及取得GCS上的Terraform state file並透過Terraform建立CloudFlare DNS解析的步驟。
Thumbnail
在開發前後端分離架構時,使用兩個不同網域所遇到跨域請求問題。特別是在POST請求時行為差異大,揭示了「簡單請求」與「預檢請求」的關鍵差異。簡單請求不需預檢,但application/json會觸發預檢請求,需透過特定設定解決。分享這篇文章希望幫助開發者有效處理跨域問題。
Thumbnail
前言 上次我們針對 Docker 這樣容器化技術做了一點介紹,今天我們要來講解 Docker 架構,你是否發現在每次程式上伺服器的流程很麻煩呢 ? 是否發現你寫的程式在別的作業系統不能用呢 ? 如果你遇到這些問題,Docker 都可以幫助你解決這些問題 Docker 架構 在 Docker 這