本文主要是对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中部署,其启动流程以下:
- Starting SkyDNS server. Listening on port:10053.
- skydns: metrics enabled on :/metrics.
- Setting up Healthz Handler(/readiness, /cache) on port :8081.
- watch kuber-api-server for service & endpoint & pod.
- initialize in-memory lookup structures to service DNS requests.
说明:
- 线路1:kubernetes cluster中的DNS要求被dnsmasq接受,dnsmasq默许配置了1个1G大小的cache,以提高性能。如果dnsmasq cache中有记录命中,则直接有dnsmasq返回。
- 线路2:若dnsmasq cache中无记录命中,则forward要求到KubeDNS容器中的SkyDNS Server处理,SkyDNS从KubeDNS保护的1块内存(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整合到了1个程序中KubeDNS;
- 1.3中引入了dnsmasq容器,由它接受kubernetes cluster中的DNS要求,目的就是利用dnsmasq的cache模块,提高性能;