Kubernetes DNS Service技术研究

本文主要是对kubernetes 1.2和1.3的DNS Service的内部实现分别进行研究，得出其内部实现框架和交互逻辑，并对它们的实现进行了比较。

Kubernetes 1.2 DNS Service

部署

kubernetes 1.2中DNS Server的部署请参考：https://xuxinkun.github.io/2016/07/22/kubernetes-dns/

内部架构及技术细节

画图画的好累，不想写太多字了，其实想说的都在图里。

说明：

• 线路1：kubernetes cluster中的DNS请求被SkyDNS接受，SkyDNS配置了Backend为etcd/cluster，从etcd/cluster中读取数据，然后封装数据返回完成DNS query请求。
• Kube2Sky通过watch kube-api-server对service & endpoint的数据来进行更新etcd中/v2/key/skydns/...中的数据。

Kubernetes 1.3 DNS Service

部署

kubernetes 1.3中DNS Server的部署请参考：http://tonybai.com/2016/10/23/install-dns-addon-for-k8s/

内部架构及技术细节

在kubernetes 1.3中，KubeDNS容器把在1.2中分开部署的SkyDNS和Kube2Sky整合在程序kube-dns中，在容器KubeDNS中部署，其启动流程如下：

1. Starting SkyDNS server. Listening on port:10053.
2. skydns: metrics enabled on :/metrics.
3. Setting up Healthz Handler(/readiness, /cache) on port :8081.
4. watch kuber-api-server for service & endpoint & pod.
5. initialize in-memory lookup structures to service DNS requests.

说明：

• 线路1：kubernetes cluster中的DNS请求被dnsmasq接受，dnsmasq默认配置了一个1G大小的cache，以提高性能。如果dnsmasq cache中有记录命中，则直接有dnsmasq返回。
• 线路2：若dnsmasq cache中无记录命中，则forward请求到KubeDNS容器中的SkyDNS Server处理，SkyDNS从KubeDNS维护的一块内存(cache)中查找数据并进行响应。这个cache是由类似1.2中的Kube2Sky中的模块通过watch kube-api-server对service & endpoint的数据来进行更新维护。

##总结 对比1.2和1.3中的实现，主要区别在：

• 1.2中SkyDNS和Kube2Sky分别部署在两个不同的容器中，直接由SkyDNS接受kubernetes cluster中的DNS请求；
• 1.3中将SkyDNS和Kube2Sky整合到了一个程序中KubeDNS；
• 1.3中引入了dnsmasq容器，由它接受kubernetes cluster中的DNS请求，目的就是利用dnsmasq的cache模块，提高性能；