大綱：

??????? Kubernetes中如何發現服務

??????? 如何發現Pod提供的服務

??????? 如何使用Service發現服務

??????? 如何使用kube-dns發現服務

??????? kube-dns原理

??????? 組成

??????? 域名格式

??????? 配置

注：本次分享內容基于Kubernetes 1.2版本！

下面從一個簡單的例子開始講解。

◆ ??發現Pod提供的服務

首先使用nginx-deployment.yaml文件創建一個Nginx Deployment，文件內容如圖所示：

首先創建兩個運行Nginx服務的Pod：

使用kubectl create -f nginx-deployment.yaml指令創建，這樣便可以得到兩個運行nginx服務的Pod。待Pod運行之后查看一下它們的IP，并在k8s集群內通過podIP和containerPort來訪問Nginx服務：

獲取Pod IP：

在集群內訪問Nginx服務：

看到這里相信很多人會有以下疑問：

1. ?每次收到獲取podIP太扯了，總不能每次都要手動改程序或者配置才能訪問服務吧，要怎么提前知道podIP呢？

2. ?Pod在運行中可能會重建，IP變了怎么解？

3. ?如何在多個Pod中實現負載均衡嘞？

這些問題使用k8s Service就可以解決。

◆ ??使用Service發現服務

下面為兩個Nginx Pod創建一個Service。使用nginx-service.yaml文件進行創建，文件內容如下：

創建之后，仍需要獲取Service的Cluster-IP，再結合Port訪問Nginx服務。

Service可以將pod? IP封裝起來，即使Pod發生重建，依然可以通過Service來訪問Pod提供的服務。此外，Service還解決了負載均衡的問題，大家可以多訪問幾次Service，然后通過kubectl logs 來查看兩個Nginx Pod的訪問日志來確認。

獲取IP：

在集群內訪問Service：

雖然Service解決了Pod的服務發現和負載均衡問題，但存在著類似的問題：不提前知道Service的IP，還是需要改程序或配置啊。看到這里有沒有感覺身體被掏空？

接下來聊聊kube-dns是如何解決上面這個問題的。

◆ ??使用kube-dns發現服務

kube-dns可以解決Service的發現問題，k8s將Service的名稱當做域名注冊到kube-dns中，通過Service的名稱就可以訪問其提供的服務。

可能有人會問如果集群中沒有部署kube-dns怎么辦？沒關系，實際上kube-dns插件只是運行在kube-system命名空間下的Pod，完全可以手動創建它。可以在k8s源碼（v1.2）的cluster/addons/dns目錄下找到兩個模板（skydns-rc.yaml.in和skydns-svc.yaml.in）來創建，為大家準備的完整示例文件會在分享結束后提供獲取方式，PPT中只截取了部分內容。

通過skydns-rc.yaml文件創建kube-dns Pod，其中包含了四個containers，這里開始簡單過一下文件的主要部分，稍后做詳細介紹。

第一部分可以看到kube-dns使用了RC來管理Pod，可以提供最基本的故障重啟功能。

創建kube-dns Pod，其中包含了4個containers

接下來是第一個容器 ?etcd ?，它的用途是保存DNS規則。

第二個容器 ?kube2sky ，作用是寫入DNS規則。

第三個容器是 ?skydns ，提供DNS解析服務。

最后一個容器是 ?healthz ，提供健康檢查功能。

有了Pod之后，還需要創建一個Service以便集群中的其他Pod訪問DNS查詢服務。通過skydns-svc.yaml創建Service，內容如下：

創建完kube-dns Pod和Service，并且Pod運行后，便可以訪問kube-dns服務。

下面創建一個Pod，并在該Pod中訪問Nginx服務：

創建之后等待kube-dns處于運行狀態

再新建一個Pod，通過其訪問Nginx服務

在curl-util Pod中通過Service名稱訪問my-nginx Service：

只要知道需要的服務名稱就可以訪問，使用kube-dns發現服務就是那么簡單。

雖然領略了使用kube-dns發現服務的便利性，但相信有很多人也是一頭霧水：kube-dns到底怎么工作的？在集群中啟用了kube-dns插件，怎么就能通過名稱訪問Service了呢？

◆ ??Kube-dns組成

之前已經了解到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支持的域名格式，具體為：..svc.。

其中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非常方便地訪問對應的服務了。

1. 問: 請問如果公司已有的應用接入的話，那么現有的沒有接入的應用就無法訪問了，因為這個服務發現是k8s集群內部的，外部無法訪問。主要是k8s集群內的服務和集群外的己有的生產的域名訪問如何實現，能在kube－dns整合嗎？

答：兩個問題可以抽象為k8s集群內與集群外服務連通性問題，我們從兩個方面講：

一、集群內訪問集群外

這個問題比較簡單，集群內的Pod會繼承Node上的DNS解析規則。因此只要Node可以訪問的服務，Pod中也可以訪問到。

另外，在1.4版本中，k8s支持了一種ExternalName類型的Service，可以與一個公網域名綁定，通過該Service可以訪問對應公網服務。

二、集群外訪問集群內

1. 可以將Service設置為NodePort類型，這樣通過任意Node的IP和Service Port便可以訪問Service。適合對外的Service比較少的場景。

2. 通過kube-proxy可以對外暴露集群內的服務。

3. 根據實際情況在集群內自定義實現反向代理。

2. 問：我想問下etcd這個容器可以省掉嗎？k8s集群有etcd不可以共用嗎？

答：理論上可以共用etcd。從隔離性的角度考慮來說還是分開好，這樣kube-dns服務不會對整個k8s集群的穩定性產生影響。另外如果把kube-dns看做一個微服務的話，那么應該保證內部組件不依賴外部，可以獨立運行。

您也可以關注我們的官方微信公眾號（ID：ctoutiao），給您更多好看的內容。