本篇文章主要围绕两种 DNS Server 的实现方式展开，会比较两种 Server 的优缺点。
在说两个 Service 之前，我们先来了解一下在k8s中域名是如何被解析的。
我们都知道，在 k8s 中，一个 Pod 如果要访问同 Namespace 下的 Service（比如 user-svc），那么只需要curl user-svc。如果 Pod 和 Service 不在同一域名下，那么就需要在 Service Name 之后添加上 Service 所在的 Namespace（比如 beta），curl user-svc.beta。那么 k8s 是如何知道这些域名是内部域名并为他们做解析的呢？
DNS In Kubernetes
/etc/resolv.conf
resolv.conf 是 DNS 域名解析的配置文件。每行都会以一个关键字开头，然后跟配置参数。这里主要使用到的关键词有3个。
- nameserver #定义 DNS 服务器的 IP 地址
- search #定义域名的搜索列表，当查询的域名中包含的
.的数量少于options.ndots的值时，会依次匹配列表中的每个值 - options #定义域名查找时的配置信息
那么我们进入一个 Pod 查看它的 resolv.conf
nameserver 100.64.0.10
search default.svc.cluster.local svc.cluster.local cluster.local
options ndots:5
这里的 nameserver、search 和 options 都是可以通过 dnsConfig 字段进行配置的，官方文档中已有详细的讲述
上述配置文件 resolv.conf 是 dnsPolicy: ClusterFirst 情况下，k8s 为 Pod 自动生成的，这里的 nameserver 所对应的地址正是 DNS Service 的Cluster IP（该值在启动 kubelet 的时候，通过 clusterDNS 指定）。所以，从集群内请求的所有的域名解析都需要经过 DNS Service 进行解析，不管是 k8s 内部域名还是外部域名。
可以看到这里的 search 域默认包含了 namespace.svc.cluster.local、svc.cluster.local 和 cluster.local 三种。当我们在 Pod 中访问 a Service时（ curl a ），会选择nameserver 100.64.0.10 进行解析，然后依次带入 search 域进行 DNS 查找，直到找到为止。
# curl a
a.default.svc.cluster.local
显然因为 Pod 和 a Service 在同一 Namespace 下，所以第一次 lookup 就能找到。
如果 Pod 要访问不同 Namespace（例如： beta ）下的 Service b （ curl b.beta ），会经过两次 DNS 查找，分别是
# curl b.beta
b.beta.default.svc.cluster.local（未找到）
b.beta.svc.cluster.local（找到）
正是因为 search 的顺序性，所以访问同一 Namespace 下的 Service， curl a 是要比 curl a.default 的效率更高的，因为后者多经过了一次 DNS 解析。
# curl a
a.default.svc.cluster.local
# curl a.default
b.default.default.svc.cluster.local（未找到）
b.default.svc.cluster.local（找到）
那么当Pod中访问外部域名时仍然需要走search域吗？
这个答案，不能说肯定也不能说否定，看情况，可以说，大部分情况要走 search 域。
以 domgoer.com 为例，通过抓包的方式，在某一个Pod中访问 domgoer.com ，可以看到 DNS 查找的过程，都产生了什么样的数据包。首先先进入 DNS 容器的网络。
ps: 由于 DNS 容器往往不具备 bash，所以不能通过 docker exec 的方式进入容器抓包，需要采用其他方法
// 1.找到容器ID，打印它的NS ID
docker inspect --format "{{.State.Pid}}" container_id
// 2.进入此容器的Namespace
nsenter -n -t pid
// 3.DNS抓包
tcpdump -i eth0 -N udp dst port 53
在其他容器中进行domgoer.com域名查找
nslookup domgoer.com dns_container_ip
指定 dns_container_ip，是为了避免有多个DNS容器的情况，DNS请求会分到各个容器。这样可以让 DNS 请求只发往这个地址，这样抓包的数据才会完整。
可以看到如下的结果：
17:01:28.732260 IP 172.20.92.100.36326 > nodexxxx.domain: 4394+ A? domgoer.com.default.svc.cluster.local. (50)
17:01:28.733158 IP 172.20.92.100.49846 > nodexxxx.domain: 60286+ A? domgoer.com.svc.cluster.local. (45)
17:01:28.733888 IP 172.20.92.100.51933 > nodexxxx.domain: 63077+ A? domgoer.com.cluster.local. (41)
17:01:28.734588 IP 172.20.92.100.33401 > nodexxxx.domain: 27896+ A? domgoer.com. (27)
17:01:28.734758 IP nodexxxx.34138 > 192.168.x.x.domain: 27896+ A? domgoer.com. (27)
可以看到在真正解析 domgoer.com 之前，经历了 domgoer.com.default.svc.cluster.local. -> domgoer.com.svc.cluster.local. -> domgoer.com.cluster.local. -> domgoer.com.
这样也就意味着有3次DNS请求是浪费的，没有意义的。
如何避免这样的情况
在研究如何避免之前可以下思考一下造成这种情况的原因。在 /etc/resolv.conf 文件中，我们可以看到 options 中有个配置项 ndots:5 。
ndots:5，表示：如果需要 lookup 的 Domain 中包含少于5个 . ，那么将使用非绝对域名，如果需要查询的 DNS 中包含大于或等于5个 . ，那么就会使用绝对域名。如果是绝对域名则不会走 search 域，如果是非绝对域名，就会按照 search 域中进行逐一匹配查询，如果 search 走完了都没有找到，那么就会使用 原域名.（domgoer.com.） 的方式作为绝对域名进行查找。
综上可以找到两种优化的方法
直接使用绝对域名
这是最简单直接的优化方式，可以直接在要访问的域名后面加上
.如：domgoer.com. ，这样就会避免走 search 域进行匹配。配置ndots
还记得之前说过 /etc/resolv.conf 中的参数都可以通过k8s中的
dnsConfig字段进行配置。这就允许你根据你自己的需求配置域名解析的规则。例如 当域名中包含两个
.或以上时，就能使用绝对域名直接进行域名解析。apiVersion: v1 kind: Pod metadata: namespace: default name: dns-example spec: containers: - name: test image: nginx dnsConfig: options: - name: ndots value: 2
Kubernetes DNS 策略
在k8s中，有4中DNS策略，分别是 ClusterFirstWithHostNet 、ClusterFirst 、Default 、和 None，这些策略可以通过 dnsPolicy 这个字段来定义
如果在初始化 Pod、Deployment 或者 RC 等资源时没有定义，则会默认使用 ClusterFirst 策略
ClusterFirstWithHostNet
当一个 Pod 以 HOST 模式（和宿主机共享网络）启动时，这个 POD 中的所有容器都会使用宿主机的/etc/resolv.conf 配置进行 DNS 查询，但是如果你还想继续使用 Kubernetes 的 DNS 服务，
就需要将 dnsPolicy 设置为 ClusterFirstWithHostNet。ClusterFirst
使用这是方式表示 Pod 内的 DNS 优先会使用 k8s 集群内的DNS服务，也就是会使用 kubedns 或者 coredns 进行域名解析。如果解析不成功，才会使用宿主机的 DNS 配置进行解析。
Default
这种方式，会让 kubelet 来绝定 Pod 内的 DNS 使用哪种 DNS 策略。kubelet 的默认方式，其实就是使用宿主机的 /etc/resolv.conf 来进行解析。你可以通过设置 kubelet 的启动参数，
–resolv-conf=/etc/resolv.conf 来决定 DNS 解析文件的地址None
这种方式顾名思义，不会使用集群和宿主机的 DNS 策略。而是和 dnsConfig 配合一起使用，来自定义 DNS 配置，否则在提交修改时报错。
kubeDNS
结构
kubeDNS由3个部分组成。
- kubedns: 依赖
client-go中的informer机制监视 k8s 中的Service和Endpoint的变化，并将这些结构维护进内存来服务内部 DNS 解析请求。 - dnsmasq: 区分 Domain 是集群内部还是外部，给外部域名提供上游解析，内部域名发往 10053 端口，并将解析结果缓存，提高解析效率。
- sidecar: 对 kubedns 和 dnsmasq 进行健康检查和收集监控指标。
以下是结构图
kubedns
在 kubedns 包含两个部分, kubedns 和 skydns。
其中 kubedns 是负责监听 k8s 集群中的 Service 和 Endpoint 的变化，并将这些变化通过 treecache 的数据结构缓存下来，作为 Backend 给 skydns 提供 Record。
而真正负责dns解析的其实是 skydns（skydns 目前有两个版本 skydns1 和 skydns2，下面所说的是 skydns2，也是当前 kubedns 所使用的版本）。
我们可以先看下 treecache，以下是 treecache 的数据结构
// /dns/pkg/dns/treecache/treecache.go#54
type treeCache struct {
ChildNodes map[string]*treeCache
Entries map[string]interface{}
}
我们再看一组实际的数据
{
"ChildNodes": {
"local": {
"ChildNodes": {
"cluster": {
"ChildNodes": {
"svc": {
"ChildNodes": {
"namespace": {
"ChildNodes": {
"service_name": {
"ChildNodes": {
"_tcp": {
"ChildNodes": {
"_http": {
"ChildNodes": {},
"Entries": {
"6566333238383366": {
"host": "service.namespace.svc.cluster.local.",
"port": 80,
"priority": 10,
"weight": 10,
"ttl": 30
}
},
}
},
"Entries": {}
}
},
"Entries": {
"3864303934303632": {
"host": "100.70.28.188",
"priority": 10,
"weight": 10,
"ttl": 30
}
}
}
},
"Entries": {}
}
},
"Entries": {}
}
},
"Entries": {}
}
},
"Entries": {}
}
},
"Entries": {}
}
treeCache 的结构类似于目录树。从根节点到叶子节点的每个路径与一个域名是相对应的，顺序是颠倒的。它的叶子节点只包含 Entries，非叶子节点只包含 ChildNodes。叶子节点中保存的就是 SkyDNS 定义的 msg.Service 结构，可以理解为 DNS 记录。
在 Records 接口方法实现中，只需根据域名查找到对应的叶子节点，并返回叶子节点中保存的所有msg.Service 数据。K8S 就是通过这样的一个数据结构来保存 DNS 记录的，并替换了 Etcd（ skydns2 默认使用 etcd 作为存储），来提供基于内存的高效存储。
我们可以直接阅读代码来了解 kubedns 的启动流程。
首先看它的结构体
// dns/cmd/kube-dns/app/server.go#43
type KubeDNSServer struct {
// DNS domain name. = cluster.local.
domain string
healthzPort int
// skydns启动的地址和端口
dnsBindAddress string
dnsPort int
nameServers string
kd *dns.KubeDNS
}
下来可以看到一个叫 NewKubeDNSServerDefault 的函数，它初始化了 KubeDNSServer。并执行 server.Run() 启动了服务。那么我们来看下 NewKubeDNSServerDefault 这个方法做了什么。
// dns/cmd/kube-dns/app/server.go#53
func NewKubeDNSServerDefault(config *options.KubeDNSConfig) *KubeDNSServer {
kubeClient, err := newKubeClient(config)
if err != nil {
glog.Fatalf("Failed to create a kubernetes client: %v", err)
}
// 同步配置文件，如果观察到配置信息改变，就会重启skydns
var configSync dnsconfig.Sync
switch {
// 同时配置了 configMap 和 configDir 会报错
case config.ConfigMap != "" && config.ConfigDir != "":
glog.Fatal("Cannot use both ConfigMap and ConfigDir")
case config.ConfigMap != "":
configSync = dnsconfig.NewConfigMapSync(kubeClient, config.ConfigMapNs, config.ConfigMap)
case config.ConfigDir != "":
configSync = dnsconfig.NewFileSync(config.ConfigDir, config.ConfigPeriod)
default:
conf := dnsconfig.Config{Federations: config.Federations}
if len(config.NameServers) > 0 {
conf.UpstreamNameservers = strings.Split(config.NameServers, ",")
}
configSync = dnsconfig.NewNopSync(&conf)
}
return &KubeDNSServer{
domain: config.ClusterDomain,
healthzPort: config.HealthzPort,
dnsBindAddress: config.DNSBindAddress,
dnsPort: config.DNSPort,
nameServers: config.NameServers,
kd: dns.NewKubeDNS(kubeClient, config.ClusterDomain, config.InitialSyncTimeout, configSync),
}
}
// 启动skydns server
func (d *KubeDNSServer) startSkyDNSServer() {
skydnsConfig := &server.Config{
Domain: d.domain,
DnsAddr: fmt.Sprintf("%s:%d", d.dnsBindAddress, d.dnsPort),
}
if err := server.SetDefaults(skydnsConfig); err != nil {
glog.Fatalf("Failed to set defaults for Skydns server: %s", err)
}
// 使用d.kd作为存储的后端，因为kubedns实现了skydns.Backend的接口
s := server.New(d.kd, skydnsConfig)
if err := metrics.Metrics(); err != nil {
glog.Fatalf("Skydns metrics error: %s", err)
} else if metrics.Port != "" {
glog.V(0).Infof("Skydns metrics enabled (%v:%v)", metrics.Path, metrics.Port)
} else {
glog.V(0).Infof("Skydns metrics not enabled")
}
d.kd.SkyDNSConfig = skydnsConfig
go s.Run()
}
可以看到这里 dnsconfig 会返回一个 configSync 的 interface 用来实时同步配置，也就是 kube-dns 这个 configmap，或者是本地的 dir（但一般来说这个 dir 也是由 configmap 挂载进去的）。在方法的最后 dns.NewKubeDNS 返回一个 KubeDNS 的结构体。那么我们看下这个函数初始化了哪些东西。
// dns/pkg/dnsdns.go#124
func NewKubeDNS(client clientset.Interface, clusterDomain string, timeout time.Duration, configSync config.Sync) *KubeDNS {
kd := &KubeDNS{
kubeClient: client,
domain: clusterDomain,
cache: treecache.NewTreeCache(),
cacheLock: sync.RWMutex{},
nodesStore: kcache.NewStore(kcache.MetaNamespaceKeyFunc),
reverseRecordMap: make(map[string]*skymsg.Service),
clusterIPServiceMap: make(map[string]*v1.Service),
domainPath: util.ReverseArray(strings.Split(strings.TrimRight(clusterDomain, "."), ".")),
initialSyncTimeout: timeout,
configLock: sync.RWMutex{},
configSync: configSync,
}
kd.setEndpointsStore()
kd.setServicesStore()
return kd
}
可以看到kd.setEndpointsStore() 和 kd.setServicesStore() 这两个方法会在 informer中注册 Service 和 Endpoint 的回调，用来观测这些资源的变动并作出相应的调整。
下面我们看下当集群中新增一个 Service,kubedns 会以怎样的方式处理。
// dns/pkg/dns/dns.go#499
func (kd *KubeDNS) newPortalService(service *v1.Service) {
// 构建了一个空的叶子节点, recordLabel是clusterIP经过 FNV-1a hash运算后得到的32位数字
// recordValue 的结构
// &msg.Service{
// Host: service.Spec.ClusterIP,
// Port: 0,
// Priority: defaultPriority,
// Weight: defaultWeight,
// Ttl: defaultTTL,
// }
subCache := treecache.NewTreeCache()
recordValue, recordLabel := util.GetSkyMsg(service.Spec.ClusterIP, 0)
subCache.SetEntry(recordLabel, recordValue, kd.fqdn(service, recordLabel))
// 查看service的ports列表，将每个port信息转换成skydns.Service并加入上面构建的叶子节点
for i := range service.Spec.Ports {
port := &service.Spec.Ports[i]
if port.Name != "" && port.Protocol != "" {
srvValue := kd.generateSRVRecordValue(service, int(port.Port))
l := []string{"_" + strings.ToLower(string(port.Protocol)), "_" + port.Name}
subCache.SetEntry(recordLabel, srvValue, kd.fqdn(service, append(l, recordLabel)...), l...)
}
}
subCachePath := append(kd.domainPath, serviceSubdomain, service.Namespace)
host := getServiceFQDN(kd.domain, service)
reverseRecord, _ := util.GetSkyMsg(host, 0)
kd.cacheLock.Lock()
defer kd.cacheLock.Unlock()
// 将构建好的叶子节点加入treecache
kd.cache.SetSubCache(service.Name, subCache, subCachePath...)
kd.reverseRecordMap[service.Spec.ClusterIP] = reverseRecord
kd.clusterIPServiceMap[service.Spec.ClusterIP] = service
}
再看一下当 Endpoint 添加到集群时，kubedns 会如何处理
// dns/pkg/dns/dns.go#460
func (kd *KubeDNS) addDNSUsingEndpoints(e *v1.Endpoints) error {
// 获取ep所属的svc
svc, err := kd.getServiceFromEndpoints(e)
if err != nil {
return err
}
// 判断这个svc，如果这个svc不是 headless，就不会处理此次添加，因为 svc 有 clusterIP 的情况，在处理
// svc 的增删改时已经都被处理了。所以当 ep 属于 headless svc 时，需要将这个 ep 加入到 cache
if svc == nil || v1.IsServiceIPSet(svc) || svc.Spec.Type == v1.ServiceTypeExternalName {
// No headless service found corresponding to endpoints object.
return nil
}
return kd.generateRecordsForHeadlessService(e, svc)
}
// 把 endpoint 添加到它所属的 headless service 的缓存下
func (kd *KubeDNS) generateRecordsForHeadlessService(e *v1.Endpoints, svc *v1.Service) error {
subCache := treecache.NewTreeCache()
generatedRecords := map[string]*skymsg.Service{}
// 遍历这个 ep 下所有的 ip+port，并将它们添加到 treecache 中
for idx := range e.Subsets {
for subIdx := range e.Subsets[idx].Addresses {
address := &e.Subsets[idx].Addresses[subIdx]
endpointIP := address.IP
recordValue, endpointName := util.GetSkyMsg(endpointIP, 0)
if hostLabel, exists := getHostname(address); exists {
endpointName = hostLabel
}
subCache.SetEntry(endpointName, recordValue, kd.fqdn(svc, endpointName))
for portIdx := range e.Subsets[idx].Ports {
endpointPort := &e.Subsets[idx].Ports[portIdx]
if endpointPort.Name != "" && endpointPort.Protocol != "" {
srvValue := kd.generateSRVRecordValue(svc, int(endpointPort.Port), endpointName)
l := []string{"_" + strings.ToLower(string(endpointPort.Protocol)), "_" + endpointPort.Name}
subCache.SetEntry(endpointName, srvValue, kd.fqdn(svc, append(l, endpointName)...), l...)
}
}
// Generate PTR records only for Named Headless service.
if _, has := getHostname(address); has {
reverseRecord, _ := util.GetSkyMsg(kd.fqdn(svc, endpointName), 0)
generatedRecords[endpointIP] = reverseRecord
}
}
}
subCachePath := append(kd.domainPath, serviceSubdomain, svc.Namespace)
kd.cacheLock.Lock()
defer kd.cacheLock.Unlock()
for endpointIP, reverseRecord := range generatedRecords {
kd.reverseRecordMap[endpointIP] = reverseRecord
}
kd.cache.SetSubCache(svc.Name, subCache, subCachePath...)
return nil
}
整体流程其实和 Service 差不多，只不过在添加 cache 之前会先去查找Endpoint所属的 Service，然后不同的是 Endpoint 的叶子节点中的host存储的是 EndpointIP，而 Service 的叶子节点的 host 中存储的是 fqdn。
kubedns总结
kubedns 有两个模块，kubedns和skydns，kubedns负责监听
Service和Endpoint并将它们转换为 skydns 能够理解的格式，以目录树的形式存在内存中。因为 skydns 是以 etcd 的标准作为后端存储的，所以为了兼容 etcd ，kubedns 在错误信息方面都以 etcd 的格式进行定义的。因此 kubedns 的作用其实可以理解为为 skydns 提供存储。
dnsmasq
dnsmasq 由两个部分组成
1.dnsmasq-nanny，容器里的1号进程，不负责处理 DNS LookUp 请求，只负责管理 dnsmasq。
2.dnsmasq，负责处理 DNS LookUp 请求，并缓存结果。
dnsmasq-nanny 负责监控 config 文件（/etc/k8s/dns/dnsmasq-nanny，也就是kube-dns-config这个 configmap 所挂载的位置）的变化（每 10s 查看一次），如果 config 变化了就会Kill掉 dnsmasq，并重新启动它。
// dns/pkg/dnsmasq/nanny.go#198
// RunNanny 启动 nanny 服务并处理配置变化
func RunNanny(sync config.Sync, opts RunNannyOpts, kubednsServer string) {
// ...
configChan := sync.Periodic()
for {
select {
// ...
// 观察到config变化
case currentConfig = <-configChan:
if opts.RestartOnChange {
// 直接杀掉dnsmasq进程
nanny.Kill()
nanny = &Nanny{Exec: opts.DnsmasqExec}
// 重新加载配置
nanny.Configure(opts.DnsmasqArgs, currentConfig, kubednsServer)
// 重新启动dnsmasq进程
nanny.Start()
} else {
glog.V(2).Infof("Not restarting dnsmasq (--restartDnsmasq=false)")
}
break
}
}
}
让我们看下 sync.Periodic() 这个函数做了些什么
// dns/pkg/dns/config/sync.go#81
func (sync *kubeSync) Periodic() <-chan *Config {
go func() {
// Periodic函数中设置了一个Tick，每10s会去load一下configDir下
// 所有的文件，并对每个文件进行sha256的摘要计算
// 并将这个结果返回。
resultChan := sync.syncSource.Periodic()
for {
syncResult := <-resultChan
// processUpdate函数会比较新的文件的版本和旧的
// 文件的版本，如果不一致会返回changed。
// 值得注意的是有三个文件是需要单独处理的
// federations
// stubDomains
// upstreamNameservers
// 当这三个文件变化是会触发单独的函数（打印日志）
config, changed, err := sync.processUpdate(syncResult, false)
if err != nil {
continue
}
if !changed {
continue
}
sync.channel <- config
}
}()
return sync.channel
}
dnsmasq 中是如何加载配置的呢？
// dns/pkg/dnsmasq/nanny.go#58
// Configure the nanny. This must be called before Start().
// 这个函数会配置 dnsmasq，Nanny 每次 Kill 掉 dnsmasq 后，调用 Start() 之前都会调用这个函数
// 重新加载配置。
func (n *Nanny) Configure(args []string, config *config.Config, kubednsServer string) {
// ...
for domain, serverList := range config.StubDomains {
resolver := &net.Resolver{
PreferGo: true,
Dial: func(ctx context.Context, network, address string) (net.Conn, error) {
d := net.Dialer{}
return d.DialContext(ctx, "udp", kubednsServer)
},
}
// 因为 stubDomain 中可以是以 host:port 的形式存在，所以这里还要做一次 上游的 dns 解析
for _, server := range serverList {
if isIP := (net.ParseIP(server) != nil); !isIP {
switch {
// 如果 server 是以 cluster.local（不知道为什么这里是 hardCode 的）结尾的，就会发往 kubednsServer 进行 DNS 解析
// 因为上面已经配置了 d.DialContext(ctx, "udp", kubednsServer)
case strings.HasSuffix(server, "cluster.local"):
// ...
resolver.LookupIPAddr(context.Background(), server)
default:
// 如果没有以 cluster.local 结尾，就会走外部解析 DNS
// ...
net.LookupIP(server)
}
}
}
}
// ...
}
sidecar
sidecar 启动后会在内部开启一个协程，并在循环中每默认 5s 向 kubedns 发送一次 dns 解析。并记录解析结果。
sidecar 提供了两个http的接口 /healthcheck/kubedns 和 /healthcheck/dnsmasq 给 k8s 用作 livenessProbe 的健康检查。每次请求，sidecar 会将上述记录的 DNS 解析结果返回。
kubedns的优缺点
优点
- 各个模块都做了很好的解耦，方便开发者上手。
- 依赖 dnsmasq ，性能有保障
缺点
因为 dnsmasq-nanny 重启 dnsmasq 的方式，先杀后起，方式比较粗暴，有可能导致这段时间内大量的 DNS 请求失败。
dnsmasq-nanny 检测文件的方式，可能会导致以下问题：
dnsmasq-nanny 每次遍历目录下的所有文件，然后用 ioutil.ReadFile 读取文件内容。如果目录下文件数量过多，可能出现在遍历的同时文件也在被修改，遍历的速度跟不上修改的速度。
这样可能导致遍历完了，某个配置文件才更新完。那么此时，你读取的一部分文件数据并不是和当前目录下文件数据完全一致，本次会重启 dnsmasq。进而，下次检测，还认为有文件变化，到时候，又重启一次 dnsmasq。这种方式不优雅，但问题不大。文件的检测，直接使用 ioutil.ReadFile 读取文件内容，也存在问题。如果文件变化，和文件读取同时发生，很可能你读取完，文件的更新都没完成，那么你读取的并非一个完整的文件，而是坏的文件，这种文件，dnsmasq-nanny 无法做解析，不过官方代码中有数据校验，解析失败也问题不大，大不了下个周期的时候，再取到完整数据，再解析一次。
CoreDNS
CoreDNS 是一个高速并且十分灵活的DNS服务。CoreDNS 允许你通过编写插件的形式去自行处理DNS数据。
结构图
CoreDNS 使用Caddy作为底层的 Web Server，Caddy 是一个轻量、易用的Web Server，它支持 HTTP、HTTPS、HTTP/2、GRPC 等多种连接方式。所有 coreDNS 可以通过四种方式对外直接提供 DNS 服务，分别是 UDP、gRPC、HTTPS 和 TLS
CoreDNS 的大多数功能都是由插件来实现的，插件和服务本身都使用了 Caddy 提供的一些功能，所以项目本身也不是特别的复杂。
插件
CoreDNS 定义了一套插件的接口，只要实现 Handler 接口就能将插件注册到插件链中。
type (
// 只需要为插件实现 ServeDNS 以及 Name 这两个接口并且写一些用于配置的代码就可以将插件集成到 CoreDNS 中
Handler interface {
ServeDNS(context.Context, dns.ResponseWriter, *dns.Msg) (int, error)
Name() string
}
)
现在在 CoreDNS 中已经支持40种左右的插件。
kubernetes
该插件可以让 coreDNS 读取到k8s集群内的 endpoint 以及 service 等信息，从而替代 kubeDNS 作为 k8s 集群内的 DNS 解析服务。不仅如此，该插件还支持多种配置如：
kubernetes [ZONES...] {
; 使用该配置可以连接到远程的k8s集群
kubeconfig KUBECONFIG CONTEXT
endpoint URL
tls CERT KEY CACERT
; 可以设置需要暴露Service的namespace列表
namespaces NAMESPACE...
; 可以暴露带有特定label的namespace
labels EXPRESSION
; 是否可以解析10-0-0-1.ns.pod.cluster.local这种domain（为了兼容kube-dns）
pods POD-MODE
endpoint_pod_names
ttl TTL
noendpoints
transfer to ADDRESS...
fallthrough [ZONES...]
ignore empty_service
}
forward
提供上游解析功能
forward FROM TO... {
except IGNORED_NAMES...
; 强制使用tcp进行域名解析
force_tcp
; 当请求是tcp时，先尝试一次udp解析，失败了再使用tcp
prefer_udp
expire DURATION
; upstream的healthcheck失败的最多次数，默认2，超过的话upstream就会被下掉
max_fails INTEGER
tls CERT KEY CA
tls_servername NAME
; 选择nameserver的策略，random、round_robin、sequential
policy random|round_robin|sequential
health_check DURATION
}
更多的插件可以到 CoreDNS 的插件市场查看
Corefile
CoreDNS 提供了一种简单易懂的 DSL 语言，它允许你通过 Corefile 来自定义 DNS 服务。
coredns.io:5300 {
file db.coredns.io
}
example.io:53 {
log
errors
file db.example.io
}
example.net:53 {
file db.example.net
}
.:53 {
kubernetes
proxy . 8.8.8.8
log
errors
cache
}
通过以上的配置，CoreDNS 会开启两个端口 5300 和 53 ，提供 DNS 解析服务。对于 coredns.io 相关的域名会通过 5300 端口进行解析，其他域名会被解析到 53 端口，不同的域名会应用不同的插件。
插件原理
在 CoreDNS 中 Plugin 其实就是一个出入参数都是 Handler 的函数
// 所谓的插件链其实是一个Middle layer，通过传递链中的下一个Handler，将一个Handler链接到下一个Handler。
type Plugin func(Handler) Handler
同时 CoreDNS 提供了 NextOrFailure 方法，供每个插件在执行完自身的逻辑之后执行下一个插件
// NextOrFailure calls next.ServeDNS when next is not nil, otherwise it will return, a ServerFailure and a nil error.
func NextOrFailure(name string, next Handler, ctx context.Context, w dns.ResponseWriter, r *dns.Msg) (int, error) { // nolint: golint
if next != nil {
if span := ot.SpanFromContext(ctx); span != nil {
child := span.Tracer().StartSpan(next.Name(), ot.ChildOf(span.Context()))
defer child.Finish()
ctx = ot.ContextWithSpan(ctx, child)
}
return next.ServeDNS(ctx, w, r)
}
return dns.RcodeServerFailure, Error(name, errors.New("no next plugin found"))
}
如果 next 为 nil，说明插件链已经调用结束，直接返回 no next plugin found 的 error 即可。
每个 Plugin 也可以调用 (dns.ResponseWriter).WriteMsg(*dns.Msg) 方法来结束整个调用链。
kubernetes 插件做了什么
CoreDNS 正是通过 kubernetes 插件实现了解析 k8s 集群内域名的功能。那么我们看下这个插件做了些什么事情。
// coredns/plugin/kubernetes/setup.go#44
func setup(c *caddy.Controller) error {
// 检查了 corefile 中 kubernetes 配置的定义，并配置了一些缺省值
k, err := kubernetesParse(c)
if err != nil {
return plugin.Error("kubernetes", err)
}
// 启动了对 pod, service, endpoint 三种资源增、删、改的 watch，并注册了一些回调
// 注意：pod 是否启动 watch 是根据配置文件中 pod 的值来决定的，如果值不是 verified 就不会启动 pod 的 watch
// 这里的 watch 方法观测到变化后，仅仅只改变 dns.modified 这个值，它会将该值设置为当前时间戳
err = k.InitKubeCache()
if err != nil {
return plugin.Error("kubernetes", err)
}
// 将插件注册到 Caddy，让 Caddy 启动时能够同时启动该插件
k.RegisterKubeCache(c)
// 注册插件到调用链
dnsserver.GetConfig(c).AddPlugin(func(next plugin.Handler) plugin.Handler {
k.Next = next
return k
})
return nil
}
// coredns/plugin/kubernetes/controller.go#408
// 这三个方法就是 watch 资源时的回调
func (dns *dnsControl) Add(obj interface{}) { dns.detectChanges(nil, obj) }
func (dns *dnsControl) Delete(obj interface{}) { dns.detectChanges(obj, nil) }
func (dns *dnsControl) Update(oldObj, newObj interface{}) { dns.detectChanges(oldObj, newObj) }
// detectChanges detects changes in objects, and updates the modified timestamp
func (dns *dnsControl) detectChanges(oldObj, newObj interface{}) {
// 判断新老对象的版本
if newObj != nil && oldObj != nil && (oldObj.(meta.Object).GetResourceVersion() == newObj.(meta.Object).GetResourceVersion()) {
return
}
obj := newObj
if obj == nil {
obj = oldObj
}
switch ob := obj.(type) {
case *object.Service:
dns.updateModifed()
case *object.Endpoints:
if newObj == nil || oldObj == nil {
dns.updateModifed()
return
}
p := oldObj.(*object.Endpoints)
// endpoint updates can come frequently, make sure it's a change we care about
if endpointsEquivalent(p, ob) {
return
}
dns.updateModifed()
case *object.Pod:
dns.updateModifed()
default:
log.Warningf("Updates for %T not supported.", ob)
}
}
func (dns *dnsControl) Modified() int64 {
unix := atomic.LoadInt64(&dns.modified)
return unix
}
// updateModified set dns.modified to the current time.
func (dns *dnsControl) updateModifed() {
unix := time.Now().Unix()
atomic.StoreInt64(&dns.modified, unix)
}
上面展示的就是 kubernetes 这个 Plugin Watch 各个资源变化后的回调。可以看到它仅仅只改变 dns.modified 一个值，那么当 Service 发生变化后，kubernetes 插件如何感知，并将它们更新到内存呢。其实并没有或者说并不需要。。。因为这里使用了 client-go 中的 informer 机制，kubernetes 在解析 Service DNS 时会根据直接列出所有 Service（这里其实这么说并不准确，如果查找的是泛域名，那么才会列出所有 Service，如果是正常的 servicename.namespace，那么插件会使用 client-go 的 Indexer 机制，根据索引查找符合的 ServiceList），再进行匹配，直到找到匹配的 Service 再根据它的不同类型，决定返回结果。如果是 ClusterIP 类型，则返回 svc 的 ClusterIP，如果是 Headless 类型，则返回它所有的 Endpoint 的IP，如果是 ExternalName 类型，且 external_name 的值为 CNAME 类型，则返回 external_name 的值。整个操作仍然是在内存中进行的，效率并不会很低。
// findServices returns the services matching r from the cache.
func (k *Kubernetes) findServices(r recordRequest, zone string) (services []msg.Service, err error) {
// 如果 namespace 为 * 或者 为 any，或者该 namespace 在配置文件中没有被 namespace: 这个配置项中配置
// 则返回 NXDOMAIN
if !wildcard(r.namespace) && !k.namespaceExposed(r.namespace) {
return nil, errNoItems
}
// 如果 lookup 的 service 为空
if r.service == "" {
// 如果 namepace 存在 或者 namespace 是通配符就返回空的 Service 列表
if k.namespaceExposed(r.namespace) || wildcard(r.namespace) {
// NODATA
return nil, nil
}
// 否则返回 NXDOMAIN
return nil, errNoItems
}
err = errNoItems
if wildcard(r.service) && !wildcard(r.namespace) {
// If namespace exists, err should be nil, so that we return NODATA instead of NXDOMAIN
if k.namespaceExposed(r.namespace) {
err = nil
}
}
var (
endpointsListFunc func() []*object.Endpoints
endpointsList []*object.Endpoints
serviceList []*object.Service
)
if wildcard(r.service) || wildcard(r.namespace) {
// 如果 service 或者 namespace 为 * 或者 any，列出当前所有的 Service
serviceList = k.APIConn.ServiceList()
endpointsListFunc = func() []*object.Endpoints { return k.APIConn.EndpointsList() }
} else {
// 根据 service.namespace 获取 index
idx := object.ServiceKey(r.service, r.namespace)
// 通过 client-go 的 indexer 返回 serviceList
serviceList = k.APIConn.SvcIndex(idx)
endpointsListFunc = func() []*object.Endpoints { return k.APIConn.EpIndex(idx) }
}
// 将 zone 转化为 etcd key 的格式
// /c/local/cluster
zonePath := msg.Path(zone, coredns)
for _, svc := range serviceList {
if !(match(r.namespace, svc.Namespace) && match(r.service, svc.Name)) {
continue
}
// If request namespace is a wildcard, filter results against Corefile namespace list.
// (Namespaces without a wildcard were filtered before the call to this function.)
if wildcard(r.namespace) && !k.namespaceExposed(svc.Namespace) {
continue
}
// 如果查找的 Service 没有 Endpoint，就返回 NXDOMAIN，除非这个 Service 是 Headless Service 或者 External name
if k.opts.ignoreEmptyService && svc.ClusterIP != api.ClusterIPNone && svc.Type != api.ServiceTypeExternalName {
// serve NXDOMAIN if no endpoint is able to answer
podsCount := 0
for _, ep := range endpointsListFunc() {
for _, eps := range ep.Subsets {
podsCount = podsCount + len(eps.Addresses)
}
}
// No Endpoints
if podsCount == 0 {
continue
}
}
// lookup 的 Service 是 headless Service 或者是使用 Endpoint lookup
if svc.ClusterIP == api.ClusterIPNone || r.endpoint != "" {
if endpointsList == nil {
endpointsList = endpointsListFunc()
}
for _, ep := range endpointsList {
if ep.Name != svc.Name || ep.Namespace != svc.Namespace {
continue
}
for _, eps := range ep.Subsets {
for _, addr := range eps.Addresses {
// See comments in parse.go parseRequest about the endpoint handling.
if r.endpoint != "" {
if !match(r.endpoint, endpointHostname(addr, k.endpointNameMode)) {
continue
}
}
for _, p := range eps.Ports {
if !(match(r.port, p.Name) && match(r.protocol, string(p.Protocol))) {
continue
}
s := msg.Service{Host: addr.IP, Port: int(p.Port), TTL: k.ttl}
s.Key = strings.Join([]string{zonePath, Svc, svc.Namespace, svc.Name, endpointHostname(addr, k.endpointNameMode)}, "/")
err = nil
// 遍历 Endpoints 并将结果添加到返回列表
services = append(services, s)
}
}
}
}
continue
}
// External service
// 如果 svc 是 External Service
if svc.Type == api.ServiceTypeExternalName {
s := msg.Service{Key: strings.Join([]string{zonePath, Svc, svc.Namespace, svc.Name}, "/"), Host: svc.ExternalName, TTL: k.ttl}
// 只有当 External Name 是 CNAME 时，才会添加该 Service 到结果
if t, _ := s.HostType(); t == dns.TypeCNAME {
s.Key = strings.Join([]string{zonePath, Svc, svc.Namespace, svc.Name}, "/")
services = append(services, s)
err = nil
}
continue
}
// ClusterIP service
// 正常情况，返回的 msg.Service 的 Host 为 ClusterIP
for _, p := range svc.Ports {
if !(match(r.port, p.Name) && match(r.protocol, string(p.Protocol))) {
continue
}
err = nil
s := msg.Service{Host: svc.ClusterIP, Port: int(p.Port), TTL: k.ttl}
s.Key = strings.Join([]string{zonePath, Svc, svc.Namespace, svc.Name}, "/")
services = append(services, s)
}
}
return services, err
}
coredns的优缺点
优点
- 非常灵活的配置，可以根据不同的需求给不同的域名配置不同的插件
- k8s 1.9 版本后的默认的 dns 解析
缺点
- 缓存的效率不如 dnsmasq，对集群内部域名解析的速度不如 kube-dns （10% 左右）
性能对比
在 CoreDNS 的官网中已有详细的性能测试报告，地址
- 对于内部域名解析 KubeDNS 要优于 CoreDNS 大约 10%，可能是因为 dnsmasq 对于缓存的优化会比 CoreDNS 要好
- 对于外部域名 CoreDNS 要比 KubeDNS 好 3 倍。但这个值大家看看就好，因为 kube-dns 不会缓存 Negative cache。但即使 kubeDNS 使用了 Negative cache，表现仍然也差不多
- CoreDNS 的内存占用情况会优于 KubeDNS