通过一起重启coredns操作引发的故障延伸至coredns监控
前言
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，但是好胜于无，以后慢慢优化吧。如果有不对的地方，欢迎大家批评指正，共同学习。
