https://hub.docker.com/r/coredns/coredns/
https://github.com/coredns/coredns/releases
https://coredns.io/plugins/
https://github.com/coredns/coredns/tree/master/plugin/etcd
https://kubernetes.io/zh/docs/concepts/services-networking/dns-pod-service/
1.安装etcd
https://abc.htmltoo.com/thread-46142.htm
cd /opt/app/etcd
export ETCDCTL_API=3
---A记录
./etcdctl put /coredns/com/leffss/www '{"host":"1.1.1.1","ttl":10}'
OK
etcd的目录结构和域名是相反的，即上面表示域名：www.leffss.com
ttl值设置60s后，coredns每60s才会到etcd读取这个域名的记录一次
-查询结果：
dig @localhost +short www.leffss.com
1.1.1.1
---如果想添加多条记录，让coredns轮询，方法如下：
./etcdctl put /coredns/com/leffss/www/x1 '{"host":"1.1.1.2","ttl":10}'
OK
./etcdctl put /coredns/com/leffss/www/x2 '{"host":"1.1.1.3","ttl":10}'
OK
-添加/coredns/com/leffss/www/x1、x2后，请求www.leffss.com就不会再读取/coredns/com/leffss/www，可以使用etcdctl del /coredns/com/leffss/www删除值
-查询结果：
dig @localhost +short www.leffss.com
1.1.1.2
1.1.1.3
-**注意：**如果想让取消设置的轮询值，需要删除/coredns/com/leffss/www/x1与/coredns/com/leffss/www/x2
---CNAME记录
./etcdctl put /coredns/com/leffss/www '{"host":"www.baidu.com","ttl":10}'
OK
-查询结果：
dig -t CNAME @localhost +short www.leffss.com
www.baidu.com
这里cname设置成外部百度域名，按理说coredns应该也把这个cname记录继续解析成www.baidu.cm的IP地址，但是经过测试发现请求www.leffss.com只能解析到CNAME：www.baidu.com，无法继续解析，原因未知，以后研究
2.安装coredns
https://github.com/coredns/coredns/releases
tar zxvf coredns_1.3.0_linux_amd64.tgz
mv coredns /usr/bin
mkdir /etc/coredns
vi /etc/coredns/Corefile
.:53 { # 监听tcp和udp的53端口
etcd { # 配置启用etcd插件,后面可以指定域名,例如 etcd test.com {
stubzones # 启用存根区域功能。 stubzone仅在位于指定的第一个区域下方的etcd树中完成
path /coredns # etcd里面的路径 默认为/skydns，以后所有的dns记录就是存储在该存根路径底下
endpoint http://localhost:2379 # etcd访问地址，多个空格分开
# upstream设置要使用的上游解析程序解决指向外部域名的在etcd（认为CNAME）中找到的外部域名。
upstream 8.8.8.8:53 8.8.4.4:53 /etc/resolv.conf
fallthrough # 如果区域匹配但不能生成记录，则将请求传递给下一个插件
# tls CERT KEY CACERT # 可选参数，etcd认证证书设置
}
prometheus # 监控插件
cache 160
loadbalance # 负载均衡，开启DNS记录轮询策略
proxy . 8.8.8.8:53 8.8.4.4:53 /etc/resolv.conf # 上面etcd未查询到的请求转发给设置的DNS服务器解析
log # 打印日志
}
-启动
nohup /usr/bin/coredns -conf /etc/coredns/Corefile > /tmp/coredns.log 2>&1 &
-验证
dig +short @localhost www.baidu.com
www.a.shifen.com.
61.135.169.121
61.135.169.125
#默认的CoreDns的配置文件
.:53 {
errors
health
kubernetes cluster.local in-addr.arpa ip6.arpa {
pods insecure
upstream
fallthrough in-addr.arpa ip6.arpa
}
prometheus :9153
forward . /etc/resolv.conf
cache 30
loop
reload
loadbalance
}error: 错误记录到stdout
health ：CoreDNS的运行状况报告为 http://localhost:8080/health
kubernetes ：CoreDNS将根据Kubernetes服务和pod的IP回复DNS查询
prometheus ：CoreDNS的度量标准可以在 http://localhost:9153/ Prometheus格式的 指标 中找到
proxy ：任何不在Kubernetes集群域内的查询都将转发到预定义的解析器（/etc/resolv.conf）
cache ：启用前端缓存
loop ：检测简单的转发循环，如果找到循环则停止CoreDNS进程
reload ：允许自动重新加载已更改的Corefile。编辑ConfigMap配置后，请等待两分钟以使更改生效
loadbalance ：这是一个循环DNS负载均衡器，可以在答案中随机化A，AAAA和MX记录的顺序
# 动态域名增加案例
etcd [ZONES...] {
stubzones
fallthrough
path PATH
endpoint ENDPOINT...
upstream ADDRESS...
tls CERT KEY CACERT
}
ZONES :经过授权的区域，可以为空
stubzones：启用存根区域功能。 stubzone仅在位于指定的第一个区域下方的etcd树中完成。
fallthrough：如果区域匹配但不能生成记录，则将请求传递给下一个插件
path：etcd里面的路径 默认为“/ skydns”，以后所有的dns记录就是存储在该存根路径底下
endpoint：etcd访问地址，默认http://localhost:2397
upstream：要使用的上游解析程序解决指向外部域名的在etcd（认为CNAME）中找到的外部域名。 如果您希望CoreDNS作为客户端的代理，您需要添加代理插件。 ADDRESS可以是一个IP地址，IP：端口或一个字符串，指向一个被构造为/etc/resolv.conf的文件。
tls 后面紧跟：
没有参数，如果服务器证书由系统安装的CA签名，并且不需要客户端证书
一个参数是CA PEM文件，如果服务器证书没有被系统CA签名，并且不需要客户端证书
两个参数 - 认证PEM文件的路径，私钥PEM文件的路径 - 如果服务器证书由系统安装的CA签名并需要客户端证书
三个参数 - 认证PEM文件的路径，客户端私钥PEM文件的路径，CA PEM文件的路径 - 如果服务器证书未被系统安装的CA签名，并且需要客户端证书
举例：http://172.16.80.175:8080/
现在我们为该地址动态增加域名：coredns.dynamic.com.test
etcd {
stubzones
path /skydns
endpoint http://172.16.71.200:2379
upstream /etc/resolv.conf
}
那么我们只需要向etcd中添加一条如下的记录：
curl -XPUT http://172.16.71.200:2379/v2/keys/skydns/test/com/dynamic/coredns -d value='{"host":"172.16.80.175","port":8080}'
注意：test/com/dynamic/coredns的顺序和coredns.dynamic.com.test是相反的。
添加了这样一条记录之后，我们就可以用coredns.dynamic.com.test:8080来访问刚才的tomcat了
假如etcd插件定义为：
etcd com.test{
stubzones
path /skydns
endpoint http://172.16.71.200:2379
upstream /etc/resolv.conf
}那么必须是 /test/com/*/*的域名才能访问。
curl -XPUT http://172.16.71.200:2379/v2/keys/skydns/test/com/dynamic/coredns -d value='{"host":"172.16.80.175","port":8080}'
# 反向域名解析
需要将172.16.80.175指向hzb.test.com，Corefile应该进行如下配置：
.:53 {
etcd test.com 172.in-addr.arpa {
stubzones
path /skydns
endpoint http://172.16.71.200:2379
upstream /etc/resolv.conf
}
log stdout
errors stdout
proxy . /etc/resolv.conf
}
还需要向etcd中增加一条如下的记录：
curl -XPUT http://172.16.71.200:2379/v2/keys/skydns/arpa/in-addr/172/16/80/175 -d value='{"host":"hzb.test.com"}'
查询测试:
dig @localhost -x 172.16.80.175 +short
hzb.test.com
# 为什么需要服务发现
在集群内需要能够通过服务名进行服务访问, 需要一个集群范围内的dns服务来完成从服务名到clusterIP的解析
dns服务工作原理： 监控kubernetes中的service资源的变化, 根据service的名称和ip地址生成dns记录
coredns服务监视kubernetes api , 为每一个service创建dns记录用于域名解析;这样访问pod资源资源只需要访问service名即可，而不需要关系pod容器的ip地址的变化;
# coredns简介
CoreDNS是一个DNS服务器，和Caddy Server具有相同的模型：它链接插件。CoreDNS是云本土计算基金会启动阶段项目。
CoreDNS是SkyDNS的继任者。 SkyDNS是一个薄层，暴露了DNS中的etcd中的服务。 CoreDNS建立在这个想法上，是一个通用的DNS服务器，可以与多个后端（etcd，kubernetes等）进行通信。
CoreDNS旨在成为一个快速灵活的DNS服务器。 这里的关键灵活指的是：使用CoreDNS，您可以使用DNS数据进行所需的操作。 还可以自已写插件来实现DNS的功能。
CoreDNS可以通过UDP / TCP（旧式的DNS），TLS（RFC 7858）和gRPC（不是标准）监听DNS请求。
CoreDNS目前支持的行为，括号里面的英文表示插件：
从文件提供区域数据; 支持DNSSEC（仅限NSEC）和DNS（file）。
从主机检索区域数据，即充当辅助服务器（仅限AXFR）（secondary）。
快速签署区域数据（dnssec）
响应负载均衡（loadbalance）
允许区域传输，即充当主服务器（file）
从磁盘自动加载区域文件（auto）
缓存（cache）
对endpoint的健康检查（health）
使用ETCD作为后端，即SkyDNS（ETCD）的101.5％替换（etcd）
使用k8s（kubernetes）作为后端（kubernetes）
作为一个代理转发查询到一些其他（递归）域名服务器（proxy）
提供指标（使用Prometheus）（metrics）
提供查询（log）和错误（errors）日志记录
支持CH类：version.bind和friends（chaos）
分析支持（pprof）
重写查询（qtype，qclass和qname）（rewrite）
回传所使用的IP地址，传输和端口号（whoami）
