前言
CoreDNS
近日在工作中修改DNS，由於CoreDNS pod數量比較多，習慣性的使用腳本批量重啟，隨之引發了nginx ingress的告警，有大量超時的請求發生，開始並未意識到是修改CoreDNS的原因，后來看故障時間與批量重啟時間一致，才意識到是同一個問題，K8S 內部service通信其實也要經過CoreDNS。同時發現這塊監控缺失，亡羊補牢，為時不晚，添加監控，規范操作，避免此類低級問題再次出現。
CoreDNS簡介
CoreDNS 是一個從 Caddy 中 Fork 出來的項目（同時繼承了它的鏈式中間件風格），作為 CNCF 項目中的一員，它的目標是提供一個快速且靈活的 DNS 服務。
CoreDNS在Kubernetes1.11版本已經做為GA功能釋放，成為Kubernetes默認的DNS服務替代了Kube-DNS，目前是kubeadm、kube-up、minikube和kops安裝工具的默認選項。
監控CoreDNS
開啟CoreDNS性能指標
前提是需有一套K8S集群，使用CoreDNS作為內部的域名解析系統，同時集群內設置了Prometheus作為指標收集。
$ kubectl edit deployment coredns -n kube-system
.....
34 metadata:
35 annotations:
36 prometheus.io/path: /metrics
37 prometheus.io/port: "9153"
38 prometheus.io/scrape: "true"
39 creationTimestamp: null
.....
$ kubectl edit svc kube-dns -n kube-system
...
- name: metrics
port: 9153
protocol: TCP
targetPort: 9153
...
默認監聽的地址為: :9253/metrics，在Prometheus中配置target之后就可以采集coredns性能數據了。
- job_name: coredns
static_configs:
- targets:
- xxx:9153
labels:
instance: coredns
CoreDNS性能指標列表
| 指標名稱 | 指標類型 | 描述 |
|---|---|---|
| coredns_dns_request_count_total | counter | 服務端記錄所有請求查詢的累計值，單位：次 |
| coredns_dns_request_duration_seconds | histogram | 服務端每個查詢所消耗的時間分布，單位：秒 |
| coredns_dns_request_size_bytes | histogram | 客戶端通過UDP傳遞的EDNS0數據包大小分布，單位：字節 |
| coredns_dns_request_do_count_total | counter | 客戶端設置了DO標志位的請求次數累計值，單位：次 |
| coredns_dns_request_type_count_total | counter | 請求查詢記錄類型的累計值，單位：次 |
| coredns_dns_response_size_bytes | histogram | 服務端響應客戶端數據包大小分布，單位：字節 |
| coredns_dns_response_rcode_count_total | counter | 服務端響應狀態碼次數的累計值，單位：次 |
| coredns_panic_count_total | counter | 進程出現異常中斷次數的累計值，單位：次 |
| coredns_plugin_enabled | gauge | 插件的啟用情況 |
| coredns_build_info | gauge | 編譯的版本信息 |
CoreDNS監控指標
coredns_dns_request_count_total指標
| 名稱 | 說明 |
|---|---|
| server | 客戶端請求解析所使用的dns服務端地址 |
| zone | 客戶端請求解析所匹配到服務端設置的zone |
| proto | 響應傳輸層的協議，值：tcp或udp |
| family | 網絡層IP協議版本，值：1(ipv4),2(ipv6) |
coredns_dns_request_size_bytes指標
| 名稱 | 說明 |
|---|---|
| server | 客戶端請求解析所使用的dns服務端地址 |
| zone | 客戶端請求解析所匹配到服務端設置的zone |
| proto | 響應傳輸層的協議，值：tcp或udp |
| le | 通過UDP傳遞的EDNS0數據包大小分布情況，單位字節 |
le維度取值范圍：0, 100, 200, 300, 400, 511, 1023, 2047, 4095, 8291, 16000, 32000, 48000, 64000
coredns_dns_request_duration_seconds指標
| 名稱 | 說明 |
|---|---|
| server | 客戶端請求解析所使用的dns服務端地址 |
| zone | 客戶端請求解析所匹配到服務端設置的zone |
| le | 請求所消耗的時間，單位秒 |
le維度取值范圍：0.00025，0.0005，..., 后一個以前值的2被數增加，最多16個，最后一個lnf為無窮大。
coredns_dns_request_type_count_total指標
| 名稱 | 說明 |
|---|---|
| server | 客戶端請求解析所使用的dns服務端地址 |
| zone | 客戶端請求解析所匹配到服務端設置的zone |
| type | DNS解析類型 |
DNS記錄類型：
| 解析記錄 | 說明 |
|---|---|
| AAAA | IPv6地址 |
| A | IPv4地址 |
| CNAME | 一個域名 |
| DNSKEY | 在DNSSEC內使用的關鍵記錄 |
| DS | 委托簽發者，用於鑒定DNSSEC已授權區域的簽名密鑰 |
| MX | 電郵交互記錄，引導域名到該域名的郵件傳輸代理列表 |
| NSEC | DNSSEC的一部分，用來驗證一個未存在的服務器，使用與NXT記錄的格式 |
| NS | 名稱服務器記錄，指定DNS區域使用已有的權威域名服務器 |
| PTR | 指針記錄，最常用來運行反向DNS查找 |
| RRSIG | DNSSEC 安全記錄集證書 |
| SOA | 權威記錄的起始，指定有關DNS區域的權威性信息 |
| SRV | 服務定位器，被新式協議使用而避免產生特定協議的記錄，例如：MX 記錄 |
| TXT | 文本記錄 |
| IXFR | 增量區域轉移，請求只有與先前流水式編號不同的特定區域的區域轉移 |
| AXFR | 全域轉移，由主域名服務器轉移整個區域文件至二級域名服務器 |
| ANY | 所有緩存的記錄或者全部已知的記錄類型 |
coredns_dns_response_size_bytes指標
| 名稱 | 說明 |
|---|---|
| server | 客戶端請求解析所使用的dns服務端地址 |
| zone | 客戶端請求解析所匹配到服務端設置的zone |
| proto | 響應傳輸層的協議，值：tcp或udp |
| le | 響應返回客戶端的數據大小，單位：字節 |
le維度取值范圍：0, 100, 200, 300, 400, 511, 1023, 2047, 4095, 8291, 16000, 32000, 48000, 64000
coredns_panic_count_total指標
進程出現中斷的次數
coredns_dns_response_rcode_count_total指標
| 名稱 | 說明 |
|---|---|
| server | 客戶端請求解析所使用的dns服務端地址 |
| zone | 客戶端請求解析所匹配到服務端設置的zone |
| rcode | 相應狀態碼 |
常見狀態碼:
| DNS響應狀態碼 | 說明 |
|---|---|
| NOERROR | 查詢請求成功完成 |
| FORMERR | 查詢請求格式錯誤 |
| SERVFAIL | 服務端處理失敗 |
| NXDOMAIN | 請求查詢的域名不存在 |
| NOTIMP | 功能未實現 |
| REFUSED | 服務端拒絕回復該查詢 |
結束語
希望大家對生產環境有一顆敬畏之心，操作需要謹慎再謹慎。目前CoreDNS以上每個基本指標都已經做了監控，可能方式比較low，但是好勝於無，以后慢慢優化吧。如果有不對的地方，歡迎大家批評指正，共同學習。