Coredns容器部署
Coredns容器部署
1. 基本概念
CoreDNS 是 Golang 编写的一个插件式 DNS 服务器，是 Kubernetes 1.13 后所内置的默认 DNS 服务器。CoreDNS 的目标是成为 cloud-native 环境下的 DNS 服务器和服务发现解决方案。
官网： https://coredns.io/
Github： https://github.com/coredns/coredns
特性：
- 插件化（Plugins）
基于 Caddy 服务器框架，CoreDNS 实现了一个插件链的架构，将大量应用端的逻辑抽象成 plugin 的形式（如 Kubernetes 的 DNS 服务发现，Prometheus 监控等）暴露给使用者。CoreDNS 以预配置的方式将不同的 plugin 串成一条链，按序执行 plugin 的逻辑。从编译层面，用户选择所需的 plugin 编译到最终的可执行文件中，使得运行效率更高。CoreDNS 采用 Go 编写，所以从具体代码层面来看，每个 plugin 其实都是实现了其定义的 interface 的组件而已。第三方只要按照 CoreDNS Plugin API 去编写自定义插件，就可以很方便地集成于 CoreDNS。
- 配置简单化
引入表达力更强的 DSL，即 Corefile 形式的配置文件（也是基于 Caddy 框架开发）。
- 一体化的解决方案
区别于 kube-dns，CoreDNS 编译出来就是一个单独的二进制可执行文件，内置了 cache，backend storage，health check 等功能，无需第三方组件来辅助实现其他功能，从而使得部署更方便，内存管理更为安全。
2. 部署测试
2.1安装软件包
yum -y install bind-utils docker-ce docker-compose
# 添加daemon.json文件, 红色字体根据客户环境进行替换
cat << EOF > /etc/docker/daemon.json
{
"oom-score-adjust": -1000,
"log-driver": "json-file",
"log-opts": {
"max-size": "100m",
"max-file": "3"
},
"registry-mirrors": ["https://7bezldxe.mirror.aliyuncs.com"],
"max-concurrent-downloads": 5,
"max-concurrent-uploads": 5,
"storage-driver": "overlay2",
"storage-opts": [
"overlay2.override_kernel_check=true"
]
}
EOF
#启动docker
systemctl enable –now docker
#创建安装目录 //目录供参考
mkdir –p /root/coredns
上传docker-compose.yml到coredns目录
#启动
docker-compose up –d
#检查是否运行正常
docker-compose ps
2.2测试
2.2.1修改corefile
Corefile释义 https://coredns.io/manual/toc/#configuration
log 释义 https://coredns.io/plugins/log/
#本次测试的server是private.cloud
[root@test01 config]# cat corefile
.:53 {
forward . 114.114.114.114 223.5.5.5
log
errors
}
private.cloud:53 {
file /etc/coredns/cloud.org
log
errors
cache
}
#配置文件释义:
每个括号中的部分都表示一个 DNS“区域”
.:53，表示该区域是全局的（“.”表示所有流量），并且它正在侦听端口 53（默认为 udp）。我们在此处设置的参数将应用于所有未指定特定区域的传入 DNS 查询，例如要解析的查询github.com。我们在下一行看到，我们将此类请求转发到辅助 DNS 服务器进行解析；在这种情况下，对该区域的所有请求都将简单地转发到位于114.114.114.114和 的Aliyun DNS 服务器223.5.5.5。
private.cloud为本次测试指定的域名，也侦听 UDP 端口 53。对属于该区域的主机的任何查询都将引用文件数据库（类似于 bind 的方式）在那里进行查找；更多关于这一点。例如，对“server.private.cloud”的查询将绕过“.”的全局区域。并落入为“private.cloud”提供服务的区域，并使用该file指令将引用数据库文件以找到正确的记录
2.2.3编写test.org
#vim cloud.org
private.cloud. IN SOA dns.private.cloud. robbmanes.private.cloud. 2015082541 7200 3600 1209600 3600
mysql.private.cloud. IN A 10.1.0.1
redis.private.cloud. IN A 10.1.0.1
rabbitmq.private.cloud. IN A 10.1.0.1
elasticsearch.private.cloud. IN A 10.1.0.1
kafka.private.cloud. IN A 10.1.0.1
mongo.private.cloud. IN A 10.1.0.1
postgres.private.cloud. IN A 10.1.0.1
geoserver.private.cloud. IN A 10.1.0.1
registry.private.cloud. IN A 10.1.0.2
discovery.private.cloud. IN A 10.1.0.2
gateway.private.cloud. IN A 10.1.0.3
monitor.private.cloud. IN A 10.1.0.3
xxl.private.cloud. IN A 10.1.0.3
#soa配置文件参考
https://docs.aws.amazon.com/zh_cn/Route53/latest/DeveloperGuide/SOA-NSrecords.html
2.2.4重启服务
docker-compose restart
2.2.5测试
#预期结果:dig解析出的A记录应与cloud.org中的配置一致。
#验证
结果可见下图：
