本文主要是對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默許配置了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模塊，提高性能；