Kubernetes中通過kube-dns發現服務
kube-dns可以解決Service的發現問題，k8s將Service的名稱當做域名註冊到kube-dns中，通過Service的名稱就可以訪問其提供的服務。
kube-dns四個組件：
etcd，它的用途是保存DNS規則。
kube2sky，作用是寫入DNS規則。
skydns，提供DNS解析服務。
healthz，提供健康檢查功能。
之前已經了解到kube-dns是由四個容器組成的，它們扮演的角色可以通過下面這張圖來理解。
其中：
SkyDNS是用於服務發現的開源框架，構建於etcd之上。作用是為k8s集群中的Pod提供DNS查詢接口。項目托管於https://github.com/skynetservices/skydns
etcd是一種開源的分布式key-value存儲，其功能與ZooKeeper類似。在kube-dns中的作用為存儲SkyDNS需要的各種數據，寫入方為kube2sky，讀取方為SkyDNS。項目托管於https://github.com/coreos/etcd。
kube2sky是k8s實現的一個適配程序，它通過名為kubernetes的Service（通過kubectl get svc可以查看到該Service，由集群自動創建）調用k8s的list和watch API來監聽k8s Service資源的變更，從而修改etcd中的SkyDNS記錄。代碼可以在k8s源碼（v1.2）的cluster/addons/dns/kube2sky/目錄中找到。
exec-healthz是k8s提供的一種輔助容器，多用於side car模式中。它的原理是定期執行指定的Linux指令，從而判斷當前Pod中關鍵容器的健康狀態。在kube-dns中的作用就是通過nslookup指令檢查DNS查詢服務的健康狀態，k8s livenessProbe通過訪問exec-healthz提供的Http API了解健康狀態，並在出現故障時重啟容器。其源碼位於https://github.com/kubernetes/contrib/tree/master/exec-healthz。
從圖中可以發現，Pod查詢DNS是通過ServiceName.Namespace子域名來查詢的，但在之前的示例中只用了Service名稱，什麽原理呢？其實當我們只使用Service名稱時會默認Namespace為default，而上面示例中的my-nginx Service就是在default Namespace中，因此是可以正常運行的。關於這一點，後續再深入介紹。
skydns-rc.yaml中可以發現livenessProbe是設置在kube2sky容器中的，其意圖應該是希望通過重啟kube2sky來重新寫入DNS規則
域名格式
接下來了解一下kube-dns支持的域名格式，具體為：<service_name>.<namespace>.svc.<cluster_domain>。
其中cluster_domain可以使用kubelet的--cluster-domain=SomeDomain參數進行設置，同時也要保證kube2sky容器的啟動參數中--domain參數設置了相同的值。通常設置為cluster.local。那麽之前示例中的my-nginx Service對應的完整域名就是my-nginx.default.svc.cluster.local。看到這裏，相信很多人會有疑問，既然完整域名是這樣的，那為什麽在Pod中只通過Service名稱和Namespace就能訪問Service呢？下面來解釋其中原因。
配置
域名解析配置
為了在Pod中調用其他Service，kubelet會自動在容器中創建域名解析配置（/etc/resolv.conf），內容為：
感興趣的可以在網上查找一些resolv.conf的資料來了解具體的含義。之所以能夠通過Service名稱和Namespace就能訪問Service，就是因為search配置的規則。在解析域名時會自動拼接成完整域名去查詢DNS。
剛才提到的kubelet--cluster-domain參數與search的具體配置是相對應的。而kube2sky容器的--domain參數影響的是寫入到etcd中的域名，kube2sky會獲取Service的名稱和Namespace，並使用--domain參數拼接完整域名。這也就是讓兩個參數保持一致的原因。
NS相關配置
kube-dns可以讓Pod發現其他Service，那Pod又是如何自動發現kube-dns的呢？在上一節中的/etc/resolv.conf中可以看到nameserver，這個配置就會告訴Pod去哪訪問域名解析服務器。
相應的，可以在之前提到的skydns-svc.yaml中看到spec.clusterIP配置了相同的值。通常來說創建一個Service並不需要指定clusterIP，k8s會自動為其分配，但kube-dns比較特殊，需要指定clusterIP使其與/etc/resolv.conf中的nameserver保持一致。
修改nameserver配置同樣需要修改兩個地方，一個是kubelet的--cluster-dns參數，另一個就是kube-dns Service的clusterIP。
總結
接下來重新梳理一下本文的主要內容。
在k8s集群中，服務是運行在Pod中的，Pod的發現和副本間負載均衡是我們面臨的問題。
通過Service可以解決這兩個問題，但訪問Service也需要對應的IP，因此又引入了Service發現的問題。
得益於kube-dns插件，我們可以通過域名來訪問集群內的Service，解決了Service發現的問題。
為了讓Pod中的容器可以使用kube-dns來解析域名，k8s會修改容器的/etc/resolv.conf配置。
有了以上機制的保證，就可以在Pod中通過Service名稱和namespace非常方便地訪問對應的服務了。
Kubernetes中通過kube-dns發現服務