Linux运维实战技术
资源放送
coredns技术教程讲解
↓ 扫一扫 视频在线观看↓
CoreDNS是一个灵活可扩展的DNS服务器，可以作为Kubernetes集群DNS，在Kubernetes1.12版本之后成为了默认的DNS服务。与Kubernetes一样，CoreDNS项目由CNCF托管。
coredns在K8S中的用途,主要是用作服务发现，也就是服务(应用)之间相互定位的过程。
在k8s中，用service资源代理pod，通过暴露service资源的固定地址(集群IP)，来解决以上POD资源变化产生的IP变动问题，但是针对service还存在以下问题：
service IP地址难以记忆；
service资源可能也会被销毁和创建；
pod ip本身也有需要暴漏的需求。
为了解决以上问题，引入了coredns，在K8S，其主要用于服务发现，也就是服务(应用)之间相互定位的过程。
coredns部署参考：
部署后，可在dns中，通过如下命令查询coredns是否运行正常：
dig @127.0.0.1 -p 53 www.example.com
3.1 K8s DNS策略
Kubernetes中Pod的DNS策略有四种类型：
① Default：Pod继承所在主机上的DNS配置；
② ClusterFirst：K8s的默认设置；先在K8s集群配置的coreDNS中查询，查不到的再去继承自主机的上游nameserver中查询；
③ ClusterFirstWithHostNet：对于网络配置为hostNetwork的Pod而言，其DNS配置规则与ClusterFirst一致；
④ None：忽略K8s环境的DNS配置，只认Pod的dnsConfig设置。
3.2 resolv.conf
在部署pod的时候，如果用的是K8s集群的DNS，那么kubelet在起pause容器的时候，会将其DNS解析配置初始化成集群内的配置。
如创建了一个叫my-nginx的deployment，其pod中的resolv.conf文件如下：
# DNS 服务的 IP，即coreDNS 的 clusterIP nameserver 169.254.25.10 # DNS search 域。解析域名的时候，将要访问的域名依次带入 search 域，进行 DNS 查询 # 比如访问your-nginx，其进行的 DNS 域名查询的顺序是：your-nginx.default.svc.cluster.local. -> your-nginx.svc.cluster.local. -> your-nginx.cluster.local. search default.svc.cluster.local svc.cluster.local cluster.local # 其他项，最常见的是 dnots。dnots 指的是如果查询的域名包含的点 “.” 小于 5，则先走search域，再用绝对域名；如果查询的域名包含点数大于或等于 5，则先用绝对域名，再走search域 # K8s 中默认的配置是 5。 options ndots:5
3.3 coreDNS Corefile文件
CoreDNS实现了应用的插件化，用户可以选择所需的插件编译到可执行文件中；CoreDNS的配置文件是Corefile形式的，coreDNS的configMap如下所示：
apiVersion: v1
data:
Corefile: |
.:53 {
errors
health
# 指明 cluster.local 后缀的域名，都是 kubernetes 内部域名，coredns 会监听 service 的变化来维护域名关系，所以cluster.local 相关域名都在这里解析
kubernetes cluster.local in-addr.arpa ip6.arpa {
pods insecure
upstream
fallthrough in-addr.arpa ip6.arpa
}
# CoreDNS 的监控地址为：http://localhost:9153/metrics
prometheus :9153
# proxy 指 coredns 中没有找到记录，则去 /etc/resolv.conf 中的 nameserver 请求解析，而 coredns 容器中的 /etc/resolv.conf 是继承自宿主机的。
# 实际效果是如果不是 k8s 内部域名，就会去默认的 dns 服务器请求解析，并返回给 coredns 的请求者。
forward . /etc/resolv.conf
cache 30 # 允许缓存
loop # 如果找到循环，则检测简单的转发循环并停止 CoreDNS 进程
reload # 允许 Corefile 的配置自动更新。在更改 ConfigMap 后两分钟，修改生效
loadbalance # 这是一个循环 DNS 负载均衡器，可以在答案中随机化 A，AAAA 和 MX 记录的顺序
}
kind: ConfigMap
metadata:
creationTimestamp: "2019-06-10T03:19:01Z"
name: coredns
namespace: kube-system4.1 DNS间歇性5秒延迟
由于Linux内核中的缺陷，在Kubernetes集群中你很可能会碰到恼人的DNS间歇性5秒延迟问题。
原因是镜像底层库DNS解析行为默认使用UDP在同一个socket并发A和AAAA记录请求，由于UDP无状态，两个请求可能会并发创建conntrack表项，如果最终DNAT成同一个集群DNS的Pod IP就会导致conntrack冲突，由于conntrack的创建和插入是不加锁的，最终后面插入的conntrack表项就会被丢弃，从而请求超时，默认5s后重试，造成现象就是DNS 5秒延时。
4.2 NodeLocal DNSCache
NodeLocal DNSCache通过在集群上运行一个dnsCache daemonset来提高clusterDNS性能和可靠性。相比于纯coredns方案，nodelocaldns + coredns方案能够大幅降低DNS查询timeout的频次，提升服务稳定性。
nodelocaldns配置如下，nodelocaldns只配置了一个server，监听默认的UDP 53端口，4个zone。域名后缀为cluster.local的所有域名以及in-addr.arpa和ip6.arpa形式域名走coredns进行域名解析，其他外部域名使用宿主机的/etc/resolv.conf文件配置的nameserver进行解析。
缓存分为256个分片，每个分片默认最多可容纳39个项目-总大小为256*39=9984个项目。
# 其中cluster.local、in-addr.arpa、ip6.arpa表示kubernetes插件会处理域名后缀为cluster.local的所有域名以及处理所有的in-addr.arpa中的反向dns查找和ip6.arpa形式域名，其中kuberne# 集群域名后缀是在kubelet参数中配置的，默认值为cluster.local
apiVersion: v1
data:
Corefile: |
cluster.local:53 {
errors
cache {
success 9984 30 # 对于成功的缓存最多缓存9984条域名解析记录，缓存时间为30s
denial 9984 5 # 对于失败的缓存最多缓存9984条域名解析记录，缓存时间为5s
}
reload
loop
bind 169.254.25.10
forward . 10.233.0.3 {
force_tcp
}
prometheus :9253
health 169.254.25.10:9254
}
in-addr.arpa:53 {
errors
cache 30
reload
loop
bind 169.254.25.10
forward . 10.233.0.3 {
force_tcp
}
prometheus :9253
}
ip6.arpa:53 {
errors
cache 30
reload
loop
bind 169.254.25.10
forward . 10.233.0.3 {
force_tcp
}
prometheus :9253
}
.:53 {
errors
cache 30
reload
loop
bind 169.254.25.10
forward . /etc/resolv.conf
prometheus :9253
}
kind: ConfigMap
......nodelocaldns+coredns方案，DNS查询流程如下所示：
推荐阅读
